CE v2 SP

NetScreen conceptos y ejemplos
Manual de referencia de ScreenOS
Volumen 2: Fundamentos
ScreenOS 5.1.0
Ref. 093-1367-000-SP
Revisión B
Copyright Notice The following information is for FCC compliance of Class B devices: The
equipment described in this manual generates and may radiate radio-frequency
Copyright © 2004 Juniper Networks, Inc. All rights reserved. energy. If it is not installed in accordance with NetScreen’s installation
instructions, it may cause interference with radio and television reception. This
Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen equipment has been tested and found to comply with the limits for a Class B
Technologies, GigaScreen, and the NetScreen logo are registered trademarks digital device in accordance with the specifications in part 15 of the FCC rules.
of Juniper Networks, Inc. NetScreen-5GT, NetScreen-5XP, NetScreen-5XT, These specifications are designed to provide reasonable protection against
NetScreen-25, NetScreen-50, NetScreen-100, NetScreen-204, NetScreen-208, such interference in a residential installation. However, there is no guarantee
NetScreen-500, NetScreen-5200, NetScreen-5400, NetScreen-Global PRO, that interference will not occur in a particular installation.
NetScreen-Global PRO Express, NetScreen-Remote Security Client,
NetScreen-Remote VPN Client, NetScreen-IDP 10, NetScreen-IDP 100, If this equipment does cause harmful interference to radio or television
NetScreen-IDP 500, GigaScreen ASIC, GigaScreen-II ASIC, and NetScreen reception, which can be determined by turning the equipment off and on, the
ScreenOS are trademarks of Juniper Networks, Inc. All other trademarks and user is encouraged to try to correct the interference by one or more of the
registered trademarks are the property of their respective companies. following measures:
Information in this document is subject to change without notice. • Reorient or relocate the receiving antenna.
No part of this document may be reproduced or transmitted in any form or by • Increase the separation between the equipment and receiver.
any means, electronic or mechanical, for any purpose, without receiving written
permission from: • Consult the dealer or an experienced radio/TV technician for help.
Juniper Networks, Inc. • Connect the equipment to an outlet on a circuit different from that to
ATTN: General Counsel which the receiver is connected.
1194 N. Mathilda Ave. Caution: Changes or modifications to this product could void the user's
Sunnyvale, CA 94089-1206 warranty and authority to operate this device.
FCC Statement Disclaimer

The following information is for FCC compliance of Class A devices: This THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE
equipment has been tested and found to comply with the limits for a Class A ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
digital device, pursuant to part 15 of the FCC rules. These limits are designed to PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED
provide reasonable protection against harmful interference when the equipment HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE
is operated in a commercial environment. The equipment generates, uses, and SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR
can radiate radio-frequency energy and, if not installed and used in accordance NETSCREEN REPRESENTATIVE FOR A COPY.
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.
Contenido
Contenido
Prefacio ........................................................................ ix Capítulo 2 Zonas ........................................................31
Convenciones ............................................................ x Zonas de seguridad .................................................34
Convenciones de la interfaz de línea Zona Global ............................................................... 34
de comandos (CLI) ....................................................... x Opciones SCREEN ...................................................... 34
Convenciones de la interfaz gráfica (WebUI) .............. xi Zonas de túnel..........................................................35
Convenciones para las ilustraciones.......................... xiii Ejemplo: Asociar una interfaz de túnel
Convenciones de nomenclatura y conjuntos de a una zona de túnel ............................................ 36
caracteres ..................................................................xiv
Configuración de zonas de seguridad y zonas
Documentación de NetScreen de túnel ....................................................................37
de Juniper Networks ................................................. xv Creación de una zona............................................... 37
Capítulo 1 Arquitectura de ScreenOS...........................1 Modificación de una zona ........................................ 38
Eliminación de una zona ........................................... 39
Zonas de seguridad ...................................................2
Zonas de función .....................................................40
Interfaces de zonas de seguridad .............................3
Zona Null .................................................................... 40
Interfaces físicas ...........................................................3
Zona MGT................................................................... 40
Subinterfaces ................................................................4
Zona HA...................................................................... 40
Enrutadores virtuales ..................................................5 Zona Self .................................................................... 40
Directivas....................................................................6 Zona VLAN .................................................................. 40
VPNs............................................................................9 Modos de puerto......................................................41
Sistemas virtuales......................................................11 Establecimiento de los modos de puertos ................. 47
Ejemplo: Modo de puerto Home-Work ................ 48
Secuencia de flujo de paquetes .............................12
Zonas en los modos “Home-Work”
Ejemplo (1ª parte): Empresa con seis zonas ........16 y “Combined Port” ..................................................... 49
Ejemplo (2ª parte): Interfaces para seis zonas .....18 Ejemplo: Zonas Home-Work ................................. 51
Ejemplo (3ª parte): Dos dominios
de enrutamiento ..................................................22 Capítulo 3 Interfaces ..................................................53
Ejemplo (4ª parte): Directivas...............................25 Tipos de interfaces ...................................................55
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos i

Contenido
Interfaces de zonas de seguridad..............................55 Ejemplo: Eliminar una interfaz de la zona

Físicas ...................................................................55 de seguridad ....................................................... 74
Subinterfaz............................................................55 Direcciones IP secundarias ......................................75
Interfaces agregadas ..........................................56 Propiedades de las direcciones IP secundarias ........ 75
Interfaces redundantes ........................................56 Ejemplo: Crear una dirección IP secundaria....... 76
Interfaces de seguridad virtuales .........................56 Interfaces loopback .................................................77
Interfaces de zonas de función..................................57 Ejemplo: Crear una interfaz loopback................. 77
Interfaz de administración....................................57 Uso de interfaces loopback ....................................... 78
Interfaz de HA .......................................................57 Ejemplo: Interfaz loopback para
Interfaces de túnel......................................................58 la administración ................................................. 78
Eliminar interfaces de túnel ..................................62 Ejemplo: BGP en una interfaz loopback .............. 79
Ejemplo: Eliminar una interfaz de túnel ................62 Ejemplo: VSIs en una interfaz loopback............... 79
Visualización de interfaces.......................................64 Ejemplo: Interfaz loopback como interfaz
de origen ............................................................. 80
Tabla de interfaces ..............................................64
Cambios de estado de la interfaz ...........................81
Configuración de interfaces de la zona
Supervisión de la conexión física............................... 83
de seguridad............................................................66
Seguimiento de direcciones IP................................... 84
Asociación de una interfaz a una zona
Configuración del seguimiento de IP .................. 85
de seguridad..............................................................66
Ejemplo: Configuración del seguimiento de IP
Ejemplo: Asociar una interfaz ...............................66
de interfaz............................................................ 87
Direccionamiento de una interfaz de la zona
Supervisión de interfaces ........................................... 91
de seguridad L3 .........................................................67
Ejemplo: Dos interfaces supervisadas.................. 93
Direcciones IP públicas ........................................68
Ejemplo: Bucle de supervisión de interfaces ....... 94
Direcciones IP privadas ........................................69
Supervisión de zonas de seguridad ........................... 98
Ejemplo: Direccionamiento de una interfaz.........69
Interfaces inactivas y flujo de tráfico ......................... 99
Desasociación de una interfaz de una zona
Fallo en la interfaz de salida.............................. 100
de seguridad..............................................................70
Fallo en la interfaz de entrada .......................... 103
Ejemplo: Desasociar una interfaz .........................70
Modificación de interfaces ........................................71 Capítulo 4 Modos de las interfaces..........................107
Ejemplo: Modificar los ajustes de la interfaz ........72 Modo transparente ................................................108
Creación de subinterfaces.........................................73 Ajustes de zona ........................................................ 109
Ejemplo: Subinterfaz en el sistema raíz.................73 Zona VLAN.......................................................... 109
Eliminación de subinterfaces......................................74 Zonas de capa 2 predefinidas .......................... 109
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos ii

Contenido
Reenvío de tráfico ....................................................110 Tiempos de espera de servicios............................... 156

Opciones “unicast” desconocidas ...........................112 Ejemplo: Establecer el tiempo de espera
Método de inundación ......................................113 de un servicio .................................................... 157
Método ARP/Trace-Route....................................115 Servicios ICMP .......................................................... 158
Ejemplo: Interfaz VLAN1 para administración.....119 Ejemplo: Definir un servicio ICMP....................... 159
Ejemplo: Modo transparente..............................122 RSH ALG.................................................................... 160
Modo NAT ...............................................................127 Sun Remote Procedure Call Application
Tráfico NAT entrante y saliente..................................129 Layer Gateway......................................................... 160
Ajustes de interfaz .....................................................130 Situaciones típicas de llamadas RPC ................ 160
Ejemplo: Modo NAT ............................................131 Servicios Sun RPC ............................................... 161
Ejemplo: Servicios Sun RPC ................................ 162
Modo de ruta .........................................................135
Microsoft Remote Procedure Call Application
Ajustes de interfaz .....................................................136
Layer Gateway......................................................... 163
Ejemplo: Modo de ruta ......................................137
Servicios de MS RPC........................................... 164
Capítulo 5 Bloques para la construcción Grupos de servicios MS RPC .............................. 167
de directivas..............................................................141 Ejemplo: Servicios para MS RPC ........................ 167
Direcciones ............................................................143 Real Time Streaming Protocol Application
Layer Gateway......................................................... 169
Entradas de direcciones...........................................144
Ejemplo: Agregar direcciones............................144 Métodos de petición RTSP.................................. 171
Ejemplo: Modificar direcciones .........................145 Códigos de estado de RTSP............................... 173
Ejemplo: Eliminar direcciones ............................146 Ejemplo: Servidor de medios en un dominio
privado .............................................................. 175
Grupos de direcciones .............................................146
Ejemplo: Servidor de medios en un dominio
Ejemplo: Crear un grupo de direcciones...........148
público .............................................................. 178
Ejemplo: Editar una entrada de grupo
de direcciones ...................................................149 Protocolo H.323 para “Voice-over-IP” ...................... 181
Ejemplo: Eliminar un miembro y un grupo .........150 Ejemplo: Equipo selector (“gatekeeper”) en
la zona Trust (modo “transparente” o “ruta”)...... 181
Servicios..................................................................151 Ejemplo: Equipo selector (“gatekeeper”) en
Servicios predefinidos ...............................................151 la zona Untrust (modo transparente o ruta) ....... 183
Servicios personalizados...........................................153 Ejemplo: Llamadas salientes con NAT................ 186
Ejemplo: Agregar un servicio personalizado......154 Ejemplo: Llamadas entrantes con NAT .............. 191
Ejemplo: Modificar un servicio personalizado....155 Ejemplo: Equipo selector en la zona Untrust
Ejemplo: Eliminar un servicio personalizado.......155 con NAT.............................................................. 195
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos iii

Contenido
Protocolo de inicio de sesión (“Session Initiation Ejemplo: Proxy en la zona pública .................... 243
Protocol” o “SIP”) .......................................................200 Ejemplo: Zona triple, proxy en DMZ ................... 247
Métodos de petición del protocolo SIP ..............201 Ejemplo: Untrust intrazonal ................................. 253
Clases de respuestas SIP ....................................204 Ejemplo: Trust intrazonal..................................... 259
ALG – Application-Layer Gateway .....................206 Ejemplo: VPN de malla completa para SIP........ 263
SDP .....................................................................207 Administración del ancho de banda para
Creación de ojos de aguja ...............................208 servicios de VoIP....................................................... 271
Tiempo de espera por inactividad Grupos de servicios.................................................. 274
de la sesión ........................................................211 Ejemplo: Crear un grupo de servicios................ 275
Protección contra ataques SIP ...........................212 Ejemplo: Modificar un grupo de servicios ......... 276
Ejemplo: SIP Protect Deny...................................212 Ejemplo: Eliminar un grupo de servicios ............ 277
Ejemplo: Tiempos de espera por inactividad
de señalización o de medios.............................213 Conjuntos de DIP ....................................................278
Ejemplo: Protección contra inundaciones UDP ..213 Traducción de direcciones de puertos ............. 279
Ejemplo: Máximo de conexiones SIP..................214 Ejemplo: Crear un conjunto de DIP con PAT ...... 279
SIP con traducción de direcciones de red (NAT)......215 Ejemplo: Modificar un conjunto de DIP ............. 281
Llamadas salientes .............................................216 Direcciones DIP “sticky”............................................ 281
Llamadas entrantes............................................216 Interfaz extendida y DIP ........................................... 282
Llamadas reenviadas.........................................217 Ejemplo: Usar DIP en otra subred....................... 282
Terminación de la llamada................................217 Interfaz de bucle invertido ("loopback") y DIP.......... 291
Mensajes de llamada Re-INVITE .........................217 Ejemplo: DIP en una interfaz loopback.............. 292
Temporizadores de sesiones de llamadas .........218 Grupos de DIP .......................................................... 297
Cancelación de la llamada ..............................218 Ejemplo: Grupo de DIP ...................................... 299
Bifurcación .........................................................218 Tareas programadas..............................................301
Mensajes del SIP.................................................219 Ejemplo: Tarea programada repetitiva ............. 301
Encabezados SIP ................................................219
Cuerpo SIP..........................................................223 Capítulo 6 Directivas ................................................305
Supuesto de NAT con el protocolo SIP................223 Elementos básicos..................................................307
Soporte de llamadas SIP entrantes utilizando Tres tipos de directivas ...........................................308
el servidor de registro del SIP..............................226
Directivas interzonales.............................................. 308
Ejemplo: Llamada entrante (DIP de interfaz) ......228
Ejemplo: Llamada entrante (conjunto de DIP) ...232 Directivas intrazonales.............................................. 309
Ejemplo: Llamada entrante con MIP ..................236 Directivas globales................................................... 310
Ejemplo: Proxy en la zona privada.....................239 Listas de conjuntos de directivas............................311
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos iv

Contenido
Definición de directivas..........................................312 Ejemplo: Conjunto de directivas interzonales.... 337

Directivas y reglas ....................................................312 Ejemplo: Directivas intrazonales ........................ 344
Anatomía de una directiva ......................................314 Ejemplo: Directiva global .................................. 347
ID ........................................................................315 Introducción del contexto de una directiva ............ 348
Zonas..................................................................315 Varios elementos por componente de directiva ..... 349
Direcciones ........................................................315 Negación de direcciones ........................................ 351
Servicios..............................................................316 Ejemplo: Negación de la dirección
Acción ................................................................317 de destino.......................................................... 351
Aplicación ..........................................................318 Modificación y desactivación de directivas............ 355
Nombre ..............................................................318 Verificación de directivas ........................................ 356
Tunelización VPN ................................................319 Reordenamiento de directivas ................................ 357
Tunelización L2TP ................................................319 Eliminación de una directiva ................................... 358
Deep Inspection.................................................320
Colocación al principio de la lista Capítulo 7 Asignación de tráfico..............................359
de directivas ......................................................320 Aplicación de la asignación de tráfico .................360
Traducción de direcciones de origen ...............321
Administración del ancho de banda a nivel
Traducción de direcciones de destino ..............321 de directivas ............................................................ 360
Autenticación de usuarios..................................321 Ejemplo: Asignar tráfico ..................................... 361
Copia de seguridad de la sesión HA .................324
Establecimiento de las prioridades del servicio .....367
Filtrado de URL....................................................325
Registro...............................................................325 Ejemplo: Gestionar colas de prioridades .......... 368
Recuento............................................................325 Capítulo 8 Parámetros del sistema ...........................375
Umbral de alarma de tráfico .............................326
Compatibilidad con DNS (sistema de nombres
Tareas programadas..........................................326
de dominio)............................................................377
Análisis antivirus ..................................................326
Consulta DNS ........................................................... 378
Asignación de tráfico .........................................327
Tabla de estado de DNS .......................................... 379
Directivas aplicadas...............................................329 Ejemplo: Servidor DNS y programación de
Visualización de directivas .......................................329 actualizaciones ................................................. 380
Iconos de directivas ...........................................329 Ejemplo: Establecer un intervalo
Creación de directivas.............................................331 de actualización de DNS................................... 381
Ubicación de directivas .....................................331 DNS dinámico .......................................................... 382
Ejemplo: Servicio de correo de directivas Ejemplo: Configuración de DDNS para
interzonales ........................................................332 el servidor dyndns.............................................. 383
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos v

Contenido
Ejemplo: Configuración de DDNS para Ejemplo: Múltiples instancias PPPoE ................... 419
el servidor de ddo ..............................................384 PPPoE y alta disponibilidad ...................................... 422
División de direcciones del DNS proxy .....................385
Actualización o degradación de firmware ............423
Ejemplo: Dividir peticiones de DNS ....................386
Requisitos para actualizar o degradar firmware
DHCP: Protocolo de configuración dinámica del dispositivo .......................................................... 424
de hosts ..................................................................388 Conexión del servidor de NetScreen-Security
Servidor DHCP...........................................................390 Manager............................................................ 425
Ejemplo: Dispositivo NetScreen como Descarga de nuevo firmware .................................. 426
servidor DHCP.....................................................390 Carga de nuevo firmware ................................. 429
Opciones del servidor DHCP ..............................396 Mediante el cargador de arranque o
Ejemplo: Opciones de servidor DHCP del sistema operativo ........................................ 431
personalizadas ...................................................397 Actualización de dispositivos NetScreen en una
Servidor DHCP en un clúster de NSRP .................397 configuración NSRP.................................................. 434
Detección del servidor DHCP .............................398 Actualización de dispositivos en una
Ejemplo: Activar la detección de servidores configuración NSRP activa/pasiva..................... 434
DHCP ..................................................................399 Actualizar dispositivos en una configuración
Ejemplo: Desactivar la detección de NSRP activa/activa............................................. 439
servidores DHCP .................................................399 Autenticar firmware y archivos DI............................. 445
Agente de retransmisión de DHCP ...........................400 Obtención del certificado de autenticación .... 445
Ejemplo: Dispositivo NetScreen como agente Carga del certificado de autenticación ........... 447
de retransmisión de DHCP..................................401 Autenticación de firmware de ScreenOS........... 448
Cliente DHCP ............................................................406 Autenticación de un archivo de base
Ejemplo: Dispositivo NetScreen como de datos de objetos de ataques DI .................. 448
cliente DHCP ......................................................406 Descarga y carga de configuraciones .................450
Propagación de los ajustes TCP/IP............................408 Almacenamiento e importación de ajustes............. 450
Ejemplo: Reenviar ajustes TCP/IP ........................409
Retroactivación (“rollback”) de una configuración . 452
PPPoE ......................................................................411 Última configuración correcta conocida .......... 452
Ejemplo: Configurar PPPoE .................................411 Retroactivación automática y manual de una
Ejemplo: Configurar PPPoE en las interfaces configuración .................................................... 453
principal y de respaldo de la zona Untrust ........416 Carga de un nuevo archivo de configuración . 454
Múltiples sesiones PPPoE a través de una Bloqueo del archivo de configuración .................... 455
sola interfaz ..............................................................417 Inclusión de comentarios en un archivo de
Interfaces no etiquetadas ..................................418 configuración .................................................... 456
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos vi

Contenido
Establecer Bulk-CLI de NetScreen-Security Reloj del sistema ....................................................465

Manager ................................................................458 Fecha y hora............................................................ 465
Claves de licencia .................................................459 Huso horario ............................................................. 465
Ejemplo: Ampliar la capacidad de usuarios......460 NTP ........................................................................... 466
Registro y activación de los servicios Múltiples servidores NTP ..................................... 466
de suscripción ........................................................461 Desfase temporal máximo................................. 467
Servicio temporal......................................................461 Protocolos NTP y NSRP ........................................ 468
Paquete de AV, filtrado de URLs y DI incluido Ejemplo: Configurar servidores NTP y un
con un dispositivo nuevo ..........................................462 valor de desfase horario máximo ...................... 468
Actualización de AV, filtrado de URLs y DI Servidores NTP seguros....................................... 469
en un dispositivo existente ........................................463
Sólo actualización de DI...........................................464 Índice ......................................................................... IX-I
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos vii

Contenido
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos viii

Prefacio
El Volumen 2, “Fundamentos” describe la arquitectura de ScreenOS y sus elementos, incluyendo ejemplos de

configuración de algunos de ellos. En este volumen se describen:
• Conceptos generales sobre la arquitectura de ScreenOS
• Zonas de seguridad, de túneles y de funciones
• Distintos tipos de interfaz, como interfaces físicas, subinterfaces, interfaces de seguridad virtuales (VSIs),
interfaces redundantes, interfaces agregadas e interfaces de túnel para VPNs
• Modos de interfaz en los que pueden funcionar las interfaces NetScreen: traducción de direcciones de red
(NAT), ruta y transparente
• Directivas para controlar el tráfico a través de una interfaz y elementos utilizados para crear directivas y
redes privadas virtuales, como direcciones, usuarios o servicios
• Conceptos de administración de tráfico
• Parámetros de sistema para las siguientes funciones:
– Asignación de direcciones del sistema de nombres de dominio (DNS)
– Protocolo de configuración dinámica de servidor (DHCP) para la asignación o el relevo de ajustes
TCP/IP
– Filtrado de URL
– Carga y descarga de ajustes de configuración y software hacia/desde un dispositivo NetScreen
– Claves de licencia para ampliar las funciones de un dispositivo NetScreen
– Configuración del reloj del sistema
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos ix

Prefacio Convenciones
CONVENCIONES
Este documento contiene distintos tipos de convenciones, que se explican en las siguientes secciones:
• “Convenciones de la interfaz de línea de comandos (CLI)”
• “Convenciones de la interfaz gráfica (WebUI)” en la pàgina xi
• “Convenciones para las ilustraciones” en la pàgina xiii
• “Convenciones de nomenclatura y conjuntos de caracteres” en la pàgina xiv
Convenciones de la interfaz de línea de comandos (CLI)

Las siguientes convenciones se utilizan para representar la sintaxis de los comandos de la interfaz de línea de
comandos (CLI):
• Los comandos entre corchetes [ ] son opcionales.
• Los elementos entre llaves { } son obligatorios.
• Si existen dos o más opciones alternativas, aparecerán separadas entre sí por barras verticales ( | ).
Por ejemplo:
set interface { ethernet1 | ethernet2 | ethernet3 } manage
significa “establecer las opciones de administración de la interfaz ethernet1, ethernet2 o ethernet3”.
• Las variables aparecen en cursiva. Por ejemplo:
set admin user name password
Los comandos CLI insertados en el contexto de una frase aparecen en negrita (salvo en el caso de las variables,
que siempre aparecen en cursiva ). Por ejemplo: “Utilice el comando get system para visualizar el número de serie
de un dispositivo NetScreen”.
Nota: Para escribir palabras clave, basta con introducir los primeros caracteres que permitan al sistema reconocer
de forma inequívoca la palabra que se está introduciendo. Por ejemplo, es suficiente escribir set adm u joe
j12fmt54 para que el sistema reconozca el comando set admin user joe j12fmt54 . Aunque este método se
puede utilizar para introducir comandos, en la presente documentación todos ellos se representan con sus
palabras completas.
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos x

Convenciones de la interfaz gráfica (WebUI)

En este manual se utiliza la comilla angular ( > ) para indicar las rutas de navegación de la WebUI por las que se
pasa al hacer clic en opciones de menú y vínculos. Por ejemplo, la ruta para abrir el cuadro de diálogo de
configuración de direcciones se representa como sigue: Objects > Addresses > List > New . A continuación se
muestra la secuencia de navegación.
1. Haga clic en Objects en la columna de menú. 3. Haga clic en List.

La opción de menú Objects se desplegará para Aparecerá la tabla de libretas de direcciones.
mostrar las opciones subordinadas que contiene. 4. Haga clic en el vínculo New.
2. (Menú Applet) Sitúe el mouse sobre Addresses. Aparecerá el cuadro de diálogo de configuración
(Menú DHTML) Haga clic en Addresses. de nuevas direcciones.
La opción de menú Addresses se desplegará para
mostrar las opciones subordinadas que contiene.
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xi

Para llevar a cabo una tarea en la WebUI, en primer lugar debe acceder al cuadro de diálogo apropiado, donde
podrá definir objetos y establecer parámetros de ajuste. El conjunto de instrucciones de cada tarea se divide en dos
partes: la ruta de navegación y los datos de configuración. Por ejemplo, el siguiente conjunto de instrucciones
incluye la ruta al cuadro de diálogo de configuración de direcciones y los ajustes de configuración que se deben
realizar:
Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK :
Address Name: addr_1
IP Address/Domain Name:
IP/Netmask: (seleccione), 10.2.2.5/32
Zone: Untrust
Nota: En este ejemplo, no hay

Address Name: addr_1
instrucciones para el campo
Comment, por lo que se deja
en blanco.
IP Address Name/Domain Name:
Zone: Untrust
Haga clic
en OK .
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xii

Convenciones para las ilustraciones

Los siguientes gráficos conforman el conjunto básico de imágenes utilizado en las ilustraciones de este manual:
Red de área local (LAN) con

Dispositivo NetScreen genérico una única subred
(ejemplo: 10.1.1.0/24)
Dominio de enrutamiento virtual Internet
Rango de direcciones IP dinámicas

Zona de seguridad (DIP)
Equipo de escritorio
Interfaces de zonas de seguridad
Blanca = interfaz de zona protegida
(ejemplo: zona Trust)
Negra = interfaz de zona externa Equipo portátil
(ejemplo: zona sin confianza o zona Untrust)
Dispositivo de red genérico

Interfaz de túnel
(ejemplos: servidor NAT,
concentrador de acceso)
Túnel VPN
Servidor
Icono de enrutador (router)
Icono de conmutador (switch)
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xiii

Convenciones de nomenclatura y conjuntos de caracteres

ScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios
administradores, servidores de autenticación, puertas de enlace IKE, sistemas virtuales, túneles de VPN y zonas)
definidas en las configuraciones de ScreenOS.
• Si la secuencia de caracteres que conforma un nombre contiene al menos un espacio, la
cadena completa deberá entrecomillarse mediante comillas dobles ( “ ); por ejemplo,
set address trust “local LAN” 10.1.1.0/24 .
• NetScreen eliminará cualquier espacio al comienzo o al final de una cadena entrecomillada;
por ejemplo, “ local LAN ” se transformará en “local LAN”.
• NetScreen tratará varios espacios consecutivos como uno solo.
• En las cadenas de nombres se distingue entre mayúsculas y minúsculas; por el contrario, en
muchas palabras clave de la interfaz de línea de comandos pueden utilizarse indistintamente.
Por ejemplo, “local LAN” es distinto de “local lan”.
ScreenOS admite los siguientes conjuntos de caracteres:
• Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de múltiples bytes (MBCS). Algunos
ejemplos de SBCS son los juegos de caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS,
también conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el coreano
y el japonés.
Nota: Una conexión de consola sólo admite conjuntos SBCS. La WebUI admite tanto SBCS como MBCS,
según el conjunto de caracteres que admita el explorador web.
• Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepción de las comillas dobles ( “ ),
que tienen un significado especial como delimitadores de cadenas de nombres que contengan espacios.
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xiv

Prefacio Documentación de NetScreen de Juniper Networks
DOCUMENTACIÓN DE NETSCREEN DE JUNIPER NETWORKS

Para obtener documentación técnica sobre cualquier producto NetScreen de Juniper Networks, visite
www.juniper.net/techpubs/.
Para obtener soporte técnico, abra un expediente de soporte utilizando el vínculo “Case Manager” en la página web
http://www.juniper.net/support/ o llame al teléfono 1-888-314-JTAC (si llama desde los EE.UU.) o al
+1-408-745-9500 (si llama desde fuera de los EE.UU.).
Si encuentra algún error o omisión en esta documentación, póngase en contacto con nosotros a través de la
siguiente dirección de correo electrónico:
techpubs-comments@juniper.net
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xv

Prefacio Documentación de NetScreen de Juniper Networks
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xvi

Capítulo 1
Arquitectura de ScreenOS
1
La arquitectura del sistema NetScreen ScreenOS de Juniper Networks ofrece una gran flexibilidad a la hora de
diseñar la estructura de seguridad de una red. En los dispositivos NetScreen con más de dos interfaces es posible
crear numerosas zonas de seguridad y configurar directivas para regular el tráfico dentro de una zona (tráfico
intrazonal) y entre zonas distintas (tráfico interzonal). Puede enlazar una o varias interfaces a cada zona y habilitar
en cada zona un conjunto distinto de opciones de administración y de vigilancia de ataques al cortafuegos.
Básicamente, ScreenOS permite crear el número de zonas que cada entorno de red necesita, asignar el número de
interfaces que cada zona necesita, y diseñar cada interfaz según las necesidades específicas.
En este capítulo se presenta ScreenOS, describiendo los siguientes componentes principales:
• “Zonas de seguridad” en la pàgina 2
• “Interfaces de zonas de seguridad” en la pàgina 3
• “Enrutadores virtuales” en la pàgina 5
• “Directivas” en la pàgina 6
• “VPNs” en la pàgina 9
• “Sistemas virtuales” en la pàgina 11
Además, para ayudarle a comprender mejor el mecanismo que utiliza ScreenOS para procesar el tráfico, en la
sección “Secuencia de flujo de paquetes” en la pàgina 12 verá la secuencia de flujo de un paquete entrante.
El capítulo concluye con un ejemplo en cuatro partes que ilustra la configuración básica de un dispositivo
NetScreen utilizando ScreenOS:
• “Ejemplo (1ª parte): Empresa con seis zonas” en la pàgina 16
• “Ejemplo (2ª parte): Interfaces para seis zonas” en la pàgina 18
• “Ejemplo (3ª parte): Dos dominios de enrutamiento” en la pàgina 22
• “Ejemplo (4ª parte): Directivas” en la pàgina 25
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 1

Capítulo 1 Arquitectura de ScreenOS Zonas de seguridad
ZONAS DE SEGURIDAD
Una zona de seguridad es un conjunto de uno o varios segmentos de red, lo que requiere regular el tráfico entrante
y saliente por medio de directivas (consulte “Directivas” en la pàgina 6)1. Las zonas de seguridad son entidades
lógicas que tienen asociadas una o varias interfaces. Si dispone de distintos tipos de dispositivos NetScreen, podrá
definir múltiples zonas de seguridad, dependiendo su número exacto de las necesidades de su red. Además de las
zonas definidas por el usuario, también puede utilizar las zonas predefinidas: Trust, Untrust y DMZ (para el
2
funcionamiento de la capa 3), o V1-Trust, V1-Untrust y V1-DMZ (para el funcionamiento de la capa 2) . Si lo desea,
puede seguir utilizando sólo las zonas predefinidas. También puede ignorar las zonas predefinidas y utilizar
exclusivamente las definidas por el usuario3. También es posible utilizar los dos tipos de zonas (predefinidas y
definidas por el usuario) simultáneamente. Esta flexibilidad en la configuración de las zonas permite diseñar la red
que mejor responda a sus necesidades específicas.
Una red configurada con 5 zonas de

seguridad—3 zonas predeterminadas Finance
(Trust, Untrust, DMZ), y 2 zonas
definidas por el usuario (Finance, Eng) Untrust
Trust Motor de
directivas Dispositivo NetScreen
El tráfico (indicado por las líneas

negras) sólo puede pasar de una
zona de seguridad a otra si hay una Eng
directiva que lo permite. DMZ
1. La única zona de seguridad que no necesita ningún segmento de red es la zona global. (Para obtener más información, consulte “Zona Global” en la
pàgina 34). A efectos prácticos, se considera que una zona sin interfaces asociadas y sin entradas de libreta de direcciones no contiene segmentos de red.
2. Si actualiza una antigua versión de ScreenOS, todas las configuraciones de las zonas correspondientes permanecerán intactas.
3. No es posible eliminar las zonas de seguridad predefinidas. Por el contrario, sí se pueden eliminar las zonas definidas por el usuario. Cuando se elimina
una zona de seguridad, se eliminan automáticamente todas las direcciones configuradas para esa zona.

Capítulo 1 Arquitectura de ScreenOS Interfaces de zonas de seguridad
INTERFACES DE ZONAS DE SEGURIDAD

Cada interfaz de una zona de seguridad es como una puerta que el tráfico TCP/IP debe cruzar para pasar de una
zona a otra.
Mediante las directivas que usted defina, podrá permitir que el tráfico entre zonas fluya en un solo sentido o en
ambos4. Al definir las rutas, estará especificando las interfaces que el tráfico tendrá que utilizar para pasar de una
zona a otra. Como es posible asociar múltiples interfaces a una zona, las rutas diseñadas tienen una gran
importancia a la hora de dirigir el tráfico a las interfaces deseadas.
Para permitir que el tráfico pase de una zona a otra, debe asociar una interfaz a la zona y, en el caso de una interfaz
en modo de ruta o en modo NAT (consulte el Capítulo 4, “Modos de las interfaces”), asignar una dirección IP a la
interfaz. Dos tipos de interfaz comúnmente utilizados son las interfaces físicas y, en dispositivos que admitan
sistemas virtuales, las subinterfaces (es decir, la realización de una interfaz física en la capa 2). Para obtener más
información, consulte el Capítulo 3, “Interfaces”.
Interfaces físicas
Una interfaz física se refiere a los componentes físicamente presentes en el dispositivo NetScreen. Las
convenciones de nomenclatura de interfaces difieren de un dispositivo a otro. En el dispositivo NetScreen-500, por
ejemplo, una interfaz física se identifica por la posición de un módulo de interfaz y un puerto Ethernet en ese
módulo. Por ejemplo, la interfaz ethernet1/2 designa el módulo de interfaz situado en el primer bastidor
(ethernet1/2) y en el segundo puerto (ethernet1/2) .
Asignaciones de las interfaces físicas
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2
Nota: Para conocer la convención de nomenclatura de un dispositivo NetScreen determinado, consulte el manual
de usuario de dicho dispositivo.
4. Para intercambiar tráfico entre dos interfaces asociadas a una misma zona no se requiere ninguna directiva, ya que ambas tendrán el mismo nivel de
seguridad. ScreenOS necesita directivas para controlar el tráfico entre zonas, no dentro de ellas.

Capítulo 1 Arquitectura de ScreenOS Interfaces de zonas de seguridad
Subinterfaces
En los dispositivos que admiten redes LAN virtuales (VLAN), una interfaz física se puede dividir lógicamente en
varias subinterfaces virtuales, que ocupan el ancho de banda que precisan en cada momento de la interfaz física de
la que proceden. Una subinterfaz es un elemento abstracto con funciones idénticas a las de una interfaz física, de la
5
que se diferencia por el etiquetado VLAN 802.1Q. El dispositivo NetScreen dirige el tráfico desde o hacia una zona
con subinterfaz a través de su dirección IP y su etiqueta VLAN. Por razones prácticas, los administradores
normalmente utilizan el mismo número para la etiqueta VLAN y para la subinterfaz. Por ejemplo, la interfaz
ethernet1/2 con la etiqueta VLAN 3 se llamará ethernet1/2.3 . Así se identifica el módulo de interfaz que se
encuentra en el primer bastidor , el segundo puerto del módulo y la subinterfaz número 3 (ethernet1/2.3 ) .
Observe que aunque una subinterfaz comparte parte de su identidad con una interfaz física, la zona a la que se
asocia es independiente de la zona a la que se asocia la interfaz física. Puede asociar la subinterfaz ethernet1/2.3 a
una zona distinta de la utilizada para la interfaz física ethernet1/2 o a la que desee asociar ethernet1/2.2 . Asimismo,
no hay restricciones en cuanto a la asignación de direcciones IP. El término subinterfaz no implica que su dirección
se encuentre en una subred dentro del espacio de direcciones de la interfaz física.
Asignaciones de subinterfaces
3/1.1 3/2.1
1/1.1 1/2.1 3/1.2 3/2.2
1/1.2 1/2.2 3/1.3 3/2.3
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2
2/1.1 2/2.1 4/1.1 4/2.1

2/1.2 2/2.2 4/1.2 4/2.2
5. 802.1Q es una norma IEEE que define los mecanismos para implementar redes LAN virtuales enlazadas y los formatos de trama Ethernet utilizados para
indicar la pertenencia a una VLAN mediante etiquetas VLAN.

Capítulo 1 Arquitectura de ScreenOS Enrutadores virtuales
ENRUTADORES VIRTUALES
Un enrutador virtual (VR) funciona como un enrutador. Dispone de sus propias interfaces y de sus propias tablas de
enrutamiento unicast y multicast. En ScreenOS, un dispositivo NetScreen admite dos enrutadores virtuales
predefinidos. Esto permite al dispositivo NetScreen mantener dos tablas de enrutamiento unicast y multicast
independientes y ocultar la información de enrutamiento de un enrutador al otro. Por ejemplo, untrust-vr se suele
utilizar para la comunicación con interlocutores sin confianza, por lo que no contiene información de enrutamiento
para las zonas protegidas. La información de enrutamiento de las zonas protegidas se actualiza por medio de
trust-vr. Por lo tanto, no es posible capturar información interna de la red mediante la extracción no autorizada de
rutas de untrust-vr.
Dominio de enrutamiento trust-vr Dominio de enrutamiento untrust-vr
Finance
Untrust
Trust
Eng DMZ Nota: El icono del castillo representa

una interfaz en una zona de
seguridad.
Reenvío de rutas
Cuando hay dos enrutadores virtuales en un dispositivo NetScreen, el tráfico no se reenvía automáticamente entre
las zonas que se encuentran en distintos VR, incluso aunque existan directivas que permitan el tráfico. Si desea
intercambiar tráfico de datos entre enrutadores virtuales, tendrá que exportar las rutas entre los VR o configurar una
ruta estática en un VR que defina el otro VR como siguiente salto ("next-hop"). Para más información sobre el uso
de enrutadores virtuales, consulte el Volumen 6 “Enrutamiento”.

Capítulo 1 Arquitectura de ScreenOS Directivas
DIRECTIVAS
Los dispositivos NetScreen aseguran la red inspeccionando, y luego permitiendo o denegando, todo intento de
conexión que necesite pasar de una zona de seguridad a otra.
6
De forma predeterminada, un dispositivo NetScreen denegará todo el tráfico de datos en todos los sentidos . La
creación de directivas permite controlar el flujo de tráfico entre zonas definiendo qué tipo de tráfico puede pasar de
los orígenes a los destinos especificados y cuándo. En el nivel más permisivo, es posible permitir que todo tipo de
tráfico pase de cualquier origen en una zona a cualquier destino en el resto de zonas sin ninguna restricción en el
tiempo. En el nivel más restrictivo, se puede crear una directiva que sólo permita un tipo de tráfico entre un host
determinado en una zona y otro en otra zona durante un periodo de tiempo programado.
Acceso a Internet permisivo: cualquier Acceso a Internet restrictivo: servicio SMTP desde
servicio desde cualquier punto de la zona un servidor de correo en la zona Trust hacia un
Trust hacia cualquier punto de la zona servidor de correo en la zona Untrust de 05:00 a
Untrust en cualquier momento 19:00 horas
Zona Zona
Untrust Untrust
Zona Zona
Trust Trust
6. Ciertos dispositivos NetScreen se suministran con una directiva predeterminada que permite cualquier tráfico saliente de la zona Trust a la zona Untrust,
pero rechaza todo el tráfico procedente de la zona Untrust y dirigido a la zona Trust.

Cada vez que un paquete intenta pasar de una zona a otra, o entre dos interfaces enlazadas a la misma zona, el
dispositivo NetScreen comprueba si en su lista de directivas existe alguna que permita ese tipo de tráfico (consulte
“Listas de conjuntos de directivas” en la pàgina 311). Para que el tráfico pueda pasar de una zona de seguridad a
otra (p. ej., de la zona A a la zona B), es necesario configurar una directiva que permita que la zona A envíe tráfico
a la zona B. Para que el tráfico pueda pasar en sentido inverso, se debe configurar otra directiva que permita el
tráfico de la zona B a la zona A. Para que cualquier tipo de tráfico pase de una zona a otra, debe haber una
directiva que lo permita. Asimismo, cuando está habilitado el bloqueo intrazonal (bloqueo del interior de una zona),
deberá existir una directiva que permita que el tráfico pase de una interfaz a otra dentro de esa misma zona.
Dominio de enrutamiento trust-vr Dominio de enrutamiento untrust-vr

Finance
Untrust
Trust Motor de
directivas
Eng DMZ
Nota: Las líneas negras representan el
tráfico entre zonas de seguridad.
Reenvío de rutas
Nota: Para obtener más información sobre las directivas, consulte el Capítulo 6, “Directivas”.

Si configura el enrutamiento multicast en un dispositivo NetScreen, puede que tenga que configurar directivas
multicast. De forma predeterminada, los dispositivos NetScreen no permiten tráfico de control multicast entre zonas.
Por tráfico de control multicast se entienden los mensajes transmitidos por protocolos multicast, tales como el
multicast independiente del protocolo (“Protocol Independent Multicast” o PIM). Las directivas multicast solamente
controlan el flujo del tráfico de control multicast. Para permitir el tráfico de datos (tanto unicast como multicast) entre
zonas, debe configurar directivas de cortafuegos. (Para obtener más información sobre directivas multicast,
consulte “Directivas multicast” en la pàgina 6 -208).

Capítulo 1 Arquitectura de ScreenOS VPNs
VPNS
ScreenOS dispone de varias opciones para la configuración de redes privadas virtuales (VPN). Los dos tipos más
importantes son:
• VPN basada en rutas: mediante una consulta de rutas se determina qué tráfico encapsulará el dispositivo
NetScreen. Las directivas permiten o deniegan el tráfico hacia el destino especificado en la ruta. Si la
directiva permite el tráfico y la ruta hace referencia a una interfaz de túnel asociada a un túnel VPN, el
dispositivo NetScreen también encapsulará dicho tráfico. Esta configuración gestiona por separado la
aplicación de directivas y la aplicación de túneles VPN. Una vez configurados, estos túneles estarán
disponibles como recursos para asegurar el tráfico que circula entre una zona de seguridad y otra.
• VPN basada en directivas: mediante una consulta de directivas se determina qué tráfico encapsulará el
dispositivo NetScreen cuando la directiva haga referencia a un túnel VPN determinado y se especifique
“tunnel” como acción.
Una VPN basada en rutas es la opción adecuada para configuraciones VPN punto a punto, ya que es posible
aplicar múltiples directivas al tráfico que pasa a través de un único túnel VPN. La VPN basada en directivas resulta
adecuada para configuraciones VPN de acceso telefónico, ya que el cliente de acceso telefónico probablemente no
dispone de una dirección IP interna hacia la que establecer una ruta.
En las siguientes instrucciones se muestran los principales pasos a seguir para configurar una VPN basada en
rutas:
1. Cuando configure el túnel VPN (p. ej., vpn-to-SF , donde SF es el destino o entidad final), especifique una
interfaz física o una subinterfaz en el dispositivo local como interfaz de salida. (El interlocutor remoto
deberá utilizar la dirección IP de esta interfaz para configurar su puerta de enlace remota.)
7
2. Cree una interfaz de túnel (p. ej., tunnel.1 ) y asóciela a una zona de seguridad .
3. Asocie la interfaz de túnel tunnel.1 al túnel VPN vpn-to-SF .
4. Para dirigir el tráfico a través de este túnel, configure una ruta indicando que el tráfico hacia SF debe utilizar
tunnel.1 .
7. No es necesario asociar la interfaz de túnel a la misma zona a la que está destinado el tráfico de VPN. El tráfico hacia cualquier zona puede acceder a una
interfaz de túnel siempre que haya alguna ruta que apunte a esa interfaz.

Capítulo 1 Arquitectura de ScreenOS VPNs
Zona de origen Motor de Interfaz Túnel VPN Zona de destino

directivas de túnel
Tabla de
enrutamiento
----------------
---------------- tunnel.1 vpn-to-SF
Paquete enviado ---------------- Paquete entrando
Llegados a este punto, el túnel está listo para el tráfico dirigido a SF . Ahora puede crear entradas en la libreta de
direcciones, como “Trust LAN” (10.1.1.0/24) y “SF LAN” (10.2.2.0/24), y configurar directivas para permitir o
bloquear distintos tipos de tráfico desde un origen especificado, como “Trust LAN”, y hacia un destino especificado,
como “SF LAN”.
El dispositivo NetScreen local enruta el tráfico desde la zona Trust a “SF LAN”, que se encuentra
en la zona Untrust, a través de la interfaz tunnel.1. Como la interfaz tunnel.1 está asociada al túnel
VPN “vpn-to-SF”, el dispositivo NetScreen encripta el tráfico y lo envía a través de ese túnel al
interlocutor remoto.
Dominio de enrutamiento untrust-vr
Para llegar a Utilice

Zona Untrust SF LAN
1.1.1.0/24 eth1/2 Interfaz de salida 10.2.2.0/24
eth1/2, 1.1.1.1/24
10.2.2.0/24 tunnel.1
0.0.0.0/0 1.1.1.250 Interfaz:
tunnel.1
Dominio de enrutamiento trust-vr Túnel VPN

Dispositivo vpn-to-SF
Puerta de enlace
Para llegar a Utilice predeterminada:
1.1.1.250
10.1.1.0/24 eth3/2 Zona Trust
eth3/2–10.1.1.1/24
0.0.0.0/0 untrust-vr
Nota: Para obtener información detallada sobre las VPN, consulte el Volumen 5, “VPNs”.

Capítulo 1 Arquitectura de ScreenOS Sistemas virtuales
SISTEMAS VIRTUALES
Ciertos dispositivos NetScreen pueden trabajar con sistemas virtuales (vsys). Un sistema virtual es una subdivisión
del sistema principal que para el usuario aparece como una entidad independiente. Los sistemas virtuales se
encuentran separados del sistema raíz y entre sí dentro de un mismo dispositivo NetScreen. La aplicación de
ScreenOS a los sistemas virtuales implica la coordinación de tres componentes principales: zonas, interfaces y
enrutadores virtuales. La siguiente ilustración representa conceptualmente cómo ScreenOS integra estos
componentes en los niveles raíz y de sistema virtual.
Nota: El icono del castillo representa una

interfaz en una zona de seguridad.
trust-vr
untrust-vr Finance
DMZ
Mail Trust Eng
Interfaz compartida
por vsys1 y raíz
sistema raíz vsys1-vr
Trust-vsys1
Untrust Subinterfaz vsys1
dedicada para
vsys2 vsys2-vr
vsys2
Trust-vsys2
vsys3
Interfaz física
dedicada para vsys3-vr
vsys3
Trust-vsys3
Nota: Para obtener más información sobre sistemas virtuales y la aplicación de zonas, interfaces y enrutadores
virtuales en el contexto de sistemas virtuales, consulte el Volumen 9, “Sistemas virtuales”.

Capítulo 1 Arquitectura de ScreenOS Secuencia de flujo de paquetes
SECUENCIA DE FLUJO DE PAQUETES

En ScreenOS, la secuencia de flujo de un paquete entrante ocurre según se muestra a continuación.
Paquete 1 2 3 4 5 6 7 8 9
entrante
Filtro
SCREEN
Consulta de
sesiones ( MIP/VIP
IP de )
Consulta
de rutas
Consulta de
directivas ( NAT-Dst
NAT-Src )
y/o Crear
sesión
Realizar
operación
host
Interfaz Si el paquete no Tabla de reenvíos Lista de directivas Tabla de sesiones

de entrada coincide con una 10.10.10.0/24 eth1/1 src dst service action id 977 vsys id 0, flag 000040/00,
0.0.0.0/0 untrust-vr pid -1, did 0, time 180
sesión existente, lleve a 13 (01) 10.10.10.1/1168 ->
…
cabo los pasos 4 a 9. 211.68.1.2/80, 6, 002be0c0066b,
subif 0, tun 0
Si lo hace, vaya
…
directamente al paso 9.
Zona Interfaz de destino Permit = reenviar paquete
de origen –y– Deny = descartar paquete
zona de destino Reject = descartar el
Zonas paquete y enviar TCP
Si hay tráfico de red, de seguridad RST al origen
zona de origen = Tunnel = utilizar el túnel
zona de seguridad a especificado para la
la que está asociada encriptación de VPN
la interfaz o
subinterfaz.
Si zona de destino = zona de seguridad, utilizar
Si hay tráfico VPN a esa zona para la consulta de directivas.
la interfaz de túnel
asociada al túnel
VPN, zona de
origen = zona de
seguridad donde está
configurado el túnel.
Si hay tráfico VPN a
la interfaz de túnel en Si zona de destino = zona del túnel, utilizar su
una zona de túnel, zona portadora para la consulta de directivas.
zona de origen =
zona portadora. Zona
del tunnel

1. El módulo de interfaz identifica la interfaz entrante y, por lo tanto, la zona de origen a la que está asociada.
La determinación de la zona de origen se basa en los criterios siguientes:
– Si el paquete no está encapsulado, la zona de origen es la zona de seguridad a la que la interfaz o
subinterfaz entrante está asociada.
– Si el paquete está encapsulado y la interfaz de túnel está asociada a un túnel VPN, la zona de origen
es la zona de seguridad en la que está configurada la interfaz de túnel.
– Si el paquete está encapsulado y la interfaz de túnel se encuentra en una zona de túnel, la zona de
origen es la zona portadora (zona de seguridad que porta el túnel) correspondiente a esa zona de
túnel.
2. Si hay habilitadas opciones SCREEN para la zona de origen, el dispositivo NetScreen activa el módulo
SCREEN en este momento. La comprobación de SCREEN puede producir uno de los tres resultados
siguientes:
– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para bloquear el
paquete correspondiente, el dispositivo NetScreen descarta el paquete y genera una entrada en el
registro de eventos.
– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para registrar el
evento pero no bloquear el paquete, el dispositivo NetScreen registra el evento en la lista de
contadores SCREEN para la interfaz de entrada y procede al paso siguiente.
– Si el mecanismo SCREEN no detecta ningún comportamiento anómalo, el dispositivo NetScreen
procede al paso siguiente.
3. El módulo de sesiones realiza una consulta de sesión para comprobar si el paquete coincide con una
sesión existente.
Si el paquete no coincide con ninguna sesión existente, el dispositivo NetScreen ejecuta “First Packet
Processing”, un procedimiento que implica los siguientes pasos 4 a 9.
Si el paquete coincide con una sesión existente, el dispositivo NetScreen ejecuta “Fast Processing”,
utilizando la información disponible en la entrada de sesiones existente para procesar el paquete. El
procesamiento rápido (“Fast Processing”) omite los pasos 4 a 8 porque la información que generan ya se
obtuvo durante el procesamiento del primer paquete de la sesión.

4. Si se utiliza una dirección IP asignada (MIP) o dirección IP virtual (VIP), el módulo de asignación de
direcciones resuelve la dirección MIP o VIP de modo que la tabla de enrutamiento pueda buscar la
dirección real del host.
5. La operación de consulta de la tabla de rutas averigua qué interfaz conduce a la dirección de destino. Al
hacerlo, el módulo de interfaz identifica la zona de destino a la que está asociada esa interfaz.
La determinación de la zona de destino se basa en los criterios siguientes:
– Si la zona de destino es una zona de seguridad, esa zona se utiliza para la consulta de directivas.
– Si la zona de destino es una zona de túnel, se utiliza la zona portadora correspondiente para la
consulta de directivas.
– Si la zona de destino es igual a la zona de origen y el bloqueo intrazonal está inhabilitado para esa
zona, el dispositivo NetScreen omite los pasos 6 y 7 y crea una sesión (paso 8). Si el bloqueo
intrazonal está activado, el dispositivo NetScreen descarta el paquete.
6. El motor de directivas busca en las listas de conjuntos de directivas una directiva entre las direcciones de
las zonas de origen y de destino identificadas.
La acción configurada en la directiva determina lo que debe hacer el cortafuegos de NetScreen con el
paquete:
– Si la acción es permit , el dispositivo NetScreen decide remitir el paquete a su destino.
– Si la acción es deny , el dispositivo NetScreen decide descartar el paquete.
– Si la acción es reject , el dispositivo NetScreen decide descartar el paquete y, si el protocolo es TCP,
enviar una señal de restablecimiento (RST) a la dirección IP de origen.
– Si la acción es tunnel , el dispositivo NetScreen decide remitir el paquete al módulo VPN, que
encapsula el paquete y lo transmite utilizando los ajustes especificados del túnel VPN.
7. Si en la directiva está especificado que se traduzcan las direcciones de destino (NAT-dst), el módulo NAT
traduce la dirección de destino original del encabezado del paquete IP a otra dirección.
Si está especificada la traducción de direcciones de origen (NAT basada en interfaz o NAT-src basada en
directivas), el módulo NAT traduce la dirección de origen del encabezado del paquete IP antes de
reenviarlo a su destino o al módulo VPN.
(Si en la misma directiva están especificados tanto NAT-dst como NAT-src, el dispositivo NetScreen realiza
primero NAT-dst y luego NAT-src).

8. El módulo de sesiones crea una nueva entrada en la tabla de sesiones que contiene los resultados de los
pasos 1 a 7.
Para procesar los paquetes subsiguientes de la misma sesión, el dispositivo NetScreen utiliza la
información mantenida en la entrada de la sesión.
9. El dispositivo NetScreen realiza la operación especificada en la sesión.
Algunas operaciones típicas son la traducción de direcciones de origen, la selección y encriptación del túnel
VPN, la desencriptación y el reenvío de paquetes.

Ejemplo (1ª parte): Empresa con seis zonas

Ésta es la primera de las cuatro partes de un ejemplo cuya finalidad es aclarar algunos de los conceptos expuestos
en las secciones anteriores. Si desea información sobre esta segunda parte, en la que las interfaces de cada zona
están ya establecidas, consulte “Ejemplo (2ª parte): Interfaces para seis zonas” en la pàgina 18. Aquí se configuran
las seis zonas siguientes de una empresa:
• Finance • Eng • Untrust

• Trust • Mail • DMZ
Las zonas Trust, Untrust y DMZ están preconfiguradas. Usted definirá las zonas Finance, Eng y Mail. De forma
predeterminada, las zonas definidas por el usuario se ubican en el dominio de enrutamiento trust-vr. Por lo tanto, no
es necesario especificar un enrutador virtual para las zonas Finance y Eng. Sin embargo, además de configurar la
zona Mail, también deberá especificar que se encuentre en el dominio de enrutamiento untrust-vr. Asimismo debe
8
transferir los enlaces de los enrutadores virtuales de las zonas DMZ y Untrust de trust-vr a untrust-vr .
Dominio de Dominio de
enrutamiento enrutamiento
trust-vr untrust-vr
Finance Mail
Trust Untrust
Eng DMZ
8. Para obtener más información sobre enrutadores virtuales y sus dominios de enrutamiento, consulte el Volumen 6, “Enrutamiento dinámico”.

WebUI
Network > Zones > New: Introduzca los siguientes datos y haga clic en OK :
Zone Name: Finance
Virtual Router Name: trust-vr
Zone Type: Layer 3: (seleccione)
Zone Name: Eng
Zone Name: Mail
Virtual Router Name: untrust-vr
Network > Zones > Edit (para Untrust): Seleccione untrust-vr en la lista desplegable “Virtual Router Name”
y haga clic en OK .
Network > Zones > Edit (para DMZ): Seleccione untrust-vr en la lista desplegable “Virtual Router Name” y
haga clic en OK .
CLI
set zone name finance
set zone name eng
set zone name mail
set zone mail vrouter untrust-vr
set zone untrust vrouter untrust-vr
set zone dmz vrouter untrust-vr
save

Ejemplo (2ª parte): Interfaces para seis zonas

Ésta es la segunda parte de un ejemplo fragmentado. Si desea ver la primera parte, en la que se configuran
las zonas, consulte “Ejemplo (1ª parte): Empresa con seis zonas” en la pàgina 16. Si desea ver la siguiente
parte, en la que se configuran enrutadores virtuales, consulte “Ejemplo (3ª parte): Dos dominios de
enrutamiento” en la pàgina 22. Esta parte del ejemplo demuestra cómo asociar interfaces a las zonas y
configurarlas con una dirección IP y diversas opciones de administración.
1.3.3.1/24
eth1/1
Finance
10.1.2.1/24 Mail
Etiqueta VLAN 1 1.4.4.1/24
eth3/2.1 Etiqueta VLAN 2
eth1/1.2
Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2 eth1/2
Eng DMZ
10.1.3.1/24 1.2.2.1/24
eth3/1 eth2/2

WebUI
1. Interfaz ethernet3/2
Network > Interfaces > Edit (para ethernet3/2): Introduzca los siguientes datos y haga clic en OK :
Zone Name: Trust
Static IP: (seleccione esta opción si es posible)
IP Address/Netmask: 10.1.1.1/24
Manageable: (seleccione)
Management Services: WebUI, Telnet, SNMP, SSH (seleccione)
Other Services: Ping (seleccione)
2. Interfaz ethernet3/2.1
Network > Interfaces > Sub-IF New: Introduzca los siguientes datos y haga clic en OK :
Interface Name: ethernet3/2.1
Zone Name: Finance
VLAN Tag: 1
Zone Name: Eng

Zone Name: Mail
Network > Interfaces > Sub-IF New: Introduzca los siguientes datos y haga clic en OK :
Interface Name: ethernet1/1.2
Zone Name: Mail
VLAN Tag: 2
Zone Name: Untrust
Manageable: (seleccione)
Management Services: SNMP (seleccione)
Zone Name: DMZ
Static IP: (seleccione)

CLI
set interface ethernet3/2 zone trust
set interface ethernet3/2 ip 10.1.1.1/24
set interface ethernet3/2 manage ping
set interface ethernet3/2 manage webui
set interface ethernet3/2 manage telnet
set interface ethernet3/2 manage snmp
set interface ethernet3/2 manage ssh
set interface ethernet3/2.1 tag 1 zone finance
set interface ethernet3/2.1 ip 10.1.2.1/24
set interface ethernet3/2.1 manage ping
set interface ethernet3/1 zone eng
set interface ethernet3/1 manage ping
set interface ethernet1/1 zone mail
set interface ethernet1/1.2 tag 2 zone mail
set interface ethernet1/1.2 ip 1.4.4.1/24
set interface ethernet1/2 zone untrust
set interface ethernet1/2 manage snmp
set interface ethernet2/2 zone dmz
save

Ejemplo (3ª parte): Dos dominios de enrutamiento

Ésta es la tercera parte de un ejemplo fragmentado. Si desea ver la parte anterior, en la que se definen las
interfaces para las diferentes zonas de seguridad, consulte “Ejemplo (2ª parte): Interfaces para seis zonas” en la
pàgina 18. Si desea ver la parte siguiente, en la que se establecen las directivas, consulte “Ejemplo (4ª parte):
Directivas” en la pàgina 25. En este ejemplo solamente se configura una ruta para la puerta de enlace
predeterminada a Internet. Las otras rutas son creadas automáticamente por el dispositivo NetScreen al generar las
direcciones IP de las interfaces.
Dominio de 1.3.3.1/24 Dominio de

enrutamiento eth1/1, ruta enrutamiento
trust-vr untrust-vr
Finance
10.1.2.1/24 Mail
etiqueta VLAN 1
eth3/2.1, NAT
1.4.4.1/24
Etiqueta VLAN 2
eth1/1.2, ruta
A
Internet
Trust Untrust
10.1.1.1/24 1.1.1.1/24
eth3/2, NAT eth1/2, ruta
1.1.1.254
Eng DMZ
10.1.3.1/24 1.2.2.1/24
eth3/1, NAT eth2/2, ruta
Reenvío de
rutas

WebUI
Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK :
Network Address/Netmask: 0.0.0.0/0
Next Hop Virtual Router Name: (seleccione); untrust-vr
Network > Routing > Routing Entries > untrust-vr New: Introduzca los siguientes datos y haga clic en OK :
Gateway: (seleccione)
Interface: ethernet1/2
Gateway IP Address: 1.1.1.254
CLI
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface eth1/2 gateway 1.1.1.254
save

El dispositivo NetScreen crea automáticamente las rutas siguientes (en negro):
trust-vr
Para llegar a: Utilizar interfaz: Utilizar puerta de
enlace/Vrouter:
0.0.0.0/0 n/a untrust-vr
10.1.3.0/24 eth3/1 0.0.0.0
10.1.1.0/24 eth3/2 0.0.0.0
10.1.2.0/24 eth3/2.1 0.0.0.0
untrust-vr Nota: Éstas son las

únicas entradas
Para llegar a: Utilizar interfaz: Utilizar puerta de configuradas por
enlace/Vrouter: el usuario.
1.2.2.0/24 eth2/2 0.0.0.0

1.1.1.0/24 eth1/2 0.0.0.0
1.4.4.0/24 eth1/1.2 0.0.0.0
1.3.3.0/24 eth1/1 0.0.0.0
0.0.0.0/0 eth1/2 1.1.1.254

Ejemplo (4ª parte): Directivas

Ésta es la última parte de un ejemplo fragmentado. La parte anterior es “Ejemplo (3ª parte): Dos dominios de
enrutamiento” en la pàgina 22. En esta parte del ejemplo se muestra cómo configurar nuevas directivas.
Finance Mail
Motor de
Trust Untrust
directivas
Eng DMZ
Reenvío de rutas
Para que este ejemplo funcione, antes de comenzar a configurar nuevas directivas es necesario crear nuevos
grupos de servicios.
Nota: Cuando se crea una zona, el dispositivo NetScreen crea automáticamente la dirección Any para todos los
hosts existentes en esa zona. Este ejemplo utiliza la dirección Any para los hosts.

WebUI
1. Grupos de servicios
Objects > Services > Groups > New: Introduzca los siguientes datos y haga clic en OK :
Group Name: Mail-Pop3
Seleccione Mail y utilice el botón << para mover el servicio de la columna
“Available Members” a la columna “Group Members”.
Seleccione Pop3 y utilice el botón << para mover el servicio de la columna
Objects > Services > Groups > New: Introduzca los siguientes datos y haga clic en OK :
Group Name: HTTP-FTPGet
Seleccione HTTP y utilice el botón << para mover el servicio de la columna
Seleccione FTP-Get y utilice el botón << para mover el servicio de la
columna “Available Members” a la columna “Group Members”.
2. Directivas
Policies > (From: Finance, To: Mail) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), Any
Destination Address:
Service: Mail-Pop3
Action: Permit

Policies > (From: Trust, To: Mail) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: Mail-Pop3
Action: Permit
Policies > (From: Eng, To: Mail) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: Mail-Pop3
Action: Permit
Policies > (From: Untrust, To: Mail) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: Mail
Action: Permit

Policies > (From: Finance, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: HTTP-FTPGet
Action: Permit
Policies > (From: Finance, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Action: Permit
Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Action: Permit

Policies > (From: Trust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Action: Permit
Policies > (From: Eng, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Action: Permit
Policies > (From: Eng, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: FTP-Put
Action: Permit

Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Action: Permit
CLI
set group service mail-pop3 add mail
set group service mail-pop3 add pop3
set group service http-ftpget add http
set group service http-ftpget add ftp-get
2. Directivas
set policy from finance to mail any any mail-pop3 permit
set policy from trust to mail any any mail-pop3 permit
set policy from eng to mail any any mail-pop3 permit
set policy from untrust to mail any any mail permit
set policy from finance to untrust any any http-ftpget permit
set policy from finance to dmz any any http-ftpget permit
set policy from trust to untrust any any http-ftpget permit
set policy from trust to dmz any any http-ftpget permit
set policy from eng to untrust any any http-ftpget permit
set policy from eng to dmz any any http-ftpget permit
set policy from eng to dmz any any ftp-put permit
set policy from untrust to dmz any any http-ftpget permit
save

Capítulo 2
Zonas
2
Una zona puede ser un segmento del espacio de red al que se aplican medidas de seguridad (zona de seguridad),
un segmento lógico que tiene asociada una interfaz de túnel VPN (zona de túnel), o una entidad física o lógica que
realiza una función específica (zona de función). Este capítulo examina cada uno de los tipos de zonas, poniendo
un especial énfasis en la zona de seguridad, y se compone de las secciones siguientes:
• “Zonas de seguridad” en la pàgina 34
– “Zona Global” en la pàgina 34
– “Opciones SCREEN” en la pàgina 34
• “Zonas de túnel” en la pàgina 35
• “Configuración de zonas de seguridad y zonas de túnel” en la pàgina 37
– “Creación de una zona” en la pàgina 37
– “Modificación de una zona” en la pàgina 38
– “Eliminación de una zona” en la pàgina 39
• “Zonas de función” en la pàgina 40
– “Zona Null” en la pàgina 40
– “Zona MGT” en la pàgina 40
– “Zona HA” en la pàgina 40
– “Zona Self” en la pàgina 40
– “Zona VLAN” en la pàgina 40
• “Modos de puerto” en la pàgina 41
– “Establecimiento de los modos de puertos” en la pàgina 47
– “Zonas en los modos “Home-Work” y “Combined Port”” en la pàgina 49

Capítulo 2 Zonas
La primera vez que se inicia un dispositivo NetScreen puede verse una serie de zonas preconfiguradas. En WebUI,
haga clic en Network > Zones en la columna de menús de la izquierda. En CLI, utilice el comando get zone.

Capítulo 2 Zonas
Resultado del comando get zone :
Los sistemas raíz y virtual

ns500-> get zone comparten estas zonas.
Total of 13 zones in vsys root
------------------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root Estas zonas ni tienen ni
1 Untrust Sec(L3) Shared trust-vr ethernet1/2 Root pueden tener una interfaz.
2 Trust Sec(L3) trust-vr ethernet3/2 Root
3 DMZ Sec(L3) trust-vr ethernet2/2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr mgt Root
6 HA Func trust-vr ha1 Root Estas zonas proporcionan
10 Global Sec(L3) trust-vr null Root compatibilidad con versiones
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root anteriores al actualizar de una
12 V1-Trust Sec(L2) trust-vr v1-trust Root versión anterior a ScreenOS
13 V1-DMZ Sec(L2) trust-vr v1-dmz Root 3.1.0. Las 3 superiores para
14 VLAN Func trust-vr vlan1 Root dispositivos en modo NAT o
16 Untrust-Tun Tun trust-vr null Root Route, los 3 inferiores para
------------------------------------------------------------------------ dispositivos en modo
transparente.
Los números de identificación de De forma predeterminada, las interfaces de túnel VPN están
zona 7 a 9 y 15 están reservados asociadas a la zona Untrust-Tun, cuya zona portadora es la zona
para uso futuro. Untrust. (Durante la actualización, los túneles existentes se
asocian a la zona Untrust-Tun).
Las zonas preconfiguradas mostradas arriba se pueden agrupar en tres tipos diferentes:
Zonas de seguridad: Untrust, Trust, DMZ, Global, V1-Untrust, V1-Trust, V1-DMZ
Zona de túnel: Untrust-Tun
Zonas de función: Null, Self, MGT, HA, VLAN

Capítulo 2 Zonas Zonas de seguridad
ZONAS DE SEGURIDAD
En un solo dispositivo NetScreen se pueden configurar varias zonas de seguridad, dividiendo la red en segmentos
a los que se pueden aplicar diversas opciones de seguridad para satisfacer las necesidades de cada segmento.
Deben definirse como mínimo dos zonas de seguridad, básicamente para proteger un área de la red de la otra. En
algunas plataformas de NetScreen se pueden definir muchas zonas de seguridad, lo que refina aún más la
granularidad del diseño de seguridad de la red, evitando la necesidad de distribuir múltiples dispositivos de
seguridad para conseguir el mismo fin.
Zona Global
Puede identificar una zona de seguridad porque tiene una libreta de direcciones y se puede hacer referencia a ella
en directivas. La zona Global satisface estos criterios. Sin embargo, le falta un elemento del que sí disponen las
demás zonas de seguridad: una interfaz. La zona Global sirve como área de almacenamiento de direcciones IP
asignadas (MIP) y direcciones IP virtuales (VIP). La dirección predefinida “Any” de la zona Global puede aplicarse a
todas las MIPs, VIPs y a otras direcciones definidas por el usuario establecidas en la zona Global. Dado que el
tráfico dirigido a estas direcciones se asigna a otras direcciones, la zona Global no requiere una interfaz para que el
tráfico fluya a través de ella.
La zona Global también contiene direcciones para su utilización en directivas globales. Para obtener más
información acerca de directivas globales, consulte “Directivas globales” en la pàgina 310).
Nota: Cualquier directiva que utilice la zona Global como su destino no puede admitir NAT ni asignación de tráfico.
Opciones SCREEN
Un cortafuegos NetScreen asegura una red inspeccionando, y luego permitiendo o denegando, todo intento de
conexión que necesite pasar de una zona de seguridad a otra. Por cada zona de seguridad y zona MGT, puede
habilitar un conjunto de opciones SCREEN predefinidas que detecten y bloqueen los diversos tipos de tráfico que el
dispositivo NetScreen identifica como potencialmente dañinos. Para obtener más información sobre el gran número
de opciones SCREEN disponible, consulte el Volumen 4, “Mecanismos de detección de ataques y defensa”.

Capítulo 2 Zonas Zonas de túnel
ZONAS DE TÚNEL
Una zona de túnel es un segmento lógico que contiene al menos una interfaz de túnel. Las zonas de túnel están
conceptualmente relacionadas con zonas de seguridad en una relación “padre-hijo”. Las zonas de seguridad que
actúan como “padre”, que también pueden imaginarse como zonas portadoras, proporcionan protección de
cortafuegos al tráfico encapsulado. La zona de túnel proporciona el encapsulado y desencapsulado de paquetes, y
también puede proporcionar servicios NAT basados en directivas, ya que admiten interfaces de túnel con
direcciones IP y máscaras de red que pueden contener direcciones IP asignadas (MIP) y dinámicas (DIP).
El dispositivo NetScreen utiliza la información de enrutamiento de la zona portadora para dirigir el tráfico al punto
final del túnel. La zona de túnel predeterminada es Untrust-Tun, asociada a la zona Untrust. Puede crear otras
zonas de túnel y asociarlas a otras zonas de seguridad, con un máximo de una zona de túnel por zona portadora y
por sistema virtual1.
De forma predeterminada, una zona de túnel se encuentra en el dominio de enrutamiento trust-vr, pero también
puede mover una zona de túnel a otro dominio de enrutamiento.
La interfaz de la zona de seguridad que

Zona de seguridad contiene la zona de túnel proporciona la
protección de cortafuegos para el tráfico
encapsulado.
Zona de túnel
Tráfico hacia o desde un túnel VPN Túnel VPN
Interfaz Interfaz de la
La interfaz de túnel, que cuando está de túnel zona de
asociada a una zona de túnel debe tener seguridad
una dirección IP y una máscara de red,
admite NAT basada en directivas para el
tráfico VPN pre-encapsulado y
post-desencapsulado.
El tráfico saliente penetra en la zona de túnel a través de la interfaz de túnel, es encapsulado y sale a través de la interfaz de la zona de seguridad.
El tráfico entrante accede a través de la interfaz de la zona de seguridad, es desencapsulado en la zona de túnel, y sale a través de la interfaz de túnel.
Al actualizar una versión de ScreenOS anterior a 3.1.0, las interfaces de túnel existentes se asocian de forma
predeterminada a la zona de túnel preconfigurada Untrust-Tun, que es un “hijo” de la zona de seguridad
preconfigurada de Untrust. Puede asociar múltiples zonas de túnel a la misma zona de seguridad; sin embargo, no
puede enlazar una zona de túnel a otra zona de túnel.
1. El sistema raíz y todos los sistemas virtuales pueden compartir la zona Untrust. Sin embargo, cada sistema tiene su propia zona Untrust-Tun separada.

Capítulo 2 Zonas Zonas de túnel
Ejemplo: Asociar una interfaz de túnel a una zona de túnel

En este ejemplo creará una interfaz de túnel y la llamará tunnel.3. La asociará a la zona Untrust-Tun y le asignará la
dirección IP 3.3.3.3/24. Seguidamente definirá una dirección IP asignada (MIP) en tunnel.3, traduciendo 3.3.3.5 a
10.1.1.5, que es la dirección de un servidor en la zona Trust. Tanto la zona Untrust, que es la zona portadora de la
zona Untrust-Tun, como la zona Trust están en el dominio de enrutamiento trust-vr.
WebUI
1. Interfaz de túnel
Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga clic en OK :
Tunnel Interface Name: tunnel.3
Zone (VR): Untrust-Tun (trust-vr)
Fixed IP: (seleccione)
2. MIP
Network > Interfaces > Edit (para tunnel.3) > MIP > New: Introduzca los siguientes datos y haga clic en OK :
Mapped IP: 3.3.3.5
Netmask: 255.255.255.255
Host IP Address: 10.1.1.5
Host Virtual Router Name: trust-vr
CLI
1. Interfaz de túnel
set interface tunnel.3 zone Untrust-Tun
set interface tunnel.3 ip 3.3.3.3/24
2. MIP
set interface tunnel.3 mip 3.3.3.5 host 10.1.1.5
save

Capítulo 2 Zonas Configuración de zonas de seguridad y zonas de túnel
CONFIGURACIÓN DE ZONAS DE SEGURIDAD Y ZONAS DE TÚNEL

La creación, modificación y eliminación de zonas de seguridad y zonas de túnel de capa 3 o capa 2 son
procedimientos bastante similares.
Nota:No se pueden eliminar zonas de seguridad predefinidas ni la zona de túnel predefinida, aunque sí se pueden
editar.
Creación de una zona

Para crear zonas de seguridad de capa 3 (“Layer 3”) o capa 2 (“Layer 2”), o una zona de túnel, utilice WebUI o CLI:
WebUI
Zone Name: Escriba un nombre para la zona2.
Virtual Router Name: Seleccione el enrutador virtual en cuyo dominio de
enrutamiento desea ubicar la zona.
Zone Type: Seleccione Layer 3 para crear una zona a la que podrá asociar
interfaces en el modo NAT o Route. Seleccione Layer 2 para crear una
zona a la que pueda asociar interfaces en modo transparente. Seleccione
Tunnel Out Zone cuando cree una zona de túnel y la asocie a una zona
portadora, y luego seleccione una zona portadora específica en la lista
desplegable.
Block Intra-Zone Traffic: Seleccione esta opción para bloquear el tráfico entre
hosts de la misma zona de seguridad. De forma predeterminada, los
bloqueos intrazonales están inhabilitados.
2. El nombre de una zona de seguridad de capa 2 (“Layer 2”) debe comenzar con “L2-”; por ejemplo, “L2-Corp” o “L2-XNet”.

CLI
3
set zone name zone [ l2 vlan_id_num | tunnel sec_zone ]
set zone zone block
set zone zone vrouter name_str
Modificación de una zona

Para modificar el nombre de una zona de seguridad o zona de túnel, o para cambiar la zona portadora de una zona
4
de túnel, primero debe eliminar la zona y luego crearla de nuevo con los cambios. Puede cambiar la opción de
5
bloqueo intrazonal y el enrutador virtual en una zona existente.
WebUI
1. Modificación del nombre de una zona
Network > Zones: Haga clic en Remove (para la zona de seguridad o zona de túnel cuyo nombre desea
cambiar, o para la zona de túnel cuya zona portadora desea cambiar).
Cuando aparezca la confirmación para eliminar, haga clic en Yes .
Network > Zones > New: Introduzca los ajustes de zona con sus cambios y haga clic en OK .
2. Cambio de la opción de bloqueo intrazonal o el enrutador virtual

Network > Zones > Edit (para las zonas que desea modificar): Introduzca los siguientes datos y haga clic en
OK :
Virtual Router Name: En la lista desplegable, seleccione el enrutador virtual a
cuyo dominio de enrutamiento desea mover la zona.
Block Intra-Zone Traffic: Para habilitar, active la casilla de verificación. Para
desactivar la opción, desactive la casilla.
3. Al crear una zona de seguridad de capa 2 (“Layer 2”), el número de identificación VLAN-ID debe ser 1 (para VLAN1).
4. Antes de poder eliminar una zona, primero debe desasociar todas las interfaces asociadas a ella.
5. Antes de cambiar el enrutador virtual de una zona, debe eliminar cualquier interfaz asociada a la misma.

CLI
1. Modificación del nombre de una zona
unset zone zone
set zone name zone [ l2 vlan_id_num | tunnel sec_zone ]
2. Cambio de la opción de bloqueo intrazonal o el enrutador virtual
{ set | unset } zone zone block
set zone zone vrouter name_str
Eliminación de una zona

6
Para eliminar una zona de seguridad o zona de túnel, ejecute cualquiera de los siguientes procedimientos :
WebUI
Network > Zones: Haga clic en Remove (para la zona que desee eliminar).
Cuando aparezca la confirmación para eliminar, haga clic en Yes .
CLI
unset zone zone
6. Antes de poder eliminar una zona, primero debe desasociar todas las interfaces asociadas a ella. Para desasociar una interfaz de una zona, consulte
“Asociación de una interfaz a una zona de seguridad” en la pàgina 66.

Capítulo 2 Zonas Zonas de función
ZONAS DE FUNCIÓN
Las cinco zonas de función son Null, MGT, HA, Self y VLAN. Cada zona existe con un solo propósito, según se
explica más abajo.
Zona Null
Esta zona sirve como almacenamiento temporal para cualquier interfaz que no esté asociada a ninguna otra zona.
Zona MGT
Esta zona contiene la interfaz de administración de fuera de banda, MGT. Puede establecer opciones de
cortafuegos en esta zona para proteger la interfaz de administración contra diversos tipos de ataques. Para obtener
más información sobre opciones de cortafuegos, consulte el Volumen 4, “Mecanismos de detección de ataques y
defensa”.
Zona HA
Esta zona contiene las interfaces de alta disponibilidad, HA1 y HA2. Aunque puede configurar interfaces para la
zona HA, la zona propiamente dicha no es configurable.
Zona Self
Esta zona contiene la interfaz para las conexiones de administración remotas. Cuando usted se conecta al
dispositivo NetScreen a través de HTTP, SCS o Telnet, se conecta a la zona Self.
Zona VLAN
Esta zona contiene la interfaz VLAN1, que se utiliza para administrar el dispositivo y terminar el tráfico VPN cuando
el dispositivo está en modo transparente. También puede establecer opciones de cortafuegos en esta zona para
proteger la interfaz VLAN1 de diversos ataques.

Capítulo 2 Zonas Modos de puerto
MODOS DE PUERTO
Puede seleccionar un modo de puerto para algunos dispositivos NetScreen. El modo de puerto establece
automáticamente diversas asociaciones de puertos, interfaces y de zona7 para el dispositivo. En los dispositivos
NetScreen-5XT y NetScreen-5GT puede configurar uno de los siguientes modos de puertos:
Advertencia: Al cambiar el modo de puertos, se elimina cualquier configuración existente en el dispositivo

NetScreen y es necesario reiniciar el sistema.
• El modo “Trust-Untrust” es el modo de puerto predeterminado. Este modo proporciona las siguientes
asociaciones de puerto, interfaz y zona:
– Asocia el puerto “Untrusted Ethernet” a la interfaz Untrust, asociada a la zona de seguridad Untrust
– Asocia el puerto “Modem” a la interfaz serie, que se puede asociar como interfaz de respaldo a la
zona de seguridad Untrust
– Asocia los puertos Ethernet 1 a 4 a la interfaz Trust, asociada a la zona de seguridad Trust
La interfaz Untrust es
la principal para la Interfaz
zona Untrust. Puede Untrust
asociar la interfaz Interfaz Trust
serie (mostrada en
gris) como interfaz de
respaldo a la zona
Untrust. Zona Trust
Zona Untrust
Nota: El asistente de configuración inicial (“Initial Configuration Wizard”) es ligeramente diferente en el

dispositivo NetScreen-5GT.
7. En el contexto de modos de puertos, puerto se refiere a una interfaz física en la parte posterior del dispositivo NetScreen. Para hacer referencia a un puerto
se utiliza su etiqueta: “Untrusted”, “1-4”, “Console” o “Modem”. El término interfaz se refiere a una interfaz lógica que se puede configurar con WebUI o CLI.
Cada puerto se puede asociar a una sola interfaz, pero a una interfaz se le pueden asociar múltiples puertos.

• El modo “Home-Work” asocia interfaces a la zona de seguridad Untrust y a las nuevas zonas de seguridad
“Home” y “Work”. Las zonas “Work” y “Home” permiten segregar usuarios y recursos en cada zona. En este
modo, las directivas predeterminadas permiten el flujo de tráfico y conexiones entre las zonas “Work” y
“Home”, pero no permiten tráfico de la zona “Home” a la zona “Work”. De forma predeterminada, no hay
ninguna restricción para el tráfico de la zona Home a la zona Untrust. Este modo proporciona las siguientes
asociaciones de puerto, interfaz y zona:
– Asocia los puertos Ethernet 1 y 2 a la interfaz ethernet1, asociada a la zona de seguridad Work
– Asocia los puertos Ethernet 3 y 4 a la interfaz ethernet2, asociada a la zona de seguridad Home
– Asocia el puerto Untrusted Ethernet a la interfaz ethernet3, asociada a la zona de seguridad Untrust
La interfaz ethernet3 es la
interfaz principal para la zona
Untrust. Puede asociar la
interfaz serie (mostrada en
gris) como interfaz de
respaldo a la zona Untrust. ethernet3 ethernet2 ethernet1
Zona Untrust Zona Home Zona Work
Para obtener más información sobre cómo configurar y utilizar el modo Home-Work, consulte “Zonas en los
modos “Home-Work” y “Combined Port”” en la pàgina 49.

• El modo “Dual Untrust” asocia dos interfaces, una principal y una de respaldo, a la zona de seguridad
Untrust. La interfaz principal se utiliza para entregar tráfico hacia y desde la zona Untrust, mientras que la
interfaz de respaldo se utiliza solamente cuando falla la interfaz principal. Este modo proporciona las
siguientes asociaciones de puerto, interfaz y zona:
– Asocia el puerto 4 de Ethernet a la interfaz ethernet2, asociada como interfaz de respaldo a la zona de
seguridad Untrust (la interfaz ethernet3 es la interfaz principal para la zona de seguridad Untrust)
– Asocia los puertos 1, 2 y 3 de Ethernet a la interfaz ethernet1, asociada a la zona de seguridad Trust
interfaz principal para la zona
Untrust. La interfaz ethernet2
(mostrada en gris) es una
interfaz de respaldo para la ethernet3 ethernet2 ethernet1
zona Untrust.
Zona Untrust Zona Trust
Nota: La interfaz serie no está disponible en el modo de puerto Dual Untrust.
Para obtener más información sobre cómo configurar y utilizar el modo Dual Untrust, consulte el
Volumen 10, “Alta disponibilidad”.

• El modo “Combined Port” permite tanto interfaces principales y de respaldo a Internet como la segregación
de usuarios y recursos en las zonas Work y Home.
Nota: Para el dispositivo NetScreen-5XT, el modo de puerto “Combined” sólo funciona en la plataforma
NetScreen-5XT Elite (usuarios sin restricción). El modo “Combined” no se puede configurar con el
asistente de configuración inicial (“Initial Configuration Wizard”). Este modo sólo se puede configurar
mediante WebUI o con los comandos de CLI.
Este modo proporciona las siguientes asociaciones de puerto, interfaz y zona:

– Asocia el puerto Untrusted Ethernet a la interfaz ethernet4, asociada a la zona Untrust.
– Asocia el puerto 4 de Ethernet a la interfaz ethernet3, asociada como interfaz de respaldo a la zona
Untrust (la interfaz ethernet4 es la interfaz principal a la zona de seguridad Untrust).
– Asocia los puertos Ethernet 3 y 2 a la interfaz ethernet2, asociada a la zona Home.
– Asocia el puerto 1 de Ethernet a la interfaz ethernet1, asociada a la zona Work.
interfaz principal para la
zona Untrust.
La interfaz ethernet3
(mostrada en gris) es la
interfaz de respaldo a la
zona Untrust. ethernet4 ethernet3 ethernet2 ethernet1
Nota: La interfaz serie no está disponible en el modo “Combined Port”.
Para obtener más información sobre cómo configurar y utilizar el modo de puerto combinado, consulte el
Volumen 10, “Alta disponibilidad” y “Zonas en los modos “Home-Work” y “Combined Port”” en la pàgina 49.

• El modo Trust/Untrust/DMZ (extendido) asocia interfaces a las zonas de seguridad Untrust, Trust y DMZ,
permitiendo segregar de la red interna los servidores internos de web, correo electrónico y otros servidores
de aplicaciones.
Nota: El modo de puerto Trust/Untrust/DMZ solamente funciona en la plataforma NetScreen-5GT

Extended. El modo combinado (“Combined”) no se puede configurar con el asistente de configuración
inicial (“Initial Configuration Wizard”). Este modo sólo se puede configurar mediante WebUI o con los
comandos de CLI.

– Asocia los puertos Ethernet 1 y 2 a la interfaz ethernet1, asociada a la zona de seguridad Trust
– Asocia los puertos Ethernet 3 y 4 a la interfaz ethernet2, asociada a la zona de seguridad DMZ
La interfaz ethernet3
es la interfaz principal
para la zona Untrust.
Puede asociar la
interfaz serie como
interfaz de respaldo a
la zona Untrust.
ethernet3 ethernet2 ethernet1

Zona Untrust Zona DMZ Zona Trust

• El modo DMZ/Dual Untrust asocia interfaces a las zonas de seguridad Untrust, Trust y DMZ, permitiendo
entregar tráfico simultáneamente desde la red interna.
Nota: El modo de puerto DMZ/Dual Untrust solamente funciona en la plataforma NetScreen-5GT Extended
(extendido).

– Asocia los puertos Ethernet 1 y 2 a la interfaz ethernet1, asociada a la zona de seguridad Trust
– Asocia el puerto Ethernet 3 a la interfaz ethernet2, asociada a la zona de seguridad DMZ
– Asocia el puerto Ethernet 4 a la interfaz ethernet3, asociada a la zona de seguridad Untrust
– Asocia el puerto Ethernet Untrust a la interfaz ethernet4, asociada a la zona de seguridad Untrust
Las interfaces ethernet3

y ethernet4 están activas
simultáneamente. En
este diagrama, las dos
interfaces están
asociadas a la zona
Untrust para permitir
equilibrar las cargas.
ethernet4 ethernet3 ethernet2 ethernet1
Zona Trust
Zona Untrust Zona DMZ
Nota: La interfaz serie no está disponible en el modo de puerto DMZ/Dual Untrust. Para
habilitar la conmutación por fallo, en lugar de entregar tráfico simultáneamente, utilice el
comando set failover enable .

Establecimiento de los modos de puertos

La tabla siguiente resume el puerto, la interfaz y las asociaciones de zonas proporcionados por los modos de
puertos de NetScreen ScreenOS:
Modo Modo Modo

Puerto
*
Trust-Untrust
† Home-Work Dual Untrust
Interfaz Zona Interfaz Zona Interfaz Zona
Untrusted Untrust Untrust ethernet3 Untrust ethernet3 Untrust
1 Trust Trust ethernet1 Work ethernet1 Trust
2 Trust Trust ethernet1 Work ethernet1 Trust
3 Trust Trust ethernet2 Home ethernet1 Trust
4 Trust Trust ethernet2 Home ethernet2 Untrust
Modem serie Null serie Null N/D N/D
*
†
Según la etiqueta adherida a los chasis del dispositivo NetScreen.
Modo de puerto predeterminado
Modo combinado Modo Modo DMZ/Dual

Puerto
* Trust/Untrust/DMZ Untrust
Interfaz Zona Interfaz Zona Interfaz Zona
Untrusted ethernet4 Untrust ethernet3 Untrust ethernet4 Untrust
1 ethernet1 Work ethernet1 Trust ethernet1 Trust
2 ethernet2 Home ethernet1 Trust ethernet1 Trust
3 ethernet2 Home ethernet2 DMZ ethernet2 DMZ
4 ethernet3 Untrust ethernet2 DMZ ethernet3 Untrust
Modem N/D N/D serie Null N/D N/D
*
Según la etiqueta adherida a los chasis del dispositivo NetScreen.

El ajuste del modo de puerto del dispositivo NetScreen se puede modificar mediante WebUI o CLI. Antes de
establecer el modo de puerto, observe lo siguiente:
• Al cambiar el modo de puerto, se elimina cualquier configuración existente en el dispositivo NetScreen y es
necesario reiniciar el sistema.
• Ejecutar el comando CLI unset all no afecta al ajuste del modo de puerto del dispositivo NetScreen. Por
ejemplo, si desea cambiar el modo de puerto de Combined al modo predeterminado Trust-Untrust, ejecutar
el comando unset all eliminará la configuración existente, pero no pondrá el dispositivo en el modo
Trust-Untrust.
Ejemplo: Modo de puerto Home-Work

En este ejemplo establecerá el modo de puerto del dispositivo NetScreen-5XT en Home-Work.
Nota: Cambiar el modo de puerto elimina cualquier configuración existente en el dispositivo NetScreen y requiere
reiniciar el sistema.
WebUI
Configuration > Port Mode > Port Mode: Seleccione “Home-Work” en la lista desplegable y haga clic en
Apply.
Cuando aparezca la pregunta siguiente, haga clic en OK :
Operational mode change will erase current configuration and reset the device, continue?
CLI
exec port-mode home-work
Cuando aparezca la pregunta siguiente, teclee y (respuesta afirmativa) :
Change port mode from <trust-untrust> to <home-work> will erase system configuration and reboot box
Are you sure y/[n] ?

Para ver el modo de puerto actual en el dispositivo NetScreen:
WebUI
Configuration > Port Mode
CLI
get system
Zonas en los modos “Home-Work” y “Combined Port”

Pueden presentarse conflictos de seguridad cuando el teletrabajo de los empleados y las redes domésticas
empiecen a popularizarse. La red doméstica utilizada tanto por teletrabajadores como por miembros de sus familias
puede convertirse en un peligroso agujero de seguridad para una red corporativa, por el que se introducen
amenazas (como los gusanos o “worms”) y se permite el acceso a los recursos corporativos, como servidores y
redes, a terceros ajenos a la empresa.
Los modos de puertos8 Home-Work y Combined asocian las interfaces de ScreenOS a las zonas especiales Work y
Home. Esto permite la segregación de usuarios y recursos corporativos de los domésticos, permitiendo al mismo
tiempo que los usuarios de las zonas Home y Work puedan acceder a la zona Untrust.
8. Sólo se pueden establecer modos de puertos en ciertos dispositivos NetScreen. Consulte “Modos de puerto” en la pàgina 41.

Home-Work
Combined
El modo de puerto Home-Work también asocia el puerto Modem a una interfaz serie, que se puede asociar como
interfaz de respaldo a la zona de seguridad Untrust. Para obtener más información sobre cómo utilizar la interfaz
serie como interfaz de respaldo a la zona de seguridad Untrust, consulte el Volumen 10, “Alta disponibilidad”.
El modo de puertos combinados (“Combined Port”) también asocia el puerto Ethernet 4 a la zona no fiable para
salvaguardar el puerto de seguridad Untrust. La interfaz de respaldo solamente se utiliza cuando se produce algún
fallo en la interfaz principal a la zona Untrust. Para obtener más información sobre cómo utilizar la interfaz ethernet3
como interfaz de respaldo a la zona de seguridad Untrust, consulte el Volumen 10, “Alta disponibilidad”.
De forma predeterminada, el dispositivo NetScreen-5XT actúa como un servidor del protocolo de configuración
dinámica de hosts (“Dynamic Host Configuration Protocol” o “DHCP”), asignando direcciones IP dinámicas a los
clientes DHCP en la zona Work. (Para obtener más información sobre el servidor DHCP, consulte “Servidor DHCP”
en la pàgina 390).

Puede configurar el dispositivo NetScreen utilizando una conexión de Telnet o WebUI solamente desde la zona
Work. El dispositivo NetScreen no se puede configurar desde la zona Home. No se puede utilizar ningún servicio de
administración, incluyendo el comando “ping”, en la interfaz de la zona Home. La dirección IP predeterminada de la
interfaz de la zona Work (ethernet1) es 192.168.1.1/24.
Las directivas predeterminadas en los modos de puertos del Home-Work y modo Combined proporcionan el
siguiente control del tráfico entre zonas:
• Permitir todo el tráfico desde la zona Work a la zona Untrust.
• Permitir todo el tráfico desde la zona Home a la zona Untrust.
• Permitir todo el tráfico desde la zona Work a la zona Home.
• Bloquear todo el tráfico desde la zona Home a la zona Work (esta directiva no se puede eliminar)
Puede crear nuevas directivas para el tráfico de la zona Work a la zona Untrust, de la zona Home a la zona Untrust
y de la zona Work a la zona Home. También puede eliminar las directivas predeterminadas que permiten todo el
tráfico desde la zona Work a la zona Untrust, desde la zona Home a la zona Untrust y desde la zona Work a la zona
Home. Tenga en cuenta, sin embargo, que no puede crear una directiva para permitir tráfico desde la zona Home a
la zona Work.
Ejemplo: Zonas Home-Work

En este ejemplo, primero pondrá un dispositivo NetScreen-5XT en el modo de puerto Home-Work. A continuación
configurará una directiva para permitir solamente el tráfico FTP desde la zona Home a la zona Untrust y para
eliminar la directiva predeterminada que permite todo el tráfico desde la zona Home a la zona Untrust. En este
ejemplo, la directiva predeterminada, que permite tráfico desde cualquier dirección de origen a cualquier dirección
de destino para cualquier servicio, tiene la identificación 2.
Advertencia: Cambiar el modo de puerto elimina cualquier configuración existente en el dispositivo NetScreen y
requiere reiniciar el sistema.

WebUI
Configuration > Port Mode > Port Mode: Seleccione “Home-Work” en la lista desplegable y haga clic en
Apply .
Cuando aparezca la pregunta siguiente, haga clic en OK :
Operational mode change will erase current configuration and reset the device, continue?
En este momento, el sistema se reinicia. Tras iniciar una sesión, haga lo siguiente:
Policies > (From: Home, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK .
Source Address:
Service: FTP
Action: Permit
Directivas: En la lista de directivas “From Home to Untrust”, haga clic en Remove en la columna
“Configure” para la directiva con la identificación 2.
CLI
exec port-mode home-work
Cuando aparezca la pregunta siguiente, teclee y (respuesta afirmativa) :
Change port mode from <trust-untrust> to <home-work> will erase system
configuration and reboot box
Are you sure y/[n] ?
set policy from home to untrust any any ftp permit
unset policy 2
save

Capítulo 3
Interfaces
3
Las interfaces y subinterfaces físicas actúan como puertas; permiten que entre y salga tráfico de una zona de
seguridad. Para permitir que el tráfico de una red entre y salga de una zona de seguridad, ésta debe tener asociada
una interfaz y, si se trata de una zona de capa 3, deberá asignársele una dirección IP. A continuación se deberán
configurar directivas para permitir que el tráfico pase de interfaz en interfaz entre las diferentes zonas. Se pueden
asignar varias interfaces a una zona, pero una misma interfaz no se puede asignar a varias zonas.
Este capítulo contiene las siguientes secciones:
• “Tipos de interfaces” en la pàgina 55
– “Interfaces de zonas de seguridad” en la pàgina 55
– “Interfaces de zonas de función” en la pàgina 57
– “Interfaces de túnel” en la pàgina 58
• “Visualización de interfaces” en la pàgina 64
• “Configuración de interfaces de la zona de seguridad” en la pàgina 66
– “Asociación de una interfaz a una zona de seguridad” en la pàgina 66
– “Direccionamiento de una interfaz de la zona de seguridad L3” en la pàgina 67
– “Desasociación de una interfaz de una zona de seguridad” en la pàgina 70
– “Modificación de interfaces” en la pàgina 71
– “Creación de subinterfaces” en la pàgina 73
– “Eliminación de subinterfaces” en la pàgina 74
• “Direcciones IP secundarias” en la pàgina 75
– “Propiedades de las direcciones IP secundarias” en la pàgina 75
• “Interfaces loopback” en la pàgina 77

Capítulo 3 Interfaces
• “Cambios de estado de la interfaz” en la pàgina 81

– “Supervisión de la conexión física” en la pàgina 83
– “Seguimiento de direcciones IP” en la pàgina 84
– “Supervisión de interfaces” en la pàgina 91
– “Supervisión de zonas de seguridad” en la pàgina 98
– “Interfaces inactivas y flujo de tráfico” en la pàgina 99

Capítulo 3 Interfaces Tipos de interfaces
TIPOS DE INTERFACES
En esta sección se describen la zona de seguridad, la zona de función y las interfaces de túnel. Para obtener más
información sobre cómo visualizar una tabla de todas estas interfaces, consulte “Visualización de interfaces” en la
pàgina 64.
Interfaces de zonas de seguridad

La finalidad de las interfaces y subinterfaces físicas es proporcionar una abertura por la que el tráfico de red pueda
pasar de una zona a otra.
Físicas
Cada puerto de su dispositivo NetScreen representa una interfaz física, estando el nombre de la interfaz
predefinido. El nombre de una interfaz física se compone del tipo de medio, número de la ranura (en algunos
dispositivos NetScreen) y número de puerto, por ejemplo, ethernet3/2 o ethernet2 (consulte también “Interfaces de
zonas de seguridad” en la pàgina 3). Puede asociar una interfaz física a cualquier zona de seguridad en la que
actúe como entrada a través de la que el tráfico entre y salga de la zona. Sin una interfaz, ningún tráfico podría
entrar ni salir de una zona.
En los dispositivos NetScreen que admiten cambios en las asociaciones interfaz-a-zona, tres de las interfaces
físicas Ethernet están pre-asociadas a zonas de seguridad específicas de capa 2: V1-Trust, V1-Untrust y V1-DMZ.
La interfaz que se asocia a cada zona depende de la plataforma en cuestión. (Para obtener más información sobre
zonas de seguridad, consulte “Zonas de seguridad” en la pàgina 2).
Subinterfaz
Una subinterfaz, como una interfaz física, actúa como puerta por la que entra y sale el tráfico de una zona de
seguridad. Una interfaz física se puede dividir lógicamente en varias subinterfaces virtuales. Cada subinterfaz
virtual toma prestado el ancho de banda que necesita de la interfaz física de la que procede, por lo que su nombre
es una extensión del nombre de la interfaz física, por ejemplo, ethernet3/2.1 o ethernet2.1. (Consulte también
“Interfaces de zonas de seguridad” en la pàgina 3).

Una subinterfaz se puede asociar a cualquier zona. Una subinterfaz se puede asociar a la misma zona que su
interfaz física, o bien a otra zona. (Para obtener más información, consulte “Asociación de una interfaz a una zona
de seguridad” en la pàgina 66 y “Definición de subinterfaces y etiquetas VLAN” en la pàgina 9 -24).
Interfaces agregadas
Los dispositivos de la serie NetScreen-5000 pueden trabajar con interfaces agregadas. Una interfaz agregada es la
acumulación de dos o más interfaces físicas, entre las que se reparten equitativamente la carga de tráfico dirigida a
la dirección IP de la interfaz agregada. Utilizando interfaces agregadas se puede aumentar el ancho de banda
disponible para una dirección IP determinada. Asimismo, si falla algún miembro de una interfaz agregada, los otros
miembros pueden seguir procesando tráfico, aunque con menos ancho de banda que el disponible anteriormente.
Nota: Para obtener más información sobre interfaces agregadas, consulte “Redundancia de interfaces” en la
pàgina 10 -59.
Interfaces redundantes
Dos interfaces físicas se pueden asociar para crear una interfaz redundante, que entonces se puede asociar a una
zona de seguridad. Una de las dos interfaces físicas actúa como interfaz principal y gestiona todo el tráfico dirigido
a la interfaz redundante. La otra interfaz física actúa como interfaz secundaria y permanece en estado de espera
por si la interfaz activa experimenta algún fallo. En ese caso, el tráfico dirigido a la interfaz redundante se desvía a
la interfaz secundaria, que se convierte en la nueva interfaz principal. El uso de interfaces redundantes proporciona
un primer frente de redundancia antes de que el fallo sea comunicado como error al nivel de dispositivo.
Nota: Para obtener más información sobre interfaces redundantes, consulte “Redundancia de interfaces” en la
pàgina 10 -59.
Interfaces de seguridad virtuales

Las interfaces de seguridad virtuales (VSIs) son las interfaces virtuales compartidas por dos dispositivos NetScreen
que forman un dispositivo de seguridad virtual (VSD) cuando funcionan en el modo de alta disponibilidad (HA).
Tanto el tráfico de una red como el tráfico VPN utilizan la dirección IP y la dirección virtual MAC de un VSI. A
continuación, VSD asigna el tráfico a la interfaz, subinterfaz o interfaz redundante a la que anteriormente había

asociado el VSI. Cuando dos dispositivos NetScreen están funcionando en el modo de alta disponibilidad (“HA”), es
necesario asociar las interfaces de la zona de seguridad a las que desee proporcionar un servicio ininterrumpido
por si se produce alguna conmutación por error en uno o más dispositivos de seguridad virtuales (VSDs). Cuando
se asocia una interfaz a un VSD, el resultado es una interfaz de seguridad virtual (VSI).
Nota: Para obtener más información sobre VSIs y cómo funcionan con VSDs en un clúster HA, consulte
Interfaces de zonas de función

Las interfaces de las zonas de función, como la de administración y la de HA, tienen una finalidad especial.
Interfaz de administración
En algunos dispositivos NetScreen, el dispositivo se puede administrar a través de una interfaz física separada (la
interfaz de administración o MGT) sacando el tráfico administrativo fuera del tráfico de usuario de red habitual.
Separando el tráfico administrativo del tráfico de los usuarios de red se aumenta significativamente la seguridad y
se asegura un ancho de banda de administración constante.
Nota: Para obtener más información sobre cómo configurar el dispositivo para la administración, consulte
“Administración” en la pàgina 3 -1.
Interfaz de HA
La interfaz de HA es un puerto físico utilizado exclusivamente para las funciones de HA. Con dispositivos
NetScreen equipados con interfaces especializadas para alta disponibilidad (“High Availability” o “HA”) se pueden
asociar dos dispositivos para formar un grupo redundante, o clúster. En un grupo redundante, una unidad actúa
como maestra, realizando las funciones de cortafuegos de la red, VPN y asignación de tráfico, mientras que la otra
unidad actúa como respaldo, esperando a asumir el control de las funciones de cortafuegos en caso de fallar la
unidad principal. Se trata de una configuración activa/pasiva. También se pueden configurar ambos miembros del
clúster para actuar mutuamente como maestros y respaldos. Esta configuración se denomina activa/activa. Ambas
configuraciones se explican en detalle en el Volumen 10, “Alta disponibilidad”.

Interfaz de HA virtual
En dispositivos NetScreen carentes de una interfaz de HA especializada, una interfaz de alta disponibilidad
virtual (HA) proporciona la misma funcionalidad. Al no haber ningún puerto físico dedicado exclusivamente
al tráfico de HA, la interfaz de HA virtual se debe asociar a uno de los puertos físicos de Ethernet. Para
asociar una interfaz de red a la zona de HA se utiliza el mismo procedimiento que para asociar una interfaz
de red a una zona de seguridad (consulte “Asociación de una interfaz a una zona de seguridad” en la
pàgina 66).
Nota: Para obtener más información sobre interfaces de HA, consulte “Interfaces HA duales” en la
pàgina 10 -39.
Interfaces de túnel
Una interfaz de túnel actúa como entrada a un túnel VPN. El tráfico entra y sale por el túnel VPN a través de una
interfaz de túnel.
Cuando se asocia una interfaz de túnel a un túnel VPN, se puede establecer una referencia a esa interfaz de túnel
en una ruta hacia un destino determinado y después hacer referencia a ese destino en una o más directivas. Este
método permite un control muy detallado del flujo de tráfico a través del túnel. También permite el enrutamiento
dinámico para el tráfico VPN. Cuando no hay ninguna interfaz de túnel asociada a un túnel VPN, se debe
especificar el túnel mismo en la directiva y elegir tunnel como acción. Dado que la acción tunnel lleva implícito un
permiso, no se puede rechazar específicamente el tráfico procedente de un túnel VPN.
Se puede aplicar NAT basada en directivas al tráfico entrante o saliente usando un conjunto de direcciones IP
dinámicas (DIP) en la misma subred que la interfaz de túnel. Un motivo típico para utilizar NAT basada en directivas
en una interfaz de túnel es evitar conflictos de direcciones IP entre los sitios de ambos extremos de un túnel VPN.
Un túnel VPN basado en rutas debe asociarse a una interfaz de túnel para que el dispositivo NetScreen pueda
enrutar el tráfico entrante y saliente. Un túnel VPN basado en rutas se puede asociar a una interfaz de túnel
numerada (con dirección IP y máscara de red) o no numerada (sin dirección IP y máscara de red). Si la interfaz de
túnel no está numerada, debe especificar una interfaz que preste a la interfaz de túnel una dirección IP. El
dispositivo NetScreen solamente utiliza la dirección IP prestada como dirección de origen cuando el dispositivo
NetScreen mismo genera tráfico (como el de los mensajes OSPF) a través del túnel. La interfaz de túnel puede
tomar prestada la dirección IP de otra interfaz en la misma zona de seguridad, o bien de una interfaz en otra zona,
siempre que ambas zonas se encuentren en el mismo dominio de enrutamiento.

Se puede alcanzar un control muy fiable del enrutamiento del tráfico VPN asociando todas las interfaces de túnel no
numeradas a una zona, que se encuentra en su propio dominio de enrutamiento virtual, y tomando la dirección IP
de una interfaz loopback asociada a la misma zona. Por ejemplo, se pueden asociar todas las interfaces de túnel no
numeradas a una zona definida por el usuario llamada “VPN” y configurarlas para que tomen su dirección IP de la
interfaz loopback.1, también asociada a la zona VPN. La zona VPN se encuentra en un dominio de enrutamiento
definido por el usuario llamado “vpn-vr”. Usted pondrá todas las direcciones de destino a las que conducen los
túneles en la zona VPN. Sus rutas a estas direcciones apuntan a las interfaces de túnel, y sus directivas controlan
el tráfico VPN entre otras zonas y la zona VPN.
set vrouter name vpn-vr

set zone name vpn vrouter vpn-vr
set interface loopback.1 zone vpn ethernet1 ethernet3
set interface loopback.1 ip 172.16.1.1/24 10.1.1.1/24 trust-vr 1.1.1.1/24
set interface tunnel.1 zone vpn Zona Trust Zona Untrust
set interface tunnel.1 ip unnumbered loopback.1 Enrutador
externo
Configure las direcciones para src-1 y dst-1. src-1 10.1.1.5 1.1.1.250
Configure un túnel VPN y asócielo a tunnel.1.
set vrouter trust-vr route 10.2.2.5/32 vrouter vpn-vr

set vrouter trust-vr route 0.0.0.0/0 interface ethernet3
gateway 1.1.1.250 loopback.1 Nota: El túnel VPN
set vrouter vpn-vr route 10.2.2.5 interface tunnel.1 mismo no se muestra.
tunnel.1 172.16.1.1/24 dst-1
set policy from trust to vpn scr-1 dst-1 any permit no numerada Zona VPN 10.2.2.5
vpn-vr
El dispositivo NetScreen envía el tráfico destinado a 10.2.2.5/32 de
trust-vr a vpn-vr. Si tunnel.1 se inhabilita por cualquier causa, el
dispositivo NetScreen descarta el paquete. Dado que la ruta
predeterminada (a 0.0.0.0/0) solamente se encuentra en trust-vr, el
dispositivo NetScreen no intenta enviar el paquete en texto puro sin
formato a través de ethernet3.

Poner todas las interfaces de túnel en una zona de estas características es muy seguro porque no hay posibilidad
de que, por un fallo de la VPN (que provocaría la desactivación de la ruta hacia la interfaz de túnel asociada), el
tráfico destinado al túnel sea desviado hacia una ruta sin túnel, como la ruta predeterminada. (Para ver varias
sugerencias sobre cómo evitar este problema, consulte “Consideraciones sobre seguridad en VPNs basadas en
rutas” en la pàgina 5 -93).
También puede asociar una interfaz de túnel a una zona de túnel. En tal caso, debe tener una dirección IP. La
finalidad de asociar una interfaz de túnel a una zona de túnel es que los servicios de NAT estén disponibles para los
1
túneles VPN basados en directivas .
Interfaces de
Interfaces zonas de
de túnel seguridad
Cuando una interfaz de túnel se encuentra en una zona de seguridad, debe
Zona de Túnel VPN asociarse un túnel VPN a la interfaz de túnel. Esto permite crear una configuración
Numerada o
no numerada de VPN basada en rutas.
seguridad La interfaz de túnel puede estar numerada o no numerada. Si no está numerada, la
interfaz de túnel toma prestada la dirección IP de la interfaz predeterminada de la
zona de seguridad en la que fue creada. Nota: Sólo una interfaz de túnel con una
dirección IP y una máscara de red puede admitir NAT basada en directivas.
Numerada Zona de Túnel VPN Cuando una interfaz de túnel numerada se encuentra en una zona de seguridad y
es la única interfaz en esa zona, no es necesario crear una interfaz de zona de
seguridad seguridad. En este caso, la zona de seguridad admite tráfico VPN a través de la
interfaz de túnel, pero ningún otro tipo de tráfico.
Cuando una interfaz de túnel está asociada a una zona de túnel, la interfaz de túnel
debe tener una dirección IP y una máscara de red. Esto permite definir conjuntos de
Numerada DIP y direcciones MIP en esa interfaz. Si asocia un túnel VPN a una zona de túnel,
Zona de Túnel VPN
no puede asociarlo también a una interfaz de túnel. En tales casos, debe crear una
túnel configuración de VPN basada en directivas.
1. Los servicios de traducción de direcciones de red (NAT) incluyen conjuntos de direcciones IP dinámicas (DIP) y direcciones IP asignadas (MIP) definidas
en la misma subred que una interfaz.

Conceptualmente, los túneles VPN pueden imaginarse como tuberías tendidas. Abarcan desde el dispositivo local
hasta las puertas de enlace remotas, siendo las interfaces de túnel los orificios en los extremos de esas tuberías.
Las tuberías siempre están disponibles, listas para cuando el motor de enrutamiento envíe tráfico a una de sus
interfaces.
Generalmente, se asigna una dirección IP a una interfaz de túnel cuando se desea que ésta admita uno o más
conjuntos de direcciones IP dinámicas (DIP) para la traducción de direcciones de origen (NAT-src) y conjuntos de
direcciones IP asignadas (MIP) para la traducción de direcciones de destino (NAT-dst). Para obtener más
información sobre VPNs y la traducción de direcciones, consulte “Sitios VPN con direcciones superpuestas” en la
pàgina 5 -203). Puede crear una interfaz de túnel con una dirección IP y una máscara de red en una zona de
seguridad o en una zona de túnel.
Si la interfaz de túnel no necesita trabajar con traducción de direcciones y su configuración no requiere que la
interfaz de túnel esté asociada a una zona de túnel, puede especificar la interfaz como no numerada. Una interfaz
de túnel no numerada debe asociarse a una zona de seguridad; no se puede asociar a una zona de túnel. También
debe especificar una interfaz con una dirección IP que pertenezca al mismo dominio de enrutamiento virtual que la
zona de seguridad a la que está asociada la interfaz no numerada. La interfaz de túnel no numerada toma prestada
la dirección IP de esa interfaz.
Nota: Para ver cómo asociar una interfaz de túnel a un túnel, consulte los ejemplos de VPN basada en rutas en
“VPNs punto a punto” en la pàgina 5 -103 y “VPNs de acceso telefónico” en la pàgina 5 -233.
Si está transmitiendo paquetes multicast a través de un túnel VPN, puede habilitar la encapsulación de
enrutamiento genérica (“Generic Routing Encapsulation” o “GRE”) en las interfaces de túnel para encapsular los
paquetes multicast en paquetes unicast. Los dispositivos NetScreen admiten GREv1 para encapsular paquetes IP
en paquetes unicast IPv4. Para obtener más información sobre GRE, consulte “Encapsulado de enrutamiento
genérico” en la pàgina 6 -205.

Eliminar interfaces de túnel

No se puede eliminar inmediatamente una interfaz de túnel que contenga direcciones IP asignadas (MIPs) o
conjuntos de direcciones IP dinámicas (DIP). Antes de eliminar una interfaz de túnel que contenga cualquiera de
estas características, primero debe eliminar cualquier directiva que contenga referencias a ellas. A continuación
debe eliminar las MIPs y los conjuntos de DIP en la interfaz de túnel. Asimismo, si una configuración de VPN
basada en rutas contiene referencias a una interfaz de túnel, antes de poder eliminar la interfaz de túnel, debe
eliminar la configuración de VPN.
Ejemplo: Eliminar una interfaz de túnel

En este ejemplo, la interfaz de túnel tunnel.2 está vinculada al conjunto de DIP 8. Existen referencias al conjunto de
DIP 8 en una directiva (ID 10) para el tráfico VPN procedente de la zona Trust y destinado a la zona Untrust a través
de un túnel VPN llamado vpn1. Para eliminar la interfaz de túnel, primero debe eliminar la directiva (o eliminar las
referencias al conjunto de DIP 8 de la directiva) y a continuación el conjunto de DIP. Después debe desasociar
tunnel.2 de vpn1. Puede eliminar la interfaz de túnel después de eliminar todas las configuraciones que dependan
de ella.
WebUI
1. Eliminar la directiva 10, con referencias al conjunto de DIP 8
Policies (From: Trust, To: Untrust): Haga clic en Remove para la directiva con ID 10.
2. Eliminar el conjunto de DIP 8, vinculado a tunnel.2

Network > Interfaces > Edit (para tunnel.2) > DIP: Haga clic en Remove para la DIP con ID 8.
3. Desasociar tunnel.2 de vpn1

VPNs > AutoKey IKE > Edit (para vpn1) > Advanced: Seleccione None en la lista desplegable “Bind to:
Tunnel Interface”, haga clic en Return y después en OK .
4. Eliminar tunnel.2
Network > Interfaces: Haga clic en Remove para tunnel.2.

CLI
1. Eliminar la directiva 10, con referencias al conjunto de DIP 8
unset policy 10
2. Eliminar el conjunto de DIP 8, vinculado a tunnel.2
unset interface tunnel.2 dip 8
3. Desasociar tunnel.2 de vpn1
unset vpn vpn1 bind interface
4. Eliminar tunnel.2
unset interface tunnel.2
save

Capítulo 3 Interfaces Visualización de interfaces
VISUALIZACIÓN DE INTERFACES
Puede visualizar una tabla que muestre todas las interfaces existentes en su dispositivo NetScreen. Al estar
predefinidas, las interfaces físicas aparecen en la lista tanto si se configuran como si no. Las subinterfaces e
interfaces de túnel solamente aparecen después de crearlas y configurarlas.
Para visualizar la tabla de interfaces en WebUI, haga clic en Network > Interfaces . Puede especificar los tipos de
interfaces a mostrar en la lista desplegable “List Interfaces”.
Para ver la tabla de interfaces en CLI, utilice el comando get interface .
Tabla de interfaces
La tabla de interfaces muestra la información siguiente sobre cada interfaz:
• Name: Este campo identifica el nombre de la interfaz.
• IP/Netmask: Este campo identifica la dirección IP y la dirección de la máscara de red de la interfaz.
• Zone: Este campo identifica las zonas a las que está asociada la interfaz.
• Type: Este campo indica si el tipo de interfaz es: capa 2 (“Layer 2”), capa 3 (“Layer 3”), túnel (“tunnel”),
redundante (“redundant”), agregada (“aggregate”), VSI.
• Link: Este campo identifica si la interfaz está activa (“Up”) o inactiva (“Down”).
• Configure: Este campo permite modificar o eliminar interfaces.

Capítulo 3 Interfaces Visualización de interfaces
Tabla de interfaces
de WebUI
Tabla de interfaces
de CLI

Capítulo 3 Interfaces Configuración de interfaces de la zona de seguridad
CONFIGURACIÓN DE INTERFACES DE LA ZONA DE SEGURIDAD

Esta sección describe cómo configurar los siguientes aspectos de las interfaces de la zona de seguridad:
• Asociar y desasociar una interfaz a una zona de seguridad
• Asignar una dirección a una interfaz de la zona de seguridad de capa 3 (“Layer 3” o “L3”)
• Modificar interfaces y subinterfaces físicas
• Crear subinterfaces
• Eliminar subinterfaces
Nota: Para obtener más información sobre cómo establecer el ancho de banda para el tráfico de una
interfaz, consulte el Capítulo 7, “Asignación de tráfico”. Para obtener más información sobre las opciones
de administración y otras opciones de servicios disponibles para cada interfaz, consulte “Control del tráfico
administrativo” en la pàgina 3 -39.
Asociación de una interfaz a una zona de seguridad

Cualquier interfaz física se puede asociar a una zona de seguridad L2 o L3. Una subinterfaz sólo se puede asociar
a una zona de seguridad L3, porque las subinterfaces requieren una dirección IP. Solamente se puede asignar una
dirección IP a una interfaz después de haberla asociado a una zona de seguridad L3.
Ejemplo: Asociar una interfaz

En este ejemplo asociará ethernet5 a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet5): Seleccione Trust en la lista desplegable “Zone Name” y haga
clic en OK .
CLI
set interface ethernet5 zone trust
save

Direccionamiento de una interfaz de la zona de seguridad L3

Al definir una interfaz o subinterfaz de la zona de seguridad de capa 3 (“Layer 3” o “L3”), debe asignarle una
dirección IP y una máscara de red. Si se asocia la interfaz a una zona en trust-vr, también se puede especificar el
modo de la interfaz como NAT o Route. (Si la zona a la que se asocia la interfaz se encuentra en untrust-vr, la
interfaz siempre estará en el modo de ruta).
Nota: Para ver ejemplos de configuración de los modos NAT y Route, consulte el Capítulo 4, “Modos de las
interfaces” en la pàgina 107.
Los dos tipos básicos de direcciones IP que pueden considerarse para asignar direcciones de interfaces son:
• Direcciones públicas, proporcionadas por los proveedores de servicios de Internet (ISPs) para su utilización
en una red pública como Internet y que deben ser únicas
• Direcciones privadas, que un administrador de red local asigna para su utilización en una red privada y que
pueden ser asignadas por otros administradores para su utilización también en otras redes privadas
Nota: Cuando se agrega una dirección IP a una interfaz, el dispositivo NetScreen comprueba mediante una
petición de ARP si la dirección IP no existe ya en la red local. (El enlace físico debe estar activo en ese momento).
Si la dirección IP ya existe, se genera un aviso.

Direcciones IP públicas
Si una interfaz se conecta a una red pública, debe tener una dirección IP pública. Asimismo, si una zona de
seguridad L3 en untrust-vr se conecta a una red pública y las interfaces de las zonas en trust-vr están en modo de
ruta, todas las direcciones de las zonas en trust-vr (para las interfaces y para los hosts) también deben ser
direcciones públicas. Los direcciones IP públicas se dividen en tres clases: A, B, y C2, según se muestra a
continuación:
Clase de dirección Rango de direcciones Rango de direcciones excluidas

A 0.0.0.0 – 127.255.255.255 10.0.0.0 – 10.255.255.255,
127.0.0.0 – 127.255.255.255
B 128.0.0.0 – 191.255.255.255 172.16.0.0 – 172.31.255.255
C 192.0.0.0 – 223.255.255.255 192.168.0.0 – 192.168.255.255
Una dirección IP se compone de cuatro octetos, cada uno compuesto por 8 bits. En una dirección de clase A, los
primeros 8 bits indican la identificación de la red y los 24 bits finales indican la identificación del host
(nnn.hhh.hhh.hhh). En una dirección de clase B, los primeros 16 bits indican la identificación de la red y los 16 bits
finales indican la identificación del host (nnn.nnn.hhh.hhh). En una dirección de clase C, los primeros 24 bits indican
la identificación de la red y los 8 bits finales indican la identificación del host (nnn.nnn.nnn.hhh).
Aplicando máscaras de subred (o máscaras de red), las redes se pueden subdividir más aún. En esencia, una
máscara de red enmascara parte de la identificación del host, convirtiendo la parte enmascarada en una subred de
la identificación de la red. Por ejemplo, la máscara de 24 bits3 de la dirección 10.2.3.4/24 indica que los primeros
8 bits (es decir, el primer octeto, 010) identifican la porción de la red de esta dirección privada de clase A, los 16 bits
siguientes (es decir, los octetos segundo y tercero, 002.003) identifican la porción de subred de la dirección y los
últimos 8 bits (el último octeto, 004) identifican la porción de host de la dirección. Utilizando subredes para reducir
los espacios de direcciones de grandes redes en subdivisiones más pequeñas, aumenta significativamente la
eficacia en la entrega de datagramas IP.
2. También existen direcciones de las clases D y E, reservadas para fines especiales.
3. El equivalente decimal con puntos de una máscara de 24 bits es 255.255.255.0.

Direcciones IP privadas
Si una interfaz se conecta a una red privada, un administrador de la red local puede asignarle cualquier dirección,
aunque según la convención se suele utilizar una dirección del rango de direcciones reservado para uso privado —
10.0.0.0/8, 172.16.0.0 – 172.31.255.255, 192.168.0.0/16— según se define en la norma RFC 1918, “Address
Allocation for Private Internets”.
Si la zona de seguridad L3 en untrust-vr se conecta a una red pública y las interfaces asociadas a las zonas en
trust-vr están en el modo NAT, todas las direcciones de las zonas en trust-vr (para interfaces y para hosts) pueden
ser privadas.
Ejemplo: Direccionamiento de una interfaz

En este ejemplo asignará a ethernet5 la dirección IP 210.1.1.1/24 y le dará la dirección IP de administración
210.1.1.5. (Recuerde que la dirección IP de administración debe encontrarse en la misma subred que la dirección
IP de la interfaz de la zona de seguridad). Por último, pondrá la interfaz en modo NAT, que traduce todas las
direcciones IP internas a las interfaces4 predeterminadas asociadas a las otras zonas de seguridad.
WebUI
Network > Interfaces > Edit (para ethernet5): Introduzca los siguientes datos y haga clic en OK :
Manage IP: 210.1.1.5
CLI
set interface ethernet5 ip 210.1.1.1/24
set interface ethernet5 manage-ip 210.1.1.5
save
4. La interfaz predeterminada en una zona de seguridad es la primera interfaz asociada a la zona. Para averiguar cuál es la interfaz predeterminada de una
zona, consulte la columna “Default IF” en la página Network > Zones de WebUI, o la columna “Default-If” en el resultado del comando CLI get zone.

Desasociación de una interfaz de una zona de seguridad

Si una interfaz no está numerada, puede desasociarla de una zona de seguridad y asociarla a otra. Si una interfaz
está numerada, primero debe establecer su dirección IP y máscara de red en 0.0.0.0. A continuación, puede
desasociarla de una zona de seguridad y asociarla a otra, y (opcionalmente) reasignarle una dirección IP y máscara
de red.
Ejemplo: Desasociar una interfaz

En este ejemplo, ethernet3 tiene la dirección IP 210.1.1.1/24 y está asociada a la zona Untrust. Establecerá su
dirección IP y máscara de red en 0.0.0.0/0 y la asociará a la zona Null.
WebUI
Zone Name: Null
CLI
set interface ethernet3 zone null
save

Modificación de interfaces
Una vez haya configurado una interfaz física, una subinterfaz, una interfaz redundante, una interfaz agregada o una
interfaz de seguridad virtual (VSI), puede cambiar posteriormente cualquiera de los ajustes siguientes si surge la
necesidad:
• Dirección IP y máscara de red
• Administrar la dirección IP
• (Interfaces de la zona L3) Servicios de administración y de red
• (Subinterfaz) Número de identificación de la subinterfaz y número de etiqueta VLAN
• (Interfaces asociadas a las zonas de seguridad L3 en trust-vr) Modo de la interfaz: NAT o Route
• (Interfaz física) Ajustes del ancho de banda del tráfico (consulte el Capítulo 7, “Asignación de tráfico” en la
pàgina 359)
• (Interfaces físicas, redundantes y agregadas) Tamaño de la unidad de transmisión máxima (MTU)
• (Interfaces L3) Impedir que el tráfico entre y salga por la misma interfaz, incluyendo el tráfico entre una
subred principal y secundaria o entre subredes secundarias (esto se realiza mediante el comando CLI
set interface con la opción route-deny)
En las interfaces físicas de algunos dispositivos NetScreen se puede forzar el estado físico del vínculo como activo
(“up”) o inactivo (“down”). Forzando el estado físico del vínculo como inactivo, se puede simular una desconexión
del cable del puerto de la interfaz. (Esto se consigue mediante el comando CLI set interface con la opción
phy link-down).

Ejemplo: Modificar los ajustes de la interfaz

En este ejemplo hará algunas modificaciones a ethernet1, una interfaz asociada a la zona Trust. Cambiará la
dirección IP de administración de 10.1.1.2 a 10.1.1.12. Para aumentar el nivel de seguridad del tráfico
administrativo, también cambiará las opciones de los servicios de administración, habilitando SCS y SSL y
desactivando Telnet y WebUI.
WebUI
Network > Interfaces > Edit (para ethernet1): Realice las modificaciones siguientes y haga clic en OK :
Manage IP: 10.1.1.12
Management Services: (seleccione) SSH, SSL; (borre) Telnet, WebUI
CLI
set interface ethernet1 manage-ip 10.1.1.12
set interface ethernet1 manage ssh
set interface ethernet1 manage ssl
unset interface ethernet1 manage telnet
unset interface ethernet1 manage web
save

Creación de subinterfaces
5
Puede crear una subinterfaz en cualquier interfaz física del sistema raíz o sistema virtual. Una subinterfaz hace uso
del etiquetado de VLAN para distinguir el tráfico asociado a ella del tráfico asociado a otras interfaces. Observe que
aunque una subinterfaz tiene su origen en una interfaz física, de la cual toma prestado el ancho de banda que
necesita, una subinterfaz se puede asociar a cualquier zona, no necesariamente la misma a la que está asociada
su interfaz “padre”. Además, la dirección IP de una subinterfaz debe encontrarse en una subred diferente que las
direcciones IP de todas las demás interfaces y subinterfaces físicas.
Ejemplo: Subinterfaz en el sistema raíz

En este ejemplo creará una subinterfaz para la zona Trust en el sistema raíz. Configurará la subinterfaz en
ethernet1, que está asociada a la zona Trust. Asociará la subinterfaz a una zona definida por el usuario llamada
“accounting”, que se encuentra en trust-vr. Le asignará la identificación de subinterfaz 3, dirección IP 10.2.1.1/24 e
identificación 3 de etiqueta VLAN. El modo de la interfaz es NAT.
WebUI
Network > Interfaces > New Sub-IF: Introduzca los siguientes datos y haga clic en OK :
Interface Name: ethernet1 . 3
Zone Name: accounting
VLAN Tag: 3
CLI
set interface ethernet1.3 zone accounting
set interface ethernet1.3 ip 10.2.1.1/24 tag 3
save
5. También puede configurar subinterfaces en interfaces redundantes y VSIs. Para ver un ejemplo que contenga la configuración de una subinterfaz en una
interfaz redundante, consulte “Conmutación por error del sistema virtual” en la pàgina 10 -132.

Eliminación de subinterfaces
No se puede eliminar inmediatamente una subinterfaz que contenga direcciones IP asignadas (MIPs), direcciones
IP virtuales (VIPs) o conjuntos de direcciones IP dinámicas (DIP). Antes de eliminar una subinterfaz que contenga
cualquiera de estas características, primero debe eliminar todas las directivas o puertas de enlace IKE que
contengan referencias a ellas. Seguidamente, deberá eliminar las MIPs, VIPs y los conjuntos de DIP de la
subinterfaz.
Ejemplo: Eliminar una interfaz de la zona de seguridad

En este ejemplo eliminará la subinterfaz ethernet1:1.
WebUI
Network > Interfaces: Haga clic en Remove para ethernet1:1.
Un mensaje del sistema le pedirá que confirme la eliminación.
Haga clic en Yes para eliminar la subinterfaz.
CLI
unset interface ethernet1:1
save

Capítulo 3 Interfaces Direcciones IP secundarias
DIRECCIONES IP SECUNDARIAS
Cada interfaz de NetScreen tiene una sola dirección IP única y principal . Sin embargo, algunas situaciones exigen
que una interfaz tenga varias direcciones IP. Por ejemplo, una organización puede tener asignaciones de
direcciones IP adicionales y puede no desear agregar un enrutador para gestionarlas. Además, una organización
puede tener más dispositivos de red de los que su subred puede manejar, como cuando hay más de 254 hosts
conectados a una LAN. Para solucionar tales problemas, puede agregar direcciones IP secundarias a una interfaz
en la zona Trust, DMZ o definida por el usuario.
Nota: No se pueden crear direcciones IP secundarias múltiples para interfaces en la zona Untrust.
Propiedades de las direcciones IP secundarias

Las direcciones secundarias tienen ciertas propiedades que afectan a cómo se pueden implementar. Estas
propiedades son las siguientes:
• Entre dos direcciones IP secundarias cualesquiera no puede haber solapamientos en las direcciones de
subred. Tampoco puede haber solapamientos en las direcciones de subred entre una IP secundaria y
cualquier subred existente en el dispositivo NetScreen.
• Cuando se administra un dispositivo NetScreen a través de una dirección IP secundaria, la dirección
siempre tiene las mismas propiedades de administración que la dirección IP principal. Por lo tanto, no se
puede especificar una configuración de administración separada para la dirección IP secundaria.
• Tampoco se puede configurar una puerta de enlace para una dirección IP secundaria.
• Siempre que se cree una nueva dirección IP secundaria, el dispositivo NetScreen creará automáticamente
la correspondiente entrada en la tabla de enrutamiento. Cuando se elimina una dirección IP secundaria, el
dispositivo elimina automáticamente la entrada correspondiente en la tabla de enrutamiento.
Habilitar o inhabilitar el enrutamiento entre dos direcciones IP secundarias no causa ningún cambio en la tabla de
enrutamiento. Por ejemplo, si inhabilita el enrutamiento entre dos direcciones de ese tipo, el dispositivo NetScreen
descarta cualquier paquete dirigido de una interfaz a otra, pero no se producirá ningún cambio en la tabla de
enrutamiento.

Capítulo 3 Interfaces Direcciones IP secundarias
Ejemplo: Crear una dirección IP secundaria

En este ejemplo configurará una dirección IP secundaria (192.168.2.1/24) para ethernet1, una interfaz con la
dirección IP 10.1.1.1/24 asociada a la zona Trust.
WebUI
Network > Interfaces > Edit (para ethernet1) > Secondary IP: Introduzca los siguientes datos y haga clic en
Add:
CLI
set interface ethernet1 ip 192.168.2.1/24 secondary
save

Capítulo 3 Interfaces Interfaces loopback
INTERFACES LOOPBACK
Una interfaz loopback es una interfaz lógica que emula una interfaz física en el dispositivo NetScreen. Sin embargo,
a diferencia de una interfaz física, una interfaz loopback está siempre en estado activo mientras el dispositivo en el
que reside esté activo. Las interfaces de bucle invertido se denominan loopback.id_num, donde id_num es un
6
número superior o igual a 1 y denota una interfaz de bucle invertido única en el dispositivo. Como en una interfaz
física, se debe asignar una dirección IP a una interfaz loopback y asociarla a una zona de seguridad.
Después de definir una interfaz loopback, puede definir otras interfaces como miembros de su grupo. El tráfico
puede alcanzar una interfaz loopback si llega a través de una de las interfaces de su grupo. Cualquier tipo de
interfaz puede ser miembro de un grupo de interfaces loopback: interfaz física, subinterfaz, interfaz de túnel, interfaz
redundante o VSI.
Ejemplo: Crear una interfaz loopback

En el ejemplo siguiente creará la interfaz loopback.1, la asociará a la zona Untrust y le asignará la dirección IP
1.1.1.27/24.
WebUI
Network > Interfaces > New Loopback IF: Introduzca los siguientes datos y haga clic en OK :
Interface Name: loopback.1
Zone: Untrust (seleccione)
IP Address/Netmask: 1.1.1.27./24
CLI
set interface loopback.1 zone untrust
set interface loopback.1 ip 1.1.1.27
save
Nota: La interfaz loopback no es directamente accesible desde redes o hosts que residen en otras zonas.
Debe definir una directiva para permitir tráfico desde y hacia la interfaz.
6. El valor máximo de id_num que se puede especificar depende de cada plataforma.

Uso de interfaces loopback

Puede utilizar una interfaz loopback en muchas de las maneras de una interfaz física. Esta sección muestra
ejemplos de las maneras en que se puede configurar interfaces loopback.
Nota: No se puede asociar una interfaz loopback a una zona HA ni configurar una interfaz loopback para el
funcionamiento de la capa 2, ni como interfaz redundante/agregada. En interfaces loopback no se pueden
configurar las siguientes características: NTP, DNS, VIP, IP secundaria, seguimiento de IP o Webauth.
Puede definir una MIP en una interfaz loopback. Esto permite que la MIP sea accesible por un grupo de interfaces;
esta capacidad es exclusiva de las interfaces loopback. Para obtener más información sobre cómo usar la interfaz
de bucle invertido con MIPs, consulte “MIP y la interfaz de bucle invertido (loopback)” en la pàgina 7 -107.
Puede administrar el dispositivo NetScreen utilizando la dirección IP de una interfaz loopback o la dirección IP de
administración asignada a una interfaz loopback.
Ejemplo: Interfaz loopback para la administración

En el ejemplo siguiente configurará la interfaz loopback.1, definida anteriormente como interfaz de administración
para el dispositivo.
WebUI
Network > Interfaces > loopback.1 > Edit: Seleccione todas las opciones de administración y haga clic en
OK.
CLI
set interface loopback.1 manage
save

Ejemplo: BGP en una interfaz loopback

La interfaz loopback admite el protocolo de enrutamiento dinámico BGP en el dispositivo NetScreen. En el ejemplo
siguiente habilitará BGP en la interfaz loopback.1.
Nota: Para habilitar BGP en la interfaz loopback, primero debe crear una instancia de BGP para el enrutador virtual
al que planea asociar la interfaz. Para obtener más información sobre cómo configurar BGP en dispositivos
NetScreen, consulte el Volumen 6, “Enrutamiento”.
WebUI
Network > Interfaces > loopback.1 > Edit: Seleccione Protocol BGP y haga clic en OK.
CLI
set interface loopback.1 protocol bgp
save
Ejemplo: VSIs en una interfaz loopback

Puede configurar las interfaces de seguridad virtuales (VSIs) para NSRP en una interfaz loopback. El estado físico
del VSI en la interfaz de bucle invertido está siempre activo. La interfaz puede ser activa o no, dependiendo del
estado del grupo VSD al que pertenece.
WebUI
Network > Interfaces > New VSI IF: Introduzca los siguientes datos y haga clic en OK :
Interface Name: VSI Base: loopback.1
VSD Group: 1

CLI
set interface loopback.1:1 ip 1.1.1.1/24
save
Ejemplo: Interfaz loopback como interfaz de origen

Puede utilizar una interfaz loopback como interfaz de origen para determinado tráfico originado en el dispositivo
NetScreen. (Cuando se define una interfaz de origen para una aplicación, se utiliza la dirección de la interfaz de
origen especificada en lugar de la dirección de la interfaz saliente para comunicarse con un dispositivo externo). En
el ejemplo siguiente especificará que el dispositivo NetScreen utilice la interfaz definida anteriormente loopback.1
para enviar paquetes de syslog.
WebUI
Configuration > Report Settings > Syslog: Introduzca los siguientes datos y haga clic en Apply :
Enable Syslog Messages: (seleccione)
Source interface: loopback.1 (seleccione)
Syslog Servers:
No.: 1 (seleccione)
IP/Hostname: 10.1.1.1
Traffic Log: (seleccione)
Event Log: (seleccione)
CLI
set syslog config 10.1.1.1 log all
set syslog src-interface loopback.1
set syslog enable
save

Capítulo 3 Interfaces Cambios de estado de la interfaz
CAMBIOS DE ESTADO DE LA INTERFAZ

Una interfaz puede estar en uno de los estados siguientes:
• Physically Up (Físicamente activa ) – Para interfaces Ethernet físicas que operan en la capa 2 (modo
transparente) o en la capa 3 (modo de ruta) en el modelo de interconexión de sistemas abiertos (“Open
Systems Interconnection” u “OSI”). Una interfaz está físicamente activa cuando está cableada a otro
dispositivo de red y puede establecer un enlace a ese dispositivo.
• Logically Up (Lógicamente activas) – Tanto para interfaces físicas como para interfaces lógicas
(subinterfaces, interfaces redundantes e interfaces agregadas). Una interfaz está lógicamente activa
cuando el tráfico que la atraviesa puede alcanzar los dispositivos especificados (en las direcciones IP
supervisadas) de una red.
• Physically Down (Físicamente inactivas) – Una interfaz está físicamente inactiva cuando no está
cableada a otro dispositivo de la red o cuando, aún estando cableada, no puede establecer un enlace.
También puede forzar que una interfaz esté físicamente inactiva ejecutando el comando CLI siguiente:
set interface interface phy link-down .
• Logically Down (Lógicamente inactiva) – Una interfaz está lógicamente inactiva cuando el tráfico que la
atraviesa no puede alcanzar los dispositivos especificados (en las direcciones IP supervisadas) de una red.
El estado físico de una interfaz tiene prioridad sobre su estado lógico. Una interfaz puede estar físicamente activa y,
al mismo tiempo, lógicamente activa o inactiva. Cuando una interfaz está físicamente inactiva, su estado lógico es
irrelevante.
Cuando el estado de una interfaz es activo, todas las rutas que utilizan esa interfaz permanecen activas y
utilizables. Cuando el estado de una interfaz es inactivo, el dispositivo NetScreen desactiva todas las rutas que
utilizan esa interfaz aunque, dependiendo de si la interfaz está físicamente o lógicamente inactiva, el tráfico podría
seguir atravesando una interfaz en estado inactivo (consulte “Interfaces inactivas y flujo de tráfico” en la pàgina 99).
Para compensar la pérdida de rutas que implica la pérdida de una interfaz, puede configurar rutas alternativas
utilizando una interfaz alternativa.

Dependiendo de la acción configurada para ejecutarse al detectar un cambio de estado en una interfaz
supervisada, el cambio del estado activo al inactivo en una interfaz supervisada puede hacer que la interfaz
supervisora cambie su estado de inactivo a activo. Para configurar este comportamiento, puede utilizar el siguiente
comando CLI:
set interface interface monitor threshold number action up { logically |
physically }
Al introducir este comando, el dispositivo NetScreen fuerza automáticamente la interfaz supervisora al estado
inactivo. Si falla el objeto supervisado (dirección IP, interfaz o zona supervisada), el estado de la interfaz
supervisora se activa (lógica o físicamente, dependiendo de su configuración).
Una interfaz puede supervisar objetos en cuanto al menos uno de los eventos siguientes. Cada uno de estos
eventos, individual o combinado, puede provocar que el estado de la interfaz supervisora cambie de activo a
inactivo o viceversa:
• Desconexión/reconexión física
• Fallo/éxito del seguimiento de IP
• Fallo/éxito de una interfaz supervisada
• Fallo/éxito de una zona de seguridad supervisada

Si un objeto supervisado falla… y el peso de ese objeto es ≥ al

umbral de fallos de supervisión, …
Desconexión
física y la acción se establece como desactivar,…
La interfaz se desconecta.
Fallo del
seguimiento la interfaz supervisora
de IP se desactiva.
✗
Ninguna respuesta a las peticiones de eco ICMP
Fallo de la interfaz
supervisada
Interfaz
supervisora
Los fallos de seguimiento de IP exceden el umbral.
Fallo de la zona Zona de

supervisada seguridad
Todas las interfaces en

la misma zona se
desactivan.
Si, después de fallar, un objeto supervisado tiene éxito (la interfaz se reconecta o el seguimiento de IP vuelve a
tener éxito), la interfaz supervisora vuelve a activarse. Hay un retardo de aproximadamente un segundo entre el
momento en que el objeto supervisado tiene éxito y la reactivación de la interfaz supervisora.
Cada uno de los eventos antedichos se presenta en las secciones siguientes.
Supervisión de la conexión física

Las interfaces físicas de un dispositivo NetScreen supervisan el estado de su conexión física a otros dispositivos de
la red. Cuando una interfaz está conectada a otro dispositivo de la red y ha establecido un enlace con él, su estado
es físicamente activo y todas las rutas que utilizan esa interfaz están activas.

Puede consultar el estado de una interfaz en la columna “State” del resultado del comando get interface y en la
columna “Link” de la página Network > Interfaces de WebUI. Puede estar activo (“up") o inactivo (“down”).
Puede consultar el estado de una ruta en el campo de estado del comando get route id number y en la página
Network > Routing > Routing Entries de WebUI. Un asterisco indica que la ruta está activa. Si no hay asterisco, está
inactiva.
Seguimiento de direcciones IP
El dispositivo NetScreen puede realizar un seguimiento de direcciones IP específicas a través de una interfaz, de
forma que cuando una o varias de ellas queden inaccesibles, el dispositivo NetScreen pueda desactivar todas las
7
rutas asociadas a esa interfaz, incluso aunque la conexión física siga activa . Una ruta desactivada vuelve a
activarse cuando el dispositivo NetScreen retoma el contacto con esas direcciones IP.
NetScreen utiliza una supervisión de rutas de capa 3, o seguimiento de IP, similar a la utilizada con NSRP para
supervisar la accesibilidad de direcciones IP específicas a través de una interfaz. Por ejemplo, si una interfaz se
conecta directamente a un enrutador, es posible hacer un seguimiento de la dirección de salto siguiente en la
interfaz para determinar si el enrutador sigue estando accesible. Al configurar el seguimiento de IP en una interfaz,
el dispositivo NetScreen envía peticiones de eco ICMP (ping) en la interfaz a un máximo de cuatro direcciones IP de
destino a intervalos definidos por el usuario. El dispositivo NetScreen supervisa estos objetivos para comprobar si
se recibe una respuesta. Si no se recibe respuesta de un destino un número específico de veces, dicha dirección IP
se considera inaccesible. Si no se obtiene respuesta de uno o más destinos, es posible que el dispositivo
NetScreen desactive las rutas asociadas a dicha interfaz. Si hay disponible otra ruta que conduzca al mismo
destino, el dispositivo NetScreen redirige el tráfico para utilizar la nueva ruta.
7. En ciertos dispositivos con ScreenOS, esta acción también hace que se conmute por error a la interfaz de respaldo asociada a la misma zona que la interfaz
en la que se configuró el seguimiento de IP (consulte “Definición de conmutación por error de interfaces” en la pàgina 10 -72).

Configuración del seguimiento de IP

Puede definir el seguimiento de IP en las siguientes interfaces para las que haya configurado una dirección IP de
administración:
• Interfaz física asociada a una zona de seguridad (no las zonas funcionales HA o MGT)
Nota: La interfaz puede operar en la capa 2 (modo transparente) o en la capa 3 (modo de ruta).
• Subinterfaz
• Interfaz redundante
• Interfaz agregada
Nota: Aunque la interfaz puede ser una interfaz redundante o una interfaz agregada, no puede ser un
miembro de una interfaz redundante o agregada.
En los dispositivos que admiten sistemas virtuales, la interfaz en la que se establezca el seguimiento de IP puede
pertenecer al sistema raíz o a un sistema virtual (vsys). Sin embargo, en una interfaz compartida el seguimiento de
IP sólo se puede establecer en el nivel raíz8.
Para cada interfaz se puede configurar el seguimiento de hasta cuatro direcciones IP por parte del dispositivo
NetScreen. En un único dispositivo, se pueden configurar hasta 64 direcciones IP de seguimiento. En esta suma se
incluyen todas las direcciones IP de seguimiento, independientemente de si se utilizan para el seguimiento de IP
basado en interfaz, para el seguimiento de IP basado en NSRP, en el nivel raíz o en el nivel vsys.
Las direcciones IP de seguimiento no tienen por qué estar en la misma subred que la interfaz. Por cada dirección IP
que desee someter a un seguimiento, se puede especificar lo siguiente:
• Intervalo, en segundos, transcurrido el cual se enviarán las peticiones de eco a la dirección IP especificada.
• Número de intentos de petición de eco consecutivos sin éxito antes de que se considere que la conexión
con la dirección IP ha fallado.
• Peso de la conexión IP fallida (una vez que la suma de pesos de todas las conexiones IP fallidas supera un
umbral determinado, se desactivan las rutas asociadas a la interfaz).
8. Desde un vsys, puede establecer la supervisión de una interfaz compartida desde una interfaz que pertenezca al vsys. Sin embargo, desde dentro del vsys
no se puede establecer la supervisión de interfaces desde una interfaz compartida. Para obtener más información, consulte “Supervisión de interfaces” en
la pàgina 91.

También puede configurar el dispositivo NetScreen para supervisar la puerta de enlace predeterminada de una
interfaz que sea un cliente PPPoE o DHCP. Para ello, utilice la opción “Dynamic”: (CLI)
set interface interface monitor dynamic o bien (WebUI) Network > Interfaces > Edit (para la interfaz cliente DHCP
o PPPoE) > Monitor > Track IP > Add: seleccione Dynamic.
Nota: Cuando se configura el dispositivo NetScreen para que realice un seguimiento de una dirección IP, el
dispositivo NetScreen no agrega ninguna ruta de host para dicha dirección IP en la tabla de enrutamiento.
Pueden establecerse dos tipos de umbrales en la configuración del seguimiento de direcciones IP:
• Umbral de fallos de una determinada dirección IP supervisada: Número de intentos fallidos consecutivos
por obtener respuesta a una petición de eco (“ping”) de una determinada dirección IP que deben producirse
para que se considere un fallo de acceso a esa dirección. Si no se supera el umbral, el nivel de
conectividad con la dirección será aceptable; si se supera, el nivel de conectividad será inaceptable. Este
umbral se establece para cada dirección IP con un valor entre 1 y 200. El valor predeterminado es 3.
• Umbral de fallos de seguimiento de IP en la interfaz: Peso total de los intentos fallidos acumulados por
acceder a direcciones IP de la interfaz que causa la desactivación de las rutas asociadas a dicha interfaz.
Este umbral se puede ajustar en cualquier valor entre 1 y 255. El valor predeterminado es 1, lo que significa
que cualquier fallo producido al intentar acceder a una dirección IP configurada y supervisada provoca la
desactivación de las rutas asociadas a la interfaz.
Si se aplica un peso (o valor) a una dirección IP supervisada, se puede ajustar la importancia de la conectividad de
esa dirección en relación con el acceso a otras direcciones supervisadas. Puede asignar pesos relativamente
mayores a direcciones relativamente más importantes, y pesos menores a direcciones menos importantes.
Observe que los pesos asignados sólo tienen relevancia cuando se alcanza el umbral de fallos de una dirección IP
específica supervisada. Por ejemplo, si el umbral de fallos para el seguimiento de IP en una interfaz es 3, el fallo de
una única dirección IP sometida a seguimiento con un peso de 3 completa el umbral de fallos para el seguimiento
de IP en la interfaz, lo que hace que se desactiven las rutas asociadas a la interfaz. El fallo de una única dirección
IP sometida a seguimiento con un peso de 1 no completaría el umbral de fallos para el seguimiento de IP en la
interfaz, por lo que las rutas asociadas a la interfaz seguirían activas.

Ejemplo: Configuración del seguimiento de IP de interfaz

En el ejemplo siguiente, la interfaz ethernet1 está asociada a la zona Trust y tiene asignada la dirección de red
10.1.1.1/24. Las interfaces ethernet3 y ethernet4 están asociadas a la zona Untrust. La interfaz ethernet3 tiene
asignada la dirección de red 1.1.1.1/24 y está conectada al enrutador en 1.1.1.250. La interfaz ethernet4 tiene
asignada la dirección de red 2.2.2.1/24 y está conectada al enrutador en 2.2.2.250.
Enrutador
1.1.1.250
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Zona Trust Zona Untrust
10.1.1.0/24 Internet
ethernet4
2.2.2.1/24 Enrutador
2.2.2.250
Hay dos rutas predeterminadas configuradas: en una se utiliza ethernet3 como interfaz de salida con la dirección de
enrutador 1.1.1.250 como puerta de enlace; en la otra (configurada con un valor métrico de 10) se utiliza ethernet4
como interfaz de salida con la dirección de enrutador 2.2.2.250 como puerta de enlace. La ruta predeterminada en
la que se utiliza ethernet3 es la ruta preferente, puesto que tiene un valor métrico inferior (el valor métrico
predeterminado para rutas estáticas es 1). El siguiente resultado del comando get route indica cuatro rutas activas
para trust-vr (las rutas activas se señalan con un asterisco). La ruta predeterminada que pasa por ethernet3 está
activa; la ruta predeterminada que pasa por ethernet4 no está activa, puesto que tiene menos prioridad.

ns-> get route

untrust-vr (0 entries)
--------------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 4 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
3 0.0.0.0/0 eth4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth1 0.0.0.0 C 20 1 Root
Si la ruta que atraviesa ethernet3 deja de estar disponible, la ruta predeterminada que pasa por ethernet4 se
convertirá en ruta activa. Active y configure el seguimiento de IP en la interfaz ethernet3 para supervisar la dirección
de enrutador 1.1.1.250. Si el seguimiento de IP falla al acceder a 1.1.1.250, todas las rutas asociadas a la interfaz
ethernet3 pasan a ser inactivas en el dispositivo NetScreen. En consecuencia, la ruta predeterminada que atraviesa
ethernet4 se convierte en activa. Cuando el seguimiento IP pueda acceder a 1.1.1.250 de nuevo, la ruta
predeterminada que pasa por ethernet3 se convertirá en la ruta activa y, al mismo tiempo, la ruta predeterminada
que atraviesa ethernet4 pasará a estado inactivo, ya que tiene un nivel de prioridad menor que la ruta que pasa por
ethernet3.
Con los siguientes ajustes se activa el seguimiento de IP con un umbral de fallos de interfaz de 5 y se configura el
seguimiento de IP en la interfaz ethernet3 para supervisar la dirección IP de enrutador 1.1.1.250, que tiene
asignado un peso de 10.

WebUI
Network > Interfaces > Edit (para ethernet3) > Monitor: Introduzca los siguientes datos y haga clic en
Apply :
Enable Track IP: (seleccione)
Threshold: 5
> Monitor Track IP ADD: Introduzca los siguientes datos y haga clic en Add :
Static: (seleccione)
Track IP: 1.1.1.250
Weight: 10
CLI
set interface ethernet3 monitor track-ip ip 1.1.1.250 weight 10
set interface ethernet3 monitor track-ip threshold 5
set interface ethernet3 monitor track-ip
save
En este ejemplo, el umbral de fallos para la dirección de destino está ajustado al valor predeterminado (3). Es decir,
si el destino no devuelve una respuesta a tres peticiones de eco consecutivas, se aplica un peso de 10 al umbral de
fallos para el seguimiento de IP en la interfaz. Como el umbral de fallos para el seguimiento de IP en la interfaz es
5, un peso de 10 hace que se desactiven las rutas asociadas a la interfaz en el dispositivo NetScreen.
Puede verificar el estado del seguimiento de IP en la interfaz introduciendo el comando CLI
get interface ethernet3 track-ip tal como se indica a continuación:
ns-> get interface ethernet3 track-ip

ip address interval threshold wei gateway fail-count success-rate
1.1.1.250 1 1 10 0.0.0.0 343 46%
threshold: 5, failed: 1 ip(s) failed, weighted sum = 10

El comando get route indica que la ruta predeterminada que atraviesa ethernet4 está activa en estos momentos;
todas las rutas que pasan por ethernet3 han dejado de estar activas.
ns-> get route

untrust-vr (0 entries)
--------------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
iB - IBGP, eB - EBGP, O - OSPF, E1 - OSPF external type 1
E2 - OSPF external type 2
trust-vr (4 entries)
--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
4 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root
2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root
* 3 0.0.0.0/0 eth4 2.2.2.250 S 20 10 Root
* 6 2.2.2.0/24 eth4 0.0.0.0 C 0 1 Root
* 5 10.1.1.0/24 eth1 0.0.0.0 C 20 1 Root
Recuerde que aunque las rutas que pasan por ethernet3 no estén activas, el seguimiento de IP utiliza las rutas
asociadas a ethernet3 para continuar enviando peticiones de eco a la dirección IP de destino. Cuando el
seguimiento de IP puede acceder de nuevo a 1.1.1.250, la ruta predeterminada que atraviesa ethernet3 se vuelve a
convertir en la ruta activa del dispositivo NetScreen. Al mismo tiempo, la ruta predeterminada que pasa por
ethernet4 se convierte en ruta inactiva, ya que su nivel de prioridad es inferior al de la ruta predeterminada que pasa
por ethernet3.

Supervisión de interfaces
Un dispositivo NetScreen puede supervisar el estado físico y lógico de las interfaces y ejecutar una determinada
acción en función de los cambios observados. Por ejemplo, si el estado de una interfaz supervisada cambia de
activo a inactivo, puede ocurrir lo siguiente:
Si Entonces
el estado físico de una interfaz cambia de activo el cambio de estado puede provocar que también se desactive otra
a inactivo interfaz que esté supervisando a la que acaba de desactivarse. Puede
especificar si la segunda interfaz debe quedar física o lógicamente
desactivada.
El cambio de estado de la interfaz que se está desactivando
físicamente, o el peso combinado de ambas interfaces que se
desactivan al mismo tiempo, puede desencadenar un fallo de NSRP. Un
fallo de dispositivo NSRP o de grupo VSD sólo puede producirse como
resultado de un cambio en el estado físico de una interfaz.
el estado lógico de una interfaz cambia de activo el cambio de estado puede provocar que también se desactive otra
a inactivo como resultado de un fallo de interfaz que esté supervisando a la que acaba de desactivarse. Aunque
seguimiento de IP la primera interfaz esté lógicamente inactiva, puede especificar si el
estado inactivo de la segunda interfaz debe ser lógico o físico.
Una interfaz supervisando a otra interfaz Cambio de estado para ethernet3 Cambio de estado para
ethernet2
Utilizando el seguimiento de IP, ethernet3 Si
supervisa al enrutador en 1.1.1.250. • el número de intentos fracasados Si
de ejecutar un “ping” a 1.1.1.250 • el peso del fallo de
excede el umbral de fallos de esa ethernet3 es ≥ al umbral
Utilizando la supervisión de interfaces, dirección IP supervisada, de fallos de supervisión y
ethernet2 supervisa a ethernet3. • el peso de la IP supervisada • la acción en caso de fallo
1.1.1.250 es ≥ al umbral de fallos es cambiar de activo a
del objeto supervisado, inactivo,
• el peso del objeto supervisado es ≥
entonces ethernet2 cambia su
al umbral de fallos de supervisión y estado de activo a inactivo.
• la acción en caso de fallo es
cambiar de activo a inactivo,
ethernet3 ethernet2 entonces ethernet3 cambia su estado
IP 1.1.1.1 IP 2.1.1.1 de activo a inactivo.

Para establecer la supervisión de interfaces, ejecute cualquiera de los siguientes procedimientos:

WebUI
Network > Interfaces > Edit (para la interfaz que desee supervisar) > Monitor > Edit Interface: Introduzca los
siguientes datos y haga clic en Apply :
Interface Name: Seleccione la interfaz que desea supervisar.
Weight: Indique un peso entre 1 y 255.
CLI
set interface interface1 monitor interface interface2 [ weight number ]
Si no indica un peso, el dispositivo NetScreen aplica el valor predeterminado: 255.
Cuando dos interfaces se supervisan mutuamente, forman un bucle. En este caso, si cualquiera de las interfaces
cambia de estado, la otra interfaz del bucle también lo hace.
Nota: Una interfaz sólo puede pertenecer a un bucle a la vez. Juniper Networks no admite configuraciones en las
que una interfaz pertenezca a varios bucles.
Primer cambio de estado Segundo cambio de estado

Bucle – Dos interfaces supervisándose mutuamente
Si Si
Utilizando el seguimiento de IP, ambas • el número de intentos fracasados • el peso del fallo de la
interfaces supervisan enrutadores. de ejecutar un “ping” a cualquiera primera interfaz es ≥ al
de los enrutadores excede el umbral de fallos de
Utilizando la supervisión de interfaces, umbral de fallos de esa dirección supervisión de la segunda
también se supervisan mutuamente. IP supervisada, interfaz y
• el peso de la IP supervisada • la acción en caso de fallo
fallida es ≥ al umbral de fallos del es cambiar de activo a
objeto supervisado, inactivo,
• el peso del objeto supervisado es
la segunda interfaz también
≥ al umbral de fallos de cambia su estado de activo a
supervisión y
inactivo.
• la acción en caso de fallo es
ethernet3 ethernet2 cambiar de activo a inactivo,
IP 1.1.1.1 IP 2.1.1.1 esa interfaz cambia su estado de
activo a inactivo.

Ejemplo: Dos interfaces supervisadas

En este ejemplo configurará ethernet3 para supervisar dos interfaces, ethernet1 y ethernet2. Dado que el peso de
cada interfaz supervisada (8 + 8) es igual al umbral de fallos de supervisión (16), tanto ethernet1 como ethernet2
deben fallar (y cambiar su estado de activo a inactivo) simultáneamente para provocar el fallo de ethernet3 (y
9
cambiar a su estado de activo a inactivo) .
Nota: Este ejemplo omite la configuración del seguimiento de IP en las interfaces ethernet1 y ethernet2 (consulte
“Seguimiento de direcciones IP” en la pàgina 84). Sin seguimiento de IP, la única manera de que ethernet1 y
ethernet2 puedan fallar es que sean desconectadas físicamente de otros dispositivos de la red o que no puedan
mantener enlaces con esos dispositivos.
ethernet3 supervisa a ethernet1 y a ethernet2. Dado que el umbral de fallos

de supervisión (F-T) = los pesos (W) de ambas interfaces combinadas, para
hacer fallar a ethernet3 deben fallar las dos interfaces supervisadas.
Interfaces del dispositivo

NetScreen
ethernet1 – ethernet8
1 2 3 4 5 6 7 8
W=8 W=8 F-T: 16
Interfaces supervisadas:
ethernet1, peso 8
ethernet2, peso 8
Monitor Failure Threshold: 16
WebUI
Network > Interfaces > Edit (para ethernet3) > Monitor > Edit Interface: Introduzca los siguientes datos y haga
clic en Apply:
ethernet1: (seleccione), Weight: 8
Network > Interfaces > Edit (para ethernet3) > Monitor: Escriba 16 en el campo “Monitor Threshold” y haga
clic en Apply.
9. Si establece el umbral de fallos de supervisión en 8, o lo deja en 16 y establece el peso de cada interfaz supervisada en 16, el fallo de ethernet1 o de
ethernet2 puede hacer fallar a ethernet3.

CLI
set interface ethernet3 monitor interface ethernet1 weight 8
set interface ethernet3 monitor threshold 16
save
Ejemplo: Bucle de supervisión de interfaces
En este ejemplo, primero configurará el seguimiento de IP para dos interfaces, ethernet1 y ethernet3. A
continuación, configurará estas interfaces para supervisarse mutuamente de modo que, si una cambia de estado, la
otra actúe de igual modo. Por último, definirá dos conjuntos de rutas. El primer conjunto reenvia tráfico a través de
ethernet1 y ethernet3. El segundo conjunto tiene las mismas direcciones de destino, pero estas rutas tienen
métricas de menor rango y utilizan otras interfaces de salida (ethernet2 y ethernet4) y otras puertas de enlace
diferentes a las del primer conjunto. Con esta configuración, si el primer conjunto de interfaces falla, el dispositivo
NetScreen puede redirigir todo el tráfico a través del segundo conjunto. Todas las zonas se encuentran en el
dominio de enrutamiento trust-vr.
A los hosts de la A Internet ethernet1 y ethernet3 realizan el seguimiento de
zona Trust IP. ethernet1 supervisa al enrutador interno en
10.1.1.250. ethernet3 supervisa al enrutador
Enrutador Enrutador externo externo en 1.1.1.250.
interno 1.1.1.250 Track IP Failure Threshold: 10
10.1.1.250 1.1.2.250 Track IP Weight: 8
10.1.2.250 Track Object Weight: 8
10.1.1.1/24 10.1.2.1/24 1.1.1.1/24 1.1.2.1/24 Monitor Failure Threshold: 8
Zona Trust Zona Trust Zona Untrust Zona Untrust
Interfaces del dispositivo

NetScreen
ethernet1 – ethernet8
1 2 3 4 5 6 7 8
ethernet1 y ethernet3 se Si ethernet1 y ethernet3 se desactivan, las rutas que se refieren a
supervisan mutuamente. esas interfaces también quedan inactivas. Entonces, el dispositivo
Dado que el peso de la Bucle de interfaz supervisora: NetScreen redirige el tráfico a través de ethernet2 y ethernet4.
interfaz supervisada es =
al umbral de fallos de ethernet1 y ethernet3 Rutas
supervisión, el fallo de Monitored Interface Weight: 8 set route 10.1.0.0/16 interface ethernet1 gateway 10.1.1.250 metric 10
cualquier interfaz hace Monitor Failure Threshold: 8 set route 10.1.0.0/16 interface ethernet2 gateway 10.1.2.250 metric 12
que la otra falle también. set route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 metric 10
set route 0.0.0.0/0 interface ethernet4 gateway 1.1.2.250 metric 12

WebUI
1. Seguimiento de IP
Apply .
10
Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8
Track IP: 10.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10
Apply .
Monitor Threshold: 8
Track IP Option: Threshold: 8
Weight: 8
10. Para controlar si el estado de una interfaz se vuelve lógica o físicamente inactivo (o activo), debe utilizar el comando CLI set interface interface monitor
threshold number action { down | up } { logically | physically }. Sólo se pueden activar o desactivar interfaces físicas asociadas a cualquier zona de
seguridad distinta de la zona Null.

Track IP: 1.1.1.250
Weight: 8
Interval: 3 Seconds
Threshold: 10
2. Supervisión de interfaces
clic en Apply :
clic en Apply :
3. Rutas
Interface: ethernet1
Metric: 10
Metric: 12

Metric: 10
Metric: 12
CLI
1. Seguimiento de IP
set interface ethernet1 track-ip ip 10.1.1.250 weight 8
set interface ethernet1 track-ip threshold 8
set interface ethernet1 track-ip weight 8
set interface ethernet1 track-ip
set interface ethernet3 track-ip ip 1.1.1.250 weight 8
set interface ethernet3 track-ip threshold 8
set interface ethernet3 track-ip weight 8
set interface ethernet3 track-ip
2. Supervisión de interfaces
set interface ethernet1 monitor threshold 8 action down physically

set interface ethernet3 monitor threshold 8 action down physically

3. Rutas
set vrouter trust-vr route 10.1.0.0/16 interface ethernet1 gateway 10.1.1.250
metric 10
metric 12
metric 10
metric 12
save
Supervisión de zonas de seguridad

Además de supervisar interfaces individuales, una interfaz puede supervisar todas las interfaces de una zona de
seguridad (cualquier zona de seguridad salvo la suya propia). Para que falle toda una zona de seguridad, deben
fallar cada una de las interfaces asociadas a esa zona. Mientras permanezca activa una sola interfaz asociada a
una zona supervisada, el dispositivo NetScreen considerará que toda la zona está activa.
Para configurar una interfaz de modo que supervise una zona de seguridad, ejecute cualquiera de los siguientes
procedimientos:
WebUI
Network > Interfaces > Edit (para la interfaz que desee supervisar) > Monitor > Edit Zone: Introduzca los
siguientes datos y haga clic en Apply :
Zone Name: Seleccione la zona que desee que sea supervisada.
Weight: Indique un peso entre 1 y 255.
CLI
set interface interface monitor zone zone [ weight number ]
Si no indica un peso, el dispositivo NetScreen aplica el valor predeterminado: 255.

Interfaces inactivas y flujo de tráfico

La configuración del seguimiento de IP en una interfaz permite al dispositivo NetScreen redireccionar el tráfico saliente
a través de una interfaz distinta cuando determinadas direcciones IP dejan de ser accesibles a través de la primera
interfaz. Sin embargo, aunque es posible que el dispositivo NetScreen desactive las rutas asociadas a una interfaz
debido a un fallo de seguimiento de IP, la interfaz puede continuar físicamente activa y seguir enviando y recibiendo
tráfico. Por ejemplo, el dispositivo NetScreen sigue procesando el tráfico entrante de una sesión existente que puede
llegar a la interfaz original en la que se haya producido el fallo de seguimiento de IP. Asimismo, el dispositivo
NetScreen continúa utilizando la interfaz para enviar peticiones de comando ping a las direcciones IP de destino para
determinar si los destinos son accesibles de nuevo. En estos casos, el tráfico sigue atravesando una interfaz en la que
ha fallado el seguimiento de IP y para la que el dispositivo NetScreen ha desactivado las rutas. El modo en el que el
dispositivo NetScreen gestiona el tráfico de sesión en dicha interfaz depende de los siguientes factores:
• Si la interfaz en la que se configura el seguimiento de IP actúa como interfaz de salida para una sesión, es
posible que las respuestas de la sesión sigan llegando a la interfaz y que el dispositivo NetScreen continúe
procesándolas.
• Si la interfaz en la que se configura el seguimiento de IP actúa como interfaz de entrada para una sesión, la
aplicación del comando set arp always-on-dest hace que el dispositivo NetScreen redirija las respuestas de
la sesión a otra interfaz. Si no activa este comando, el dispositivo NetScreen reenviará las respuestas de la
sesión a través de la interfaz en la que ha fallado el seguimiento de IP aunque el dispositivo NetScreen haya
desactivado las rutas que utilizan dicha interfaz. (De forma predeterminada, este comando está desactivado).
De forma predeterminada, un dispositivo NetScreen guarda en caché la dirección MAC del iniciador de una
sesión cuando recibe el paquete inicial de una sesión nueva. Si introduce el comando CLI set arp
always-on-dest , el dispositivo NetScreen no guardará en caché la dirección MAC del iniciador de una
sesión. En su lugar, el dispositivo NetScreen realizará una consulta ARP cuando procese la respuesta
correspondiente a dicho paquete inicial. Si la dirección MAC del iniciador se encuentra en la tabla ARP, el
dispositivo NetScreen la utilizará. Si la dirección MAC no se encuentra en la tabla ARP, el dispositivo
NetScreen envía una petición ARP para la dirección MAC de destino y agrega la dirección MAC recibida a su
tabla ARP. El dispositivo NetScreen realiza otra consulta ARP cada vez que se produce un cambio de ruta.
En la siguiente sección se describen los diversos contextos en los que falla el seguimiento de IP en la interfaz de
salida y en la interfaz de entrada; y, en el caso de la última, qué ocurre cuando se utiliza el comando
set arp always-on-dest .
Nota: En la sección siguiente se describe cómo el seguimiento de IP dispara los cambios de rutas y cómo pueden
afectar estos cambios al flujo de paquetes de todos los dispositivos NetScreen distintos de NetScreen-5XT y -5GT.
En el caso de estos dispositivos, un fallo de seguimiento de IP dispara una conmutación por error de interfaz. Para
obtener más información, consulte “Interfaces Dual Untrust” en la pàgina 10 -69.

Fallo en la interfaz de salida

En el siguiente contexto, vamos a configurar el seguimiento de IP en ethernet2, que es la interfaz de salida para las
sesiones del host A al host B. El host A inicia la sesión enviando un paquete al host B, tal como se indica a
continuación.
Nota: Primero hay que crear dos rutas que conduzcan al host B, y ambas interfaces de salida deben encontrarse
en la misma zona para que se aplique la misma directiva al tráfico antes y después del redireccionamiento.
Flujo de tráfico del host A al host B: petición (inicio de sesión)

Interfaz de entrada Primera interfaz de salida
ethernet1 ethernet2 Seguimiento de IP
2 activado desde ethernet2
10.1.1.1/24 1.1.1.1/24
Zona Trust Consulta Consulta Consulta Zona Untrust

de de rutas de
sesiones directivas
10.1.1.0/24 Host B
3 4 2.2.2.2
Host A
10.1.1.5 1
Iniciador Respondedor
Segunda interfaz de salida Puertas de

ethernet3 enlace:
1.1.2.1/24 1.1.1.254
1.1.2.254
1. El host A en 10.1.1.5 envía un paquete a ethernet1 (10.1.1.1) destinado al host B en 2.2.2.2.
2. El dispositivo NetScreen realiza las siguientes tareas:
2.1 Consulta de sesiones : si se trata del primer paquete, el dispositivo NetScreen crea una sesión. Si el paquete pertenece a una
sesión existente, el dispositivo NetScreen actualiza la entrada de la tabla de sesiones.
2.2 Consulta de rutas : el dispositivo NetScreen realiza una consulta de rutas para el primer paquete de una sesión y cada vez que
la ruta cambia. Con la consulta de rutas se obtiene como resultado la siguiente ruta: para acceder a 0.0.0.0/0, enviar el paquete
a través de la interfaz ethernet2 hasta la puerta de enlace 1.1.1.254.
2.3 Consulta de directivas : el dispositivo NetScreen aplica las directivas de seguridad al tráfico interzonal procedente del host A
en la zona Trust y destinado al host B en la zona Untrust para el tipo de tráfico que el host A está enviando.
3. El dispositivo NetScreen reenvía el paquete a través de ethernet2 a la puerta de enlace en 1.1.1.254.
4. La puerta de enlace en 1.1.1.254 reenvía el paquete al siguiente salto. El enrutamiento continúa hasta que el host B recibe el paquete.

Cuando el host B responde al host A, el tráfico de retorno sigue una ruta de regreso similar a través del dispositivo
NetScreen, como se indica a continuación.
Flujo de tráfico del host A al host B: respuesta

Primera interfaz de salida
Interfaz de entrada ethernet2
ethernet1 1.1.1.1/24 Seguimiento de IP desde
10.1.1.1/24 ethernet2 correcto.
Zona Trust 3 Consulta de Zona Untrust

sesiones
10.1.1.0/24 Host B
2 2.2.2.2
Host A 1
10.1.1.5 4
Segunda interfaz de salida Puertas de enlace:

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. El host B en 2.2.2.2 responde con un paquete destinado al host A en 10.1.1.5 (omitiendo NAT para mayor
claridad).
2. Cuando la puerta de enlace en 1.1.1.254 recibe la respuesta, la reenvía al siguiente salto, que es 1.1.1.1, la
dirección IP de ethernet2.
3. El dispositivo NetScreen realiza una consulta de sesiones. Como se trata de una respuesta, el dispositivo
NetScreen la relaciona con una sesión existente y actualiza la entrada de la tabla de sesiones.
4. Utilizando la dirección MAC del host A guardada en caché o realizando una consulta ARP para averiguar la
dirección MAC, el dispositivo NetScreen reenvía el paquete a través de ethernet1 al host A.

Si falla el seguimiento de IP en ethernet2, el dispositivo NetScreen desactiva las rutas que utilicen ethernet2 y utiliza
ethernet3 para el tráfico saliente destinado al host B. Sin embargo, las respuestas del host B al host A pueden llegar
tanto a través de ethernet2 como a través de ethernet3, y el dispositivo NetScreen las reenvía a través de ethernet1
al host A.
Flujo de tráfico del host A al host B: el fallo de seguimiento de IP dispara el redireccionamiento

ethernet1 ethernet2 Seguimiento de IP
1 desde ethernet2
10.1.1.1/24 1.1.1.1/24 incorrecto.
Zona Trust Cambio Actualización Zona Untrust
de ruta de sesiones
10.1.1.0/24 4
Host B
3 2.2.2.2
Host A
10.1.1.5 2
Nota: El tráfico de salida sólo utiliza ethernet3; en Segunda interfaz de Puertas de

cambio, el tráfico de entrada puede utilizar tanto salida enlace:
ethernet2 como ethernet3. ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. Cuando falla el seguimiento de IP en ethernet2, el dispositivo NetScreen realiza las siguientes tareas:
1.1 Cambio de ruta : el dispositivo NetScreen desactiva todas las rutas que utilicen ethernet2. Realiza
una consulta de rutas y sustituye la ruta que conduce a 2.2.2.2 y que pasa por ethernet2 y la puerta
de enlace 1.1.1.254 por otra ruta que pasa por ethernet3 y la puerta de enlace 1.1.2.254.
1.2 Actualización de sesión : el dispositivo NetScreen analiza la tabla de sesiones en busca de todas
las entradas que utilicen ethernet2 y las redirecciona a través de ethernet3 hacia la puerta de enlace
1.1.2.254.
2. El dispositivo NetScreen redirecciona el tráfico del host A a través de ethernet3 hacia 1.1.2.254.
3. Las respuestas del host B pueden llegar a ethernet2 o a ethernet3. El dispositivo NetScreen realiza una
consulta de sesiones y relaciona los paquetes con una sesión existente. Independientemente de la interfaz
a la que lleguen los paquetes, el dispositivo NetScreen los reenvía a través de ethernet1 al host A.
4. El dispositivo NetScreen reenvía el paquete a través de ethernet1 al host A.

Fallo en la interfaz de entrada

En el siguiente supuesto, configurará de nuevo el seguimiento de IP en ethernet2, pero esta vez ethernet2 será la
interfaz de entrada en el dispositivo NetScreen para las sesiones del host B al host A. El host B iniciará la sesión
enviando un paquete al host A, tal como se indica a continuación.
Flujo de tráfico del host B al host A: petición (inicio de sesión)

ethernet1 2 ethernet2 Seguimiento de IP
10.1.1.1/24 1.1.1.1/24 activado desde ethernet2.
Zona Trust Consulta de Consulta Consulta de Zona Untrust

directivas de rutas sesiones
10.1.1.0/24 Host B
1 2.2.2.2
Host A
10.1.1.5 3
Respondedor Iniciador

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. El host B en 2.2.2.2 envía un paquete destinado al host A en 10.1.1.5 (omitiendo NAT para mayor claridad).
2. Cuando el paquete llega a ethernet2, el dispositivo NetScreen realiza las siguientes tareas:
2.1 Consulta de sesiones (y como se trata del primer paquete de la sesión, crea una entrada nueva en
la tabla de sesiones)
2.2 Consulta de rutas
2.3 Consulta de directivas
3. El dispositivo NetScreen reenvía el paquete a través de ethernet1 al host A en 10.1.1.5.
Cuando el host A responde al host B, el tráfico de retorno sigue una ruta de regreso similar a través del dispositivo
NetScreen, como se indica a continuación.

Flujo de tráfico del host B al host A: respuesta

ethernet1 ethernet2 Seguimiento de IP desde
10.1.1.1/24 2 1.1.1.1/24 ethernet2 correcto.
Zona Trust Consulta de Zona Untrust

sesiones
10.1.1.0/24 Host B
3 4 2.2.2.2
Host A
10.1.1.5 1

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1. El host A en 10.1.1.5 envía un paquete de respuesta a ethernet1 en 10.1.1.1 destinado al host B (2.2.2.2).
2. El dispositivo NetScreen realiza una consulta de sesiones. Como se trata de una respuesta, el dispositivo NetScreen
la relaciona con una sesión existente y actualiza la entrada de la tabla de sesiones.
3. Utilizando la dirección MAC de la puerta de enlace en 1.1.1.254 guardada en caché o realizando una consulta ARP
para averiguar la dirección MAC, el dispositivo NetScreen reenvía el paquete a través de ethernet2 a la puerta de enlace.
4. Cuando la puerta de enlace en 1.1.1.254 recibe la respuesta, la reenvía al siguiente salto. El enrutamiento continúa
hasta que el host B recibe el paquete.
Si falla el seguimiento de IP en ethernet2, el dispositivo NetScreen desactiva las rutas que utilicen ethernet2 y utiliza
ethernet3 para el tráfico saliente destinado al host B. Sin embargo, las peticiones del host B al host A pueden seguir
llegando a través de ethernet2, y el dispositivo NetScreen las reenvía a través de ethernet1 al host A. El flujo de
datos para las peticiones del host B al host A sigue teniendo el mismo aspecto después de que se produzca un fallo
de seguimiento de IP. Sin embargo, las respuestas del host A pueden atravesar dos rutas distintas, en función de la
aplicación del comando set arp always-on-dest .
Si activa el comando set arp always-on-dest , el dispositivo NetScreen enviará una petición ARP para la dirección
MAC de destino cuando procese la respuesta al primer paquete de una sesión o cuando se produzca un cambio de
ruta. (Cuando este comando está desactivado, el dispositivo NetScreen guarda el caché la dirección MAC del
iniciador de la sesión y la utiliza para procesar las respuestas. De forma predeterminada, este comando está
desactivado).

Cuando falla el seguimiento de IP en ethernet2, el dispositivo NetScreen desactiva primero todas las rutas que
utilicen ethernet2 y realiza una consulta de rutas. Encuentra otra ruta para acceder al host B a través de ethernet3 y
la puerta de enlace en 1.1.2.254. A continuación, analiza la tabla de sesiones y redirige todas las sesiones a la
nueva ruta. Si está activado el comando set arp always-on-dest , el dispositivo NetScreen realizará una consulta
ARP cuando reciba el siguiente paquete del host A porque el paquete pertenece a una sesión afectada por el
cambio de ruta. Independientemente de la interfaz de entrada a la que lleguen los paquetes del host B, el
dispositivo NetScreen envía todas las respuestas del host A a través de ethernet3 a la puerta de enlace en
1.1.2.254.
Flujo de tráfico del host B al host A: el fallo de seguimiento de IP dispara el redireccionamiento

10.1.1.1/24 1 1.1.1.1/24 ethernet2 incorrecto.
Zona Trust Cambio Actualización 2 Zona Untrust

de ruta de sesiones
10.1.1.0/24 Host B
3 2.2.2.2
Host A
10.1.1.5

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1.1 Cambio de ruta : el dispositivo NetScreen desactiva todas las rutas que utilicen ethernet2. Sustituye la ruta que
conduce a 2.2.2.2 y que pasa por ethernet2 y la puerta de enlace 1.1.1.254 por otra ruta que pasa por ethernet3 y la
puerta de enlace 1.1.2.254.
1.2 Actualización de sesiones : el dispositivo NetScreen analiza la tabla de sesiones en busca de todas las entradas
que utilicen ethernet2 y las redirecciona a través de ethernet3 hacia la puerta de enlace 1.1.2.254.
2. Es posible que las peticiones procedentes del host B sigan llegando a ethernet2, o bien, que la estructura de enrutamiento
las redirija a ethernet3. El dispositivo NetScreen realiza una consulta de sesiones y relaciona el paquete con una sesión
existente.
3. Como está activado el comando set arp always-on-dest , el dispositivo NetScreen realiza una consulta ARP para la
respuesta del host A y la envía a través de ethernet3 a la puerta de enlace en 1.1.2.254.

Si está activado el comando unset arp always-on-dest (que es la configuración predeterminada), el dispositivo
NetScreen utiliza la dirección MAC para la puerta de enlace en 1.1.1.1 que guardó en caché cuando el host B envió
el paquete de sesión inicial. El dispositivo NetScreen continúa enviando las respuestas de sesión a través de
ethernet2. En este caso, el fallo de seguimiento de IP no afecta al flujo de datos a través del dispositivo NetScreen.
Flujo de tráfico del host B al host A: el fallo de seguimiento de IP no dispara el redireccionamiento

10.1.1.1/24 1.1.1.1/24 ethernet2 incorrecto .
2
Zona Trust Consulta de Zona Untrust

sesiones
10.1.1.0/24 Host B
3 4 2.2.2.2
Host A
10.1.1.5 1

ethernet3 1.1.1.254
1.1.2.1/24 1.1.2.254
1.1 Cambio de ruta : el dispositivo NetScreen desactiva todas las rutas que utilicen ethernet2. Sustituye la ruta que conduce
a 2.2.2.2 y que pasa por ethernet2 y la puerta de enlace 1.1.1.254 por otra ruta que pasa por ethernet3 y la puerta de enlace
1.1.2.254.
1.2 Actualización de sesiones : el dispositivo NetScreen analiza la tabla de sesiones en busca de todas las entradas que
utilicen ethernet2 y las redirecciona a través de ethernet3 hacia la puerta de enlace 1.1.2.254. Sin embargo, como el
dispositivo NetScreen ha guardado en caché la dirección MAC de la puerta de enlace en 1.1.1.254, continúa utilizando
dicha dirección MAC para las respuestas procedentes del host A.
2. Es posible que las peticiones procedentes del host B sigan llegando a ethernet2. El dispositivo NetScreen realiza una consulta
de sesiones, relaciona el paquete con una sesión existente y lo reenvía a través de ethernet1 al host A en 10.1.1.5.
3. Cuando el host A responde, el dispositivo NetScreen reenvía la respuesta desde ethernet2 a la puerta de enlace en 1.1.1.254.
Puesto que el comando set arp always-on-dest no está activado, la dirección MAC permanecerá inalterada en la tabla de
sesiones desde la creación inicial de la entrada.

Capítulo 4
Modos de las interfaces

4
Las interfaces pueden funcionar en tres modos diferentes: Traducción de direcciones de red (NAT), modo de ruta
(“Route”) y modo transparente (“Transparent”). Si una interfaz asociada a una zona de capa 3 (“Layer 3”) tiene una
1
dirección IP, el modo de funcionamiento de esa interfaz se puede definir como NAT o Route. Una interfaz asociada
a una zona de capa 2 (“Layer 2”) (como las zonas predefinidas v1-trust, v1-untrust y v1-dmz, o una zona de capa 2
definida por el usuario) debe estar en modo transparente. El modo de funcionamiento se selecciona al configurar la
interfaz.
Este capítulo contiene las siguientes secciones:
• “Modo transparente” en la pàgina 108
– “Ajustes de zona” en la pàgina 109
– “Reenvío de tráfico” en la pàgina 110
– “Opciones “unicast” desconocidas” en la pàgina 112
• “Modo NAT” en la pàgina 127
– “Tráfico NAT entrante y saliente” en la pàgina 129
– “Ajustes de interfaz” en la pàgina 130
• “Modo de ruta” en la pàgina 135
– “Ajustes de interfaz” en la pàgina 136
1. Aunque se puede definir el modo de funcionamiento de una interfaz asociada a cualquier zona de capa 3 como NAT, el dispositivo NetScreen solamente
aplicará NAT al tráfico que pase por esa interfaz en dirección hacia la zona Untrust. NetScreen no aplica NAT al tráfico destinado a ninguna zona que no
sea la zona Untrust. Asimismo, observe que aunque NetScreen permite poner una interfaz de la zona Untrust en modo NAT, esto no activa ninguna
operación de NAT.

Capítulo 4 Modos de las interfaces Modo transparente
MODO TRANSPARENTE
Cuando una interfaz está en modo transparente, el dispositivo NetScreen filtra los paquetes que atraviesan el
cortafuegos sin modificar ninguna información de origen ni de destino en el encabezado de los paquetes IP. Todas las
interfaces se comportan como si fuesen parte de la misma red, con el dispositivo NetScreen actuando en gran medida
como conmutador o puente de capa 2 (“Layer 2”). En el modo transparente, las direcciones IP de las interfaces se
establecen en 0.0.0.0, haciendo que el dispositivo NetScreen parezca “invisible” (o “transparente”) a los usuarios.
209.122.30.3
209.122.30.2 209.122.30.4
209.122.30.1
209.122.30.5
Zona Trust
Conmutador
Espacio de
direcciones público
Zona Untrust
Enrutador
externo
A Internet
El modo transparente es un medio muy práctico para proteger servidores web, o cualquier otra clase de servidor
que reciba principalmente tráfico de fuentes no fiables. Utilizar el modo transparente tiene las siguientes ventajas:
• Elimina la necesidad de reconfigurar los ajustes IP de los enrutadores y servidores protegidos
• Elimina la necesidad de crear direcciones IP asignadas o virtuales para que el tráfico entrante llegue a los
servidores protegidos

Ajustes de zona
De forma predeterminada, ScreenOS crea una zona de función, la zona VLAN, y tres zonas de seguridad L2:
V1-Trust, V1-Untrust y V1-DMZ.
Zona VLAN
La zona VLAN contiene la interfaz VLAN1, que tiene la misma configuración y las mismas posibilidades de
administración que una interfaz física. Cuando el dispositivo NetScreen está en modo transparente, utiliza
la interfaz VLAN1 para administrar el dispositivo y terminar el tráfico VPN. Puede configurar la interfaz
VLAN1 para permitir que los hosts en las zonas de seguridad L2 puedan administrar el dispositivo. Para
ello, debe establecer la dirección IP de la interfaz VLAN1 en la misma subred que los hosts de las zonas de
seguridad L2.
Para el tráfico administrativo, la IP de administración de VLAN1 tiene preferencia sobre la IP de la interfaz
VLAN1. Puede reservar la IP de administración de VLAN1 para el tráfico administrativo y dedicar la IP de la
interfaz VLAN1 solamente a la terminación del túnel VPN.
Zonas de capa 2 predefinidas

ScreenOS proporciona tres zonas de seguridad L2 predeterminadas: V1-Trust, V1-Untrust y V1-DMZ.
Estas tres zonas comparten el mismo dominio L2. Cuando se configura una interfaz en una de las zonas,
se agrega al dominio L2 compartido por todas las interfaces en todas las zonas L2. Para poder
comunicarse, todos los hosts de las zonas L2 deben pertenecer a la misma subred.
Según se describe en la sección anterior, cuando el dispositivo está en modo transparente se utiliza la
interfaz VLAN1 para administrar el dispositivo. Para que el tráfico administrativo pueda alcanzar la interfaz
VLAN1, es necesario habilitar las opciones de administración en la interfaz VLAN1 y en la(s) zona(s) que
atravesará dicho tráfico. De forma predeterminada, todas las opciones de administración están habilitadas
en la zona V1-Trust. Para que los hosts de otras zonas puedan administrar el dispositivo, debe establecer
esas mismas opciones en las zonas a las que pertenezcan.
Nota: Para ver qué interfaces físicas están preasociadas a las zonas L2 de cada plataforma NetScreen,
consulte el manual del instalador de cada plataforma.

Reenvío de tráfico
Los dispositivos NetScreen que operan en la capa 2 (“Layer 2” o “L2”) no permiten ningún tráfico interzonal ni
intrazonal a menos que haya una directiva configurada en el dispositivo. Para obtener más información sobre cómo
establecer directivas, consulte “Directivas” en la pàgina 305. Una vez configurada una directiva en el dispositivo
NetScreen, hace lo siguiente:
• Permite o deniega el tráfico especificado en la directiva
• Permite el tráfico ARP y L2 que no es IP “multicast” (de un emisor a múltiples destinatarios) y “broadcast”
(de múltiples emisores a múltiples destinatarios). Desde ese momento, el dispositivo NetScreen puede
recibir y transmitir tráfico “broadcast” L2 para el protocolo en árbol “Spanning Tree Protocol”.
• Continúa bloqueando todo el tráfico “unicast” que no es IP ni ARP, así como el tráfico IPSec.
El comportamiento de reenvío del dispositivo se puede modificar de la siguiente forma:
• Para bloquear todo el tráfico L2 que no es IP ni ARP, incluyendo el tráfico “multicast” y “broadcast”, ejecute
el comando unset interface vlan1 bypass-non-ip-all.
• Para permitir que todo el tráfico L2 que no es IP pueda pasar por el dispositivo, ejecute el comando set
interface vlan1 bypass-non-ip.
• Para restablecer el comportamiento predeterminado del dispositivo, consistente en bloquear todo el tráfico
“unicast” que no es IP ni ARP, ejecute el comando unset interface vlan1 bypass-non-ip.
– Observe que el comando unset interface vlan1 bypass-non-ip-all siempre sobrescribe al comando
unset interface vlan1 bypass-non-ip cuando ambos se encuentran en el archivo de configuración.
Por lo tanto, si anteriormente ejecutó el comando unset interface vlan1 bypass-non-ip-all y ahora
desea que el dispositivo recupere su comportamiento predeterminado, consistente en bloquear
únicamente el tráfico “unicast” que no es IP ni ARP, deberá ejecutar primero el comando set interface
vlan1 bypass-non-ip para permitir que todo el tráfico que no es IP pase por el dispositivo. A
continuación, deberá ejecutar el comando unset interface vlan1 bypass-non-ip para bloquear
solamente el tráfico unicast que no es IP ni ARP.

• Para permitir que un dispositivo NetScreen transmita tráfico IPSec sin intentar terminarlo, utilice el comando
set interface vlan1 bypass-others-ipsec. El dispositivo NetScreen permitirá entonces que el tráfico IPSec
pase a través de otros puntos terminales de la VPN.
Nota: Un dispositivo NetScreen con interfaces en modo transparente requiere rutas para dos fines: dirigir
el tráfico autogenerado, como las capturas SNMP, y reenviar tráfico VPN después de encapsularlo o
desencapsularlo.

Opciones “unicast” desconocidas

Cuando un host o cualquier clase de dispositivo de red desconoce la dirección MAC asociada a la dirección IP de
otro dispositivo, utiliza el protocolo de resolución de direcciones (“Address Resolution Protocol” o “ARP”) para
obtenerla. El solicitante difunde mediante “broadcast” una consulta ARP (arp-q) al resto de dispositivos de la misma
subred. La consulta arp-q solicita al dispositivo con la dirección IP de destino especificada que devuelva una
respuesta ARP (arp-r), lo que proporcionará al solicitante la dirección MAC del dispositivo que responde. Cuando
los demás dispositivos de la subred reciben la consulta arp-q, comprueban la dirección IP de destino y, al no ser la
suya, descartan el paquete. Sólo el dispositivo que tenga la dirección IP especificada devolverá un mensaje arp-r.
Cuando un dispositivo ha establecido una correspondencia entre una dirección IP y una dirección MAC, almacena
la información en su caché de ARP.
A medida que el tráfico ARP atraviesa un dispositivo NetScreen en modo transparente, el dispositivo analiza la
dirección MAC de origen en cada paquete y memoriza qué interfaz conduce a esa dirección MAC. De hecho, el
dispositivo NetScreen aprende qué interfaz conduce a qué dirección MAC observando las direcciones MAC de
origen en todos los paquetes que recibe. A continuación, almacena esta información en su tabla de reenvíos.
Nota: Un dispositivo NetScreen en modo transparente no permite ningún tráfico entre zonas a menos que haya
una directiva configurada en el dispositivo. Para obtener más información sobre cómo el dispositivo reenvia tráfico
cuando está en modo transparente, consulte “Reenvío de tráfico” en la pàgina 110.

Puede ocurrir que un dispositivo envíe un paquete unicast con una dirección MAC de destino tomada de su caché
ARP, pero que el dispositivo NetScreen no tenga registrada en su tabla de reenvíos. Por ejemplo, el dispositivo
NetScreen borra su tabla de reenvíos cada vez que se reinicia. (También el usuario podría haber borrado la tabla
de reenvíos con el comando CLI clear arp.) Cuando un dispositivo NetScreen en modo transparente recibe un
paquete unicast para el cual no contiene ninguna entrada en su tabla de reenvíos, puede tomar una de estas dos
decisiones:
• Después de realizar una consulta de directivas para determinar a qué zonas está permitido enviar el tráfico
procedente de la dirección de origen, inundar el paquete inicial saliendo por las interfaces asociadas a esas
zonas y seguir utilizando la interfaz que reciba una respuesta. Se trata de la opción “Flood”, que está
habilitada de forma predeterminada.
• Descartar el paquete inicial, inundar con consultas ARP (y, opcionalmente, paquetes “trace-route”, que son
peticiones de eco ICMP con el valor “time-to-live” en 1) saliendo por todas las interfaces (excepto por la
interfaz por la que entró el paquete) y enviar los paquetes subsiguientes por cualquier interfaz que reciba
una respuesta ARP (o trace-route) del enrutador o del host cuya dirección MAC coincida con la dirección
MAC de destino en el paquete inicial. La opción “trace-route” permite al dispositivo NetScreen descubrir la
dirección MAC de destino cuando ésta se encuentre en una subred no adyacente.
Nota: De los dos métodos (“flood” y “ARP/trace-route”), ARP es más seguro porque el dispositivo
NetScreen inunda con preguntas ARP y paquetes trace-route (no el paquete inicial) saliendo por todas
las interfaces.
Método de inundación
El método de inundación reenvía paquetes del mismo modo que la mayoría de conmutadores (“switches”) de la
capa 2. Un conmutador mantiene una tabla de reenvíos que contiene direcciones MAC y sus puertos asociados
para cada dominio de capa 2. La tabla también contiene la interfaz correspondiente a través de la cual el
conmutador puede reenviar tráfico a cada dispositivo. Cada vez que un paquete llega con una nueva dirección MAC
de origen en su encabezado de trama, el conmutador agrega la dirección MAC a su tabla de reenvíos. También
detecta a través de qué interfaz llegó el paquete. Si la dirección MAC de destino es desconocida para el
conmutador, éste duplica el paquete y lo inunda saliendo por todas las interfaces (a excepción de la interfaz por la
que llegó el paquete). Memoriza la dirección MAC (desconocida hasta ese momento) y la interfaz correspondiente
cuando recibe una respuesta con esa dirección MAC en una de sus interfaces.

Cuando se habilita el método de inundación y el dispositivo NetScreen recibe una trama de Ethernet con una
dirección MAC de destino que no figura en la tabla de direcciones MAC del dispositivo NetScreen, inunda el
paquete saliendo por todas las interfaces.
Método de inundación ethernet1 ethernet4

IP 0.0.0.0/0 IP 0.0.0.0/0
Zona NetScreen inunda el

El paquete llega paquete saliendo por
a ethernet1. V1-DMZ
ethernet4, pero no recibe
Zona V1-Trust Enrutador ninguna respuesta.
NetScreen inunda el
paquete saliendo por
Espacio de ethernet3. Cuando recibe
direcciones una respuesta, hace lo
común siguiente:
ethernet2 ethernet3 • Memoriza qué interfaz
IP 0.0.0.0/0 IP 0.0.0.0/0 conduce a la dirección
MAC especificada
NetScreen inunda el • Almacena el registro (o
Zona tupla) MAC/interfaz en su
paquete saliendo por Zona V1-Untrust
ethernet2, pero no tabla de reenvíos
L2-Finance
recibe ninguna • Sigue utilizando
respuesta. ethernet3 durante el
resto de la sesión
Enrutador Enrutador
Para habilitar el método de inundación para el tratamiento de paquetes unicast desconocidos, ejecute cualquiera de
los siguientes procedimientos:
WebUI
Network > Interface > Edit (para VLAN1): Para las opciones de multidifusión (“broadcast”), seleccione
Flood y haga clic en OK .
CLI
set interface vlan1 broadcast flood
save
Método ARP/Trace-Route
2
Cuando se habilita el método ARP con la opción “trace-route” y el dispositivo NetScreen recibe una trama de
Ethernet con una dirección MAC de destino que no consta en su tabla de MAC, el dispositivo NetScreen realiza la
siguiente serie de acciones:
1. El dispositivo NetScreen detecta la dirección MAC de destino en el paquete inicial (y, si aún no está, agrega
la dirección MAC de origen y su interfaz correspondiente a la tabla de reenvíos).
2. El dispositivo NetScreen descarta el paquete inicial.
3. El dispositivo NetScreen genera dos paquetes: la consulta ARP (arp-q) y un trace-route (una petición de
eco ICMP, o PING) con un valor 1 en el campo “time-to-live” (TTL), e inunda esos paquetes saliendo por
todas las interfaces excepto por la que llegó el paquete inicial. Para los paquetes arp-q y las peticiones de
eco ICMP, el dispositivo NetScreen utiliza las direcciones IP de origen y de destino del paquete inicial. Para
los paquetes arp-q, el dispositivo NetScreen reemplaza la dirección MAC de origen del paquete inicial con
la dirección MAC para VLAN1, y reemplaza la dirección MAC de destino del paquete inicial con ffff.ffff.ffff.
Para la opción “trace-route”, el dispositivo NetScreen utiliza las direcciones MAC de origen y de destino del
paquete inicial en las peticiones de eco ICMP que difunde mediante “broadcasts”.
3
Si la dirección IP de destino pertenece a un dispositivo en la misma subred que la dirección IP de entrada,
el host devuelve una respuesta ARP (arp-r) con su dirección MAC, indicando así la interfaz a través de la
cual el dispositivo NetScreen debe reenviar el tráfico destinado a esa dirección. (Consulte “Método ARP” en
la pàgina 117).
Si la dirección IP de destino pertenece a un dispositivo en una subred situada más allá de la subred de la
dirección IP de entrada, trace-route devuelve las direcciones IP y MAC del enrutador que conduce al
4
destino y, aún más importante, indica la interfaz a través de la cual el dispositivo NetScreen debe reenviar
el tráfico destinado a esa dirección MAC. (Consulte “Trace-Route” en la pàgina 118).
2. Cuando se habilita el método ARP, la opción “trace-route” se habilita de forma predeterminada. También puede habilitar el método ARP sin la opción
“trace-route”. Sin embargo, este método solamente permite al dispositivo NetScreen descubrir la dirección MAC de destino para un paquete unicast si dicha
dirección se encuentra en la misma subred que la dirección IP de entrada. (Para obtener más información sobre la dirección IP de entrada, consulte la nota
al pie de la página siguiente).
3. La dirección IP de entrada hace referencia a la dirección IP del último dispositivo que envió el paquete al dispositivo NetScreen. Este dispositivo puede ser
el origen que envió el paquete o un enrutador que lo reenvió.
4. De hecho, “trace-route” devuelve las direcciones IP y MAC de todos los enrutadores en la subred. A continuación, el dispositivo NetScreen compara la
dirección MAC de destino del paquete inicial con la dirección MAC de origen en los paquetes arp-r para determinar a qué enrutador dirigirse, y por lo tanto,
qué interfaz utilizar para alcanzar ese destino.

4. Combinando la dirección MAC de destino obtenida del paquete inicial con la interfaz que conduce a esa
dirección MAC, el dispositivo NetScreen agrega una nueva entrada a su tabla de reenvíos.
5. El dispositivo NetScreen reenvía a su destino a través de la interfaz correcta todos los paquetes que reciba
posteriormente.
Para habilitar el método ARP/trace-route para tratar los paquetes unicast desconocidos, ejecute cualquiera de los
siguientes procedimientos:
WebUI
Network > Interface > Edit (para VLAN1): Para las opciones de multidifusión (“broadcast”), seleccione ARP
y haga clic en OK .
CLI
set interface vlan1 broadcast arp
save
Nota: De forma predeterminada, la opción “trace-route” está habilitada. Si desea utilizar ARP sin la opción
“trace-route”, introduzca el comando siguiente: unset interface vlan1 broadcast arp trace-route . Este
comando desactiva la opción “trace-route”, pero no ARP como método seleccionado para tratar los
paquetes unicast desconocidos.

La ilustración siguiente muestra cómo el método ARP puede localizar la dirección MAC de destino cuando la
dirección IP de destino se encuentra en una subred adyacente.
Método ARP VLAN1

210.1.1.1/24
Nota: A continuación solamente se muestran los 0010.db15.39ce
elementos relevantes del encabezado de los PC A Enrutador A
paquetes y los últimos cuatro dígitos de las 210.1.1.5 ethernet1 ethernet4 210.1.1.100
direcciones MAC. 00aa.11aa.11aa 0.0.0.0/0 0.0.0.0/0 00cc.11cc.11cc
Si el paquete siguiente 0010.db15.39ce 0010.db15.39ce
Trama Ethernet Datagrama IP
dest orig tipo orig dest Zona

11bb 11aa 0800 210.1.1.5 210.1.1.75 V1-DMZ
Zona V1-Trust
llega a ethernet1 y la tabla de reenvíos no contiene
una entrada para la dirección MAC 00bb.11bb.11bb,
el dispositivo NetScreen inunda el siguiente paquete
arp-q saliendo por eth2, eth3 y eth4. Espacio de
direcciones
Trama Ethernet Mensaje ARP común
dest orig tipo orig dest
ethernet2 ethernet3
ffff 39ce 0806 210.1.1.5 210.1.1.75 0.0.0.0/0 0.0.0.0/0
0010.db15.39ce 0010.db15.39ce
Cuando el dispositivo NetScreen
recibe el siguiente arp-r en eth2, Zona
Zona V1-Untrust
Trama Ethernet Mensaje ARP L2-Finance
dest orig tipo orig dest
39ce 11bb 0806 210.1.1.75 210.1.1.5

PC B Enrutador B
podrá asociar la dirección MAC a la 210.1.1.75 210.1.1.200
interfaz que conduce hacia ella. 00bb.11bb.11bb 00dd.11dd.11dd

La ilustración siguiente muestra cómo la opción “trace-route” puede localizar la dirección MAC de destino cuando la
dirección IP de destino se encuentra en una subred no adyacente.
Trace-Route VLAN1
210.1.1.1/24
Nota: A continuación solamente se muestran los 0010.db15.39ce
elementos relevantes del encabezado de los PC A Enrutador A
paquetes y los últimos cuatro dígitos de las 210.1.1.5 ethernet1 ethernet4 210.1.1.100
direcciones MAC. 00aa.11aa.11aa 0.0.0.0/0 0.0.0.0/0 00cc.11cc.11cc
Si el paquete siguiente 0010.db15.39ce 0010.db15.39ce
Trama Ethernet Datagrama IP
dest orig tipo orig dest Zona

V1-DMZ
11dd 11aa 0800 210.1.1.5 195.1.1.5
Zona V1-Trust
llega a ethernet1 y la tabla de reenvíos no contiene
una entrada para la dirección MAC 00dd.11dd.11dd,
el dispositivo NetScreen inunda el siguiente paquete
trace-route saliendo por eth2, eth3 y eth4. Espacio de
direcciones
Trama Ethernet Mensaje ICMP común
dest orig tipo orig dest TTL ethernet2 ethernet3
0.0.0.0/0 0.0.0.0/0
11dd 11aa 0800 210.1.1.5 195.1.1.5 1 0010.db15.39ce 0010.db15.39ce
Cuando el dispositivo NetScreen recibe la siguiente Zona
respuesta en eth3, Zona V1-Untrust
Trama Ethernet Mensaje ICMP
L2-Finance
dest orig tipo orig dest msg
11aa 11dd 0800 210.1.1.200 210.1.1.5 UI message PC B Enrutador B Servidor C

210.1.1.75 210.1.1.200 195.1.1.5
puede ahora asociar la dirección MAC a la 00bb.11bb.11bb 00dd.11dd.11dd 00dd.22dd.22dd
interfaz que conduce hacia ella.

Ejemplo: Interfaz VLAN1 para administración

En este ejemplo configurará el dispositivo NetScreen para la administración a su interfaz VLAN1 como sigue:
• Asignará a la interfaz VLAN1 la dirección IP 1.1.1.1/24.
5
• Habilitará Web, Telnet, SSH y Ping tanto en la interfaz VLAN1 como en la zona de seguridad V1-Trust .
Nota: Para administrar el dispositivo desde una zona de seguridad de capa 2 (“Layer 2”), debe establecer
las mismas opciones de administración para la interfaz VLAN1 que para la zona de seguridad de capa 2.
• Agregará una ruta en el enrutador virtual trust (todas las zonas de seguridad de capa 2 están en el dominio
de enrutamiento trust-vr) para permitir que el tráfico administrativo fluya entre el dispositivo NetScreen y
una estación de trabajo administrativa situada más allá de la subred inmediata del dispositivo NetScreen.
Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.
1.1.2.0/24 1.1.1.0/24
Subred Subred
Zona V1-Trust Zona V1-Untrust
Internet
Interfaz V1-Trust Interfaz V1-Untrust

ethernet1 ethernet3
0.0.0.0/0 0.0.0.0/0
Estación de trabajo Enrutador interno VLAN1
admin 1.1.2.5 1.1.1.251 1.1.1.1/24
1.1.2.250
5. De forma predeterminada, NetScreen habilita las opciones de administración para la interfaz VLAN1 y la zona de seguridad V1-Trust. En este ejemplo se
muestran estas opciones habilitadas sólo con fines ilustrativos. A menos que las haya inhabilitado previamente, realmente no es necesario habilitarlas
manualmente.

WebUI
1. Interfaz VLAN1
Network > Interfaces > Edit (para VLAN1): Introduzca los siguientes datos y haga clic en OK :
Management Services: WebUI, Telnet, SSH (seleccione)
2. Zona V1-Trust
Network > Zones > Edit (para V1-Trust): Seleccione los siguientes datos y haga clic en OK :
Management Services: WebUI, Telnet, SSH
Other Services: Ping
3. Ruta
Interface: vlan1(trust-vr)
Metric: 1

CLI
1. Interfaz VLAN1
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ssh
set interface vlan1 manage ping
2. Zona V1-Trust
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ssh
set zone v1-trust manage ping
3. Ruta
set vrouter trust-vr route 1.1.2.0/24 interface vlan1 gateway 1.1.1.251 metric 1
save

Ejemplo: Modo transparente

El ejemplo siguiente ilustra una configuración básica con una sola LAN protegida por un dispositivo NetScreen en
modo transparente. Las directivas permiten el tráfico saliente para todos los hosts de la zona V1-Trust, servicios
SMTP entrantes para el servidor de correo y servicios entrante FTP-GET para el servidor FTP.
Para aumentar la seguridad del tráfico administrativo, cambiará el número del puerto HTTP para la administración
de WebUI de 80 a 5555, y el número de puerto Telnet para la administración de CLI de 23 a 4646. Utilizará la
dirección IP de VLAN1 (1.1.1.1/24) para administrar el dispositivo NetScreen desde la zona de seguridad V1-Trust.
Definirá direcciones para los servidores FTP y de correo. También configurará una ruta predeterminada al
enrutador externo en 1.1.1.250, para que el dispositivo NetScreen le pueda enviar tráfico VPN saliente6. (La puerta
de enlace predeterminada en todos los hosts de la zona V1-Trust también será 1.1.1.250).
FTP_Server Mail_Server Enrutador externo

1.1.1.5 1.1.1.10 1.1.1.250
1.1.1.0/24
Espacio de direcciones
Internet
IP de VLAN1 Zona V1-Untrust
Zona V1-Trust 1.1.1.1/24
Interfaz V1-Trust Interfaz V1-Untrust

ethernet1 ethernet3
0.0.0.0/0 0.0.0.0/0
6. Para ver un ejemplo de configuración de un túnel VPN para un dispositivo NetScreen con las interfaces en modo transparente, consulte “VPN en modo
transparente” en la pàgina 5 -221.

WebUI
1. Interfaz VLAN1
Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes datos y haga clic en OK :
Management Services: WebUI, Telnet (seleccione)
2. Puerto HTTP
7
Configuration > Admin > Management: En el campo “HTTP Port”, escriba 5555 y haga clic en Apply .
3. Interfaces
Zone Name: V1-Trust
Zone Name: V1-Untrust
4. Zona V1-Trust
Network > Zones > Edit (para v1-trust): Seleccione los siguientes datos y haga clic en OK :
Management Services: WebUI, Telnet
Other Services: Ping
7. El número de puerto predeterminado es 80. Se recomienda cambiarlo a cualquier número entre 1024 y 32.767 para evitar cualquier acceso no autorizado
a la configuración. Cuando se conecte posteriormente para administrar el dispositivo, introduzca lo siguiente en el campo “URL” de su explorador web:
http://1.1.1.1:5555.

5. Direcciones
Address Name: FTP_Server
Zone: V1-Trust
Address Name: Mail_Server
Zone: V1-Trust
6. Ruta
Interface: vlan1(trust-vr)
Metric: 1

7. Directivas
Policies > (From: V1-Trust, To: V1-Untrust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: Any
Action: Permit
Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), Mail_Server
Service: Mail
Action: Permit
Policies > (From: V1-Untrust, To: V1-Trust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), FTP_Server
Service: FTP-GET
Action: Permit

CLI
1. VLAN1
set interface vlan1 ip 1.1.1.1/24
set interface vlan1 manage web
set interface vlan1 manage telnet
set interface vlan1 manage ping
2. Telnet
8
set admin telnet port 4646
3. Interfaces
set interface ethernet1 zone v1-trust
set interface ethernet3 zone v1-untrust
4. Zona V1-Trust
set zone v1-trust manage web
set zone v1-trust manage telnet
set zone v1-trust manage ping
5. Direcciones
set address v1-trust FTP_Server 1.1.1.5/32
set address v1-trust Mail_Server 1.1.1.10/32
6. Ruta
set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250 metric 1
7. Directivas
set policy from v1-trust to v1-untrust any any any permit
set policy from v1-untrust to v1-trust any Mail_Server mail permit
set policy from v1-untrust to v1-trust any FTP_Server ftp-get permit
save
8. El número de puerto predeterminado para Telnet es 23. Se recomienda cambiarlo a cualquier número entre 1024 y 32.767 para evitar cualquier acceso
no autorizado a la configuración. Cuando se conecte posteriormente para administrar el dispositivo a través de Telnet, introduzca la siguiente dirección:
1.1.1.1 4646.

Capítulo 4 Modos de las interfaces Modo NAT
MODO NAT
Cuando una interfaz de entrada está en el modo de traducción de direcciones de red (NAT), el dispositivo
NetScreen, actuando como conmutador (o enrutador) de capa 3, traduce dos componentes del encabezado de un
paquete IP saliente destinado a la zona Untrust: su dirección IP de origen y el número del puerto de origen. El
dispositivo NetScreen reemplaza la dirección IP de origen del host de origen con la dirección IP de la interfaz de la
zona Untrust. También reemplaza el número del puerto de origen con otro número de puerto generado
aleatoriamente por el dispositivo NetScreen.
10.1.1.15
10.1.1.10 10.1.1.20
10.1.1.5
10.1.1.25
Zona Trust
Interfaz de la
zona Trust
Espacio de 10.1.1.1/24
direcciones privado
Interfaz de la
zona Untrust
Espacio de Enrutador 1.1.1.1/24
direcciones público externo
Zona Untrust
Internet
Cuando el paquete de respuesta llega al dispositivo NetScreen, éste traduce dos componentes del encabezado IP
del paquete entrante: la dirección y el número de puerto del destino, que se traducen inversamente para obtener los
números originales. Seguidamente, el dispositivo NetScreen reenvía el paquete a su destino.

NAT agrega un nivel de seguridad no disponible con el modo transparente: Las direcciones de los hosts que envían
tráfico a través de una interfaz de entrada en modo NAT (como una interfaz de la zona Trust) nunca quedan
expuestas a los hosts de la zona de salida (como la zona Untrust), salvo que ambas zonas se encuentren en el
mismo dominio de enrutamiento virtual y el dispositivo NetScreen publique rutas a interlocutores mediante un
protocolo de enrutamiento dinámico (DRP). Incluso entonces, las direcciones de la zona Trust son solamente
accesibles si alguna directiva les permite recibir tráfico entrante. (Si desea mantener ocultas las direcciones de la
zona Trust mientras utilice un DRP, ponga la zona Untrust en untrust-vr y la zona Trust en trust-vr, y no exporte
rutas de direcciones internas de trust-vr a untrust-vr).
Si el dispositivo NetScreen utiliza el enrutamiento estático y sólo un enrutador virtual, las direcciones internas
siguen ocultas cuando el tráfico es saliente, debido a NAT basada en interfaces. Las directivas que configure
controlarán el tráfico entrante. Si solamente utiliza direcciones IP asignadas (MIP) y direcciones IP virtuales (VIP)
como destinos en sus directivas de tráfico entrante, las direcciones internas permanecerán ocultas.
Asimismo, NAT preserva el uso de direcciones IP públicas. En muchos entornos, no hay recursos disponibles para
proporcionar direcciones IP públicas para todos los dispositivos en la red. Los servicios NAT permiten que muchas
direcciones IP privadas tengan acceso a los recursos de Internet a través de una, o de unas pocas, direcciones IP
públicas. Los siguientes rangos de direcciones IP están reservados para redes IP privadas y no deben enrutarse
hacia Internet:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

Tráfico NAT entrante y saliente

Un host situado en una zona que envíe tráfico a través de una interfaz en modo NAT puede iniciar tráfico hacia la
zona Untrust (asumiendo que alguna directiva lo permita). En versiones anteriores a ScreenOS 5.0.0, un host
situado detrás de una interfaz en modo NAT no podía recibir tráfico de la zona Untrust a menos que se configurara
9
para él una dirección IP asignada (MIP), IP virtual (VIP) o un túnel VPN . Sin embargo, en ScreenOS 5.0.0, el tráfico
hacia una zona con una interfaz habilitada para NAT desde cualquier zona (incluyendo la zona Untrust) no necesita
utilizar una MIP, VIP o VPN. Si desea proteger la privacidad de las direcciones o si está utilizando direcciones
privadas inexistentes en una red pública como Internet, puede definir una MIP, VIP o VPN para que el tráfico pueda
alcanzarlas. Sin embargo, si los posibles problemas de privacidad y las direcciones IP privadas no son una cuestión
relevante, el tráfico procedente de la zona Untrust puede llegar directamente a los hosts que se encuentren detrás
de una interfaz en modo NAT, sin necesidad de utilizar una MIP, VIP ni VPN.
1. NAT basada en interfaces aplicada al tráfico de

la zona Trust a la zona Untrust.
Zona Untrust ethernet3
2. NAT basada en interfaces aplicada al tráfico de 1.1.1.1/24
la zona definida por el usuario a la zona Modo de ruta
Untrust.
MIP 1.1.1.10 – 10.1.1.10
(Nota: Esto sólo es posible si las zonas definida 1 2 MIP 1.1.1.20 – 10.1.2.20
por el usuario y Untrust se encuentran en
diferentes dominios de enrutamiento virtuales). NAT NAT
3. Sin NAT basada en interfaces aplicada al
tráfico entre las zonas Trust y definida por el
usuario.
ethernet1 Las ethernet2
4 y 5. Puede utilizar MIPs, VIPs o VPNs para que
el tráfico procedente de la zona Untrust alcance 10.1.1.1/24 MIPS son 10.1.2.1/24
la zona Trust o la zona definida por el usuario, Modo NAT 4 opcionales 5 Modo NAT
pero no se requieren.
6. Las MIPs y VPNs tampoco se requieren para Zona Trust 3 Sin NAT Zona
el tráfico entre las zonas Trust y definida por el Las MIPS 6 definida por el usuario
usuario. son
opcionales
Nota: Para obtener más información sobre MIPs, consulte “Direcciones IP asignadas” en la pàgina 7 -92. Para
obtener más información sobre VIPs, consulte “Direcciones IP virtuales” en la pàgina 7 -118.
9. Sólo se puede definir una dirección IP virtual (VIP) en una interfaz asociada a la zona Untrust.

Ajustes de interfaz
Para el modo NAT, defina los siguientes ajustes de interfaz, donde ip_addr1 y ip_addr2 representan los números de
una dirección IP, mask representa los números de una máscara de red, vlan_id_num representa el número de una
etiqueta VLAN, zone representa el nombre de una zona y number representa el tamaño del ancho de banda en
kbps:
Interfaces de zona Ajustes Subinterfaces de zona

Zonas Trust, DMZ y definidas por el usuario IP: ip_addr1 IP: ip_addr1
que utilizan NAT Netmask: mask Netmask: mask
*
Manage IP : ip_addr2 VLAN Tag: vlan_id_num
†
Traffic Bandwidth : number Zone Name: zone
‡ †
NAT : (seleccione) NAT : (seleccione)
Untrust** IP: ip_addr1 IP: ip_addr1
Netmask: mask Netmask: mask
Manage IP*: ip_addr2 VLAN Tag: vlan_id_num
Traffic Bandwidth†: number Zone Name: zone
*
Puede establecer una dirección IP de administración en cada interfaz. Su finalidad principal es proporcionar una dirección IP para
el tráfico administrativo separada del tráfico de red. También puede utilizar la dirección IP de administración para tener acceso a
un dispositivo específico cuando se encuentre en una configuración de alta disponibilidad.
†
Ajuste opcional para la asignación de tráfico.
‡
Al seleccionar NAT, el modo de interfaz se define como NAT. Al seleccionar Route, el modo de la interfaz es de ruta.
**
Aunque se puede seleccionar NAT como modo de interfaz en una interfaz asociada a la zona Untrust, el dispositivo NetScreen no
realizará ninguna operación NAT en esa interfaz.

Ejemplo: Modo NAT

El siguiente ejemplo ilustra una configuración simple de una LAN con una sola subred en la zona Trust. La LAN está
protegida por un dispositivo NetScreen en modo NAT. Las directivas permiten el tráfico saliente para todos los
hosts de la zona Trust y correo entrante para el servidor de correo. El correo entrante se enruta al servidor de
correo a través de una dirección IP virtual. Las dos zonas Trust y Untrust se encuentran en el dominio de
enrutamiento trust-vr.
Nota: Compare este ejemplo con el del modo de ruta en la page 137.
Enrutador externo
1.1.1.250
Mail Server Internet

VIP 1.1.1.5 ->
10.1.1.5 ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Zona Trust Modo NAT Modo de ruta Zona Untrust
WebUI
1. Interfaces
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply :
Zone Name: Trust
Introduzca los siguientes datos y haga clic en OK:

10
Interface Mode: NAT
10. De forma predeterminada, cualquier interfaz que se asocie a la zona Trust estará en modo NAT. Por lo tanto, esta opción ya está habilitada para las
interfaces asociadas a la zona Trust.

Zone Name: Untrust
IP Address/Netmask11: 1.1.1.1/24
Interface Mode: Route
12
2. VIP
Network > Interfaces > Edit (para ethernet3) > VIP: Introduzca los siguientes datos y haga clic en Add :
Virtual IP Address: 1.1.1.5
Network > Interfaces > Edit (para ethernet3) > VIP > New VIP Service: Introduzca los siguientes datos y
haga clic en OK :
Virtual Port: 25
Map to Service: Mail
Map to IP: 10.1.1.5
3. Ruta
11. Si la dirección IP de la zona Untrust del dispositivo NetScreen es asignada dinámicamente por un ISP, deje los campos de dirección IP y máscara de red
vacíos y seleccione Obtain IP using DHCP . Si el ISP utiliza el protocolo “Point-to-Point Protocol over Ethernet”, seleccione Obtain IP using PPPoE , haga
clic en el vínculo Create new PPPoE settings e introduzca su nombre y contraseña.
12. Para obtener más información sobre direcciones IP virtuales (VIP), consulte “Direcciones IP virtuales” en la pàgina 7 -118.

4. Directivas
Source Address:
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Global) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), VIP(1.1.1.5)
Service: MAIL
Action: Permit

CLI
1. Interfaces
13
set interface ethernet1 nat
14
set interface ethernet3 zone untrust
set interface ethernet3 route
2. VIP
set interface ethernet3 vip 1.1.1.5 25 mail 10.1.1.5
3. Ruta
4. Directivas
set policy from trust to untrust any any any permit
set policy from untrust to global any vip(1.1.1.5) mail permit
save
13. El comando set interface ethernetn nat determina si el dispositivo NetScreen está funcionando en modo NAT.
14. Si la dirección IP de la zona Untrust del dispositivo NetScreen es asignada dinámicamente por un ISP, utilice el comando siguiente: set interface untrust
dhcp . Si el ISP utiliza el protocolo “Point-to-Point Protocol over Ethernet”, utilice los comandos set pppoe y exec pppoe . Para obtener más información,
consulte el manual NetScreen CLI Reference Guide.

Capítulo 4 Modos de las interfaces Modo de ruta
MODO DE RUTA
Cuando una interfaz está en modo de ruta (“Route”), el dispositivo NetScreen enruta el tráfico entre diferentes
zonas sin ejecutar NAT de origen (NAT-src); es decir, la dirección de origen y el número de puerto en el
encabezado del paquete IP permanecen invariables mientras atraviesan el dispositivo NetScreen. A diferencia de
NAT-src, no es necesario establecer direcciones IP asignadas (MIP) e IP virtuales (VIP) para permitir que llegue
tráfico entrante a los hosts cuando la interfaz de la zona de destino está en modo de ruta. A diferencia del modo
transparente, las interfaces de cada zona se encuentran en subredes diferentes.
1.2.2.15
1.2.2.10 1.2.2.20
1.2.2.5
1.2.2.25
Zona Trust
Interfaz de la
zona Trust
Espacio de 1.2.2.1/24
direcciones público
Interfaz de la
Espacio de zona Untrust
direcciones público 1.1.1.1/24
Enrutador
externo
Zona Untrust
Internet
No es necesario aplicar la traducción de direcciones de red de origen (“NAT-src”) en el nivel de interfaz para que
todas las direcciones de origen que inician tráfico saliente sean traducidas a la dirección IP de la interfaz de la zona
de destino. En lugar de ello, puede aplicar NAT-src selectivamente a nivel de directivas. Puede determinar qué

tráfico enrutar y a qué tráfico aplicar NAT-src creando las directivas que habilitan NAT-src para las direcciones de
origen especificadas tanto en tráfico entrante como saliente. Para el tráfico de red, NAT puede utilizar la dirección
IP (o direcciones IP) de la interfaz de la zona de destino de un conjunto de IPs dinámicas (DIP), que se encuentra
en la misma subred que la interfaz de la zona de destino. Para el tráfico VPN, NAT puede utilizar la dirección IP de
una interfaz de túnel o una dirección de su conjunto de DIP asociado.
Nota: Para obtener más información sobre cómo configurar NAT-src basada en directivas, consulte “Traducción de
direcciones de red de origen” en la pàgina 7 -15.
Ajustes de interfaz
Para el modo de ruta, defina los siguientes ajustes de interfaz, donde ip_addr1 y p_addr2 representan los números
de una dirección IP, mask representa los números de una máscara de red, vlan_id_num representa el número de
una etiqueta VLAN, zone representa el nombre de una zona y number representa el tamaño del ancho de banda en
kbps:
Interfaces de zona Ajustes Subinterfaces de zona

Trust, Untrust, DMZ y zonas definidas por IP: ip_addr1 IP: ip_addr1
el usuario Netmask: máscara Netmask: máscara
Manage IP*: ip_addr2 VLAN Tag: vlan_id_num
Traffic Bandwidth†: number Zone Name: zone
Route‡: (seleccione) Route†: (seleccione)
*
Puede establecer una dirección IP de administración en cada interfaz. Su finalidad principal es proporcionar una dirección IP para
el tráfico administrativo separada del tráfico de red. También puede utilizar la dirección IP de administración para tener acceso a
un dispositivo específico cuando se encuentre en una configuración de alta disponibilidad.
†
Ajuste opcional para la asignación de tráfico.
‡
Al seleccionar Route, la interfaz queda definida en modo de ruta. Al seleccionar NAT, el modo de la interfaz queda definido
como NAT.

Ejemplo: Modo de ruta

En el ejemplo anterior, “Ejemplo: Modo NAT” en la pàgina 131, los hosts en la LAN de la zona Trust tienen
direcciones IP privadas y una dirección IP asignada para el servidor de correo. En el ejemplo siguiente, la misma
red está protegida por un dispositivo NetScreen que funciona en modo de ruta; observe que los hosts tienen
direcciones IP públicas y que no se requiere una MIP para el servidor de correo. Ambas zonas de seguridad se
encuentran en el dominio de enrutamiento trust-vr.
Enrutador externo
1.1.1.250
Mail Server
1.2.2.5 Internet
ethernet1 ethernet3
1.2.2.1/24 1.1.1.1/24
Zona Trust Modo de ruta Modo de ruta Zona Untrust
WebUI
1. Interfaces
Zone Name: Trust
Introduzca los siguientes datos y haga clic en OK :

Interface Mode: Route15
15. Seleccionando Route se determina que el dispositivo NetScreen funcione en el modo de ruta, sin aplicar NAT al tráfico entrante o saliente de la zona Trust.

Zone Name: Untrust
IP Address/Netmask16: 1.1.1.1/24
2. Dirección
Address Name: Mail Server
Zone: Trust
3. Ruta
16. Si la dirección IP de la zona Untrust del dispositivo NetScreen es asignada dinámicamente por un ISP, deje los campos de dirección IP y máscara de red
vacíos y seleccione Obtain IP using DHCP . Si el ISP utiliza el protocolo “Point-to-Point Protocol over Ethernet”, seleccione Obtain IP using PPPoE , haga
clic en el vínculo Create new PPPoE settings e introduzca su nombre y contraseña.

4. Directivas
Source Address:
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), Mail Server
Service: MAIL
Action: Permit

CLI
1. Interfaces
17

2. Dirección
set address trust mail_server 1.2.2.5/24
3. Ruta
4. Directivas
set policy from untrust to trust any mail_server mail permit
save
17. El comando set interface ethernet number route establece que el dispositivo NetScreen funcione en modo de ruta.

Capítulo 5
Bloques para la construcción de directivas

5
Este capítulo explica los componentes, o bloques de construcción, a los que puede hacerse referencia en las
directivas. Los temas tratados son:
• “Direcciones” en la pàgina 143
– “Entradas de direcciones” en la pàgina 144
– “Grupos de direcciones” en la pàgina 146
• “Servicios” en la pàgina 151
– “Servicios predefinidos” en la pàgina 151
– “Servicios personalizados” en la pàgina 153
– “Tiempos de espera de servicios” en la pàgina 156
– “Servicios ICMP” en la pàgina 158
– “RSH ALG” en la pàgina 160
– “Sun Remote Procedure Call Application Layer Gateway” en la pàgina 160
– “Microsoft Remote Procedure Call Application Layer Gateway” en la pàgina 163
– “Real Time Streaming Protocol Application Layer Gateway” en la pàgina 169
– “Protocolo H.323 para “Voice-over-IP”” en la pàgina 181
– “Protocolo de inicio de sesión (“Session Initiation Protocol” o “SIP”)” en la pàgina 200
– “SIP con traducción de direcciones de red (NAT)” en la pàgina 215
– “Administración del ancho de banda para servicios de VoIP” en la pàgina 271
– “Grupos de servicios” en la pàgina 274

Capítulo 5 Bloques para la construcción de directivas
• “Conjuntos de DIP” en la pàgina 278

– “Direcciones DIP “sticky”” en la pàgina 281
– “Interfaz extendida y DIP” en la pàgina 282
– “Interfaz de bucle invertido ("loopback") y DIP” en la pàgina 291
– “Grupos de DIP” en la pàgina 297
• “Tareas programadas” en la pàgina 301
Nota: Para obtener más información sobre la autenticación de usuarios, consulte el Volumen 8,
“Autenticación de usuarios”.

Capítulo 5 Bloques para la construcción de directivas Direcciones
DIRECCIONES
NetScreen ScreenOS clasifica las direcciones de todos los demás dispositivos según su ubicación y máscara de
red. Cada zona posee su propia lista de direcciones y sus grupos de direcciones.
Los hosts individuales solamente tienen definida una dirección IP, por lo que su máscara de red debe tener el valor
255.255.255.255 (que enmascara todos los hosts salvo el propio).
Las subredes tienen una dirección IP y una máscara de red (por ejemplo, 255.255.255.0 o 255.255.0.0).
Para poder configurar directivas que permitan, rechacen o canalicen el tráfico a través de un túnel desde y hacia
determinados hosts y subredes, es necesario crear las correspondientes entradas en las listas de direcciones de
NetScreen, que están organizadas por zonas.
Nota: Para “Any” no es necesario crear entradas de direcciones. Este término se aplica automáticamente a todos
los dispositivos situados físicamente dentro de sus zonas respectivas.

Entradas de direcciones
Para poder establecer muchas de las opciones de configuración del cortafuegos de NetScreen, de VPN y de
asignación del tráfico, es necesario definir direcciones en unas o varias listas de direcciones. La lista de direcciones
1
de una zona de seguridad contiene las direcciones IP o nombres de dominios de los hosts o subredes cuyo tráfico
está permitido, bloqueado, encriptado o autenticado por el usuario.
Nota: Para obtener más información sobre las convenciones de nomenclatura de ScreenOS (aplicables a los
nombres creados para las direcciones), consulte “Convenciones de nomenclatura y conjuntos de caracteres” en la
pàgina xiv.
Ejemplo: Agregar direcciones

En este ejemplo agregará la subred “Sunnyvale_Eng” con la dirección IP 10.1.10.0/24 como dirección en la zona
Trust, y la dirección “www.juniper.net” como dirección en la zona Untrust.
WebUI
Objects > Addresses > List > New: Introduzca la siguiente información y haga clic en OK :
Address Name: Sunnyvale_Eng
Zone: Trust
Objects > Addresses > List > New: Introduzca la siguiente información y haga clic en OK :
Address Name: Juniper
Domain Name: (seleccione), www.juniper.net
Zone: Untrust
1. Para poder utilizar nombres de dominios para las entradas de direcciones, es necesario configurar el dispositivo NetScreen para los servicios del sistema
de nombres de dominios (“Domain Name System” o “DNS”). Para obtener más información sobre la configuración de DNS, consulte “Compatibilidad con
DNS (sistema de nombres de dominio)” en la pàgina 377.

CLI
set address trust Sunnyvale_Eng 10.1.10.0/24
set address untrust Juniper www.juniper.net
save
Ejemplo: Modificar direcciones

En este ejemplo cambiará la entrada de la dirección “Sunnyvale_Eng” para reflejar que este departamento está
dedicado específicamente a la ingeniería de software y tiene otra dirección IP (10.1.40.0/24).
WebUI
Objects > Addresses > List > Edit (para Sunnyvale_Eng): Cambie el nombre y la dirección IP por los
siguientes datos y haga clic en OK :
Address Name: Sunnyvale_SW_Eng
Zone: Trust
CLI
unset address trust Sunnyvale_Eng
set address trust Sunnyvale_SW_Eng 10.1.40.0/24
save
Nota: Después de definir una dirección, o un grupo de direcciones, y asociarla a una directiva, no podrá cambiar la
ubicación de la dirección a otra zona (como de Trust a Untrust). Para cambiar su ubicación, primero debe
desvincularla de la directiva subyacente.

Ejemplo: Eliminar direcciones

En este ejemplo eliminará la entrada de la dirección “Sunnyvale_SW_Eng”.
WebUI
Objects > Addresses > List: Haga clic en Remove en la columna “Configure” para “Sunnyvale_SW_Eng”.
CLI
unset address trust “Sunnyvale_SW_Eng”
save
Grupos de direcciones
En la sección anterior se explica cómo crear, modificar y eliminar las entradas en la libreta de direcciones
correspondientes a los diferentes hosts y subredes. Según se vayan agregando direcciones a una lista de
direcciones, se hará más difícil controlar cómo las directivas afectan a cada entrada de dirección. NetScreen
permite crear grupos de direcciones. En lugar de administrar un gran número de entradas de direcciones, puede
administrar un pequeño número de grupos. Los cambios que efectúe al grupo se aplicarán a todas las entradas de
direcciones que lo componen.
1 directiva por dirección 1 directiva por grupo de direcciones

La opción de grupo de direcciones tiene las siguientes características:

• Puede crear grupos de direcciones en cualquier zona.
• Puede crear grupos de direcciones con los usuarios existentes, o bien crear grupos de direcciones vacíos
e introducir posteriormente los usuarios.
2
• Un grupo de direcciones puede ser miembro de otro grupo de direcciones .
• En una directiva se puede hacer referencia a una entrada de grupo de direcciones igual que a una entrada
individual en la libreta de direcciones.
• NetScreen aplica las directivas a cada miembro del grupo creando internamente directivas individuales
para cada miembro del grupo. Aunque usted solamente tiene que crear una directiva para un grupo, en
realidad NetScreen crea una directiva interna para cada miembro del grupo (así como para cada servicio
configurado para cada usuario).3
• Cuando se elimina una entrada individual en la libreta de direcciones, el dispositivo NetScreen la elimina
automáticamente de todos los grupos a los que perteneció.
Los grupos de direcciones tienen las siguientes limitaciones:
• Los grupos de direcciones solamente pueden contener direcciones que pertenezcan a la misma zona.
• Los nombres de direcciones no pueden coincidir con nombres de grupos. Si se utiliza el nombre “Paris”
para una entrada de dirección individual, no se puede utilizar para un nombre de grupo.
• No se pueden eliminar los grupos a los que se haga referencia en directivas. No obstante, estos grupos
pueden ser editados.
• Cuando se asigna una directiva individual a un grupo de direcciones, se aplica de forma individual a cada
miembro del grupo, y el dispositivo NetScreen genera una entrada por cada miembro en la lista de control
de accesos (ACL). Si el usuario no está atento, se puede exceder el número de recursos de directivas
disponibles, especialmente si tanto la dirección de origen como la de destino son grupos de direcciones y el
servicio especificado es un grupo de servicios.
• No se pueden agregar las direcciones predefinidas: “Any”, “All Virtual IPs” ni “Dial-Up VPN” a grupos.
2. Para asegurarse de que un grupo no esté “autocontenido” accidentalmente como miembro en su propio grupo, el dispositivo NetScreen realiza una
comprobación de coherencia cada vez que se incluye un grupo en otro. Por ejemplo, si agrega el grupo A como miembro al grupo B, el dispositivo NetScreen
se asegura automáticamente de que A no contenga ya a B como miembro.
3. La forma automática en la que el dispositivo NetScreen aplica directivas a cada miembro del grupo de direcciones ahorra al usuario tener que crearlas una
por una para cada dirección. NetScreen incluso escribe estas directivas en ASIC, lo cual acelera considerablemente la ejecución de las consultas.

Ejemplo: Crear un grupo de direcciones

En el ejemplo siguiente creará un grupo denominado “HQ 2nd Floor” que contendrá las dos direcciones “Santa
Clara Eng” y “Tech Pubs”, que ya habrá introducido en la libreta de direcciones para la zona Trust.
WebUI
Objects > Addresses > Groups > (para la zona: Trust) New: Introduzca el siguiente nombre de grupo,
mueva las siguientes direcciones y haga clic en OK :
Group Name: HQ 2nd Floor
Seleccione Santa Clara Eng y utilice el botón << para trasladar la dirección
de la columna “Available Members” a la columna “Group Members”.
Seleccione Tech Pubs y utilice el botón << para trasladar la dirección de la
CLI
set group address trust “HQ 2nd Floor” add “Santa Clara Eng”
set group address trust “HQ 2nd Floor” add “Tech Pubs”
save

Ejemplo: Editar una entrada de grupo de direcciones

En este ejemplo agregará “Support” (una dirección que ya habrá introducido en la libreta de direcciones) al grupo de
direcciones “HQ 2nd Floor”.
WebUI
Objects > Addresses > Groups > (para la zona: Trust) Edit (para “HQ 2nd Floor”): Mueva la siguiente
dirección y haga clic en OK :
Seleccione Support y utilice el botón << para trasladar la dirección de la
CLI
set group address trust “HQ 2nd Floor” add Support
save

Ejemplo: Eliminar un miembro y un grupo

En este ejemplo eliminará el miembro “Support” del grupo de direcciones “HQ 2nd Floor” y eliminará “Sales”, un
grupo de direcciones que previamente habrá creado.
WebUI
Objects > Addresses > Groups > (para la zona: Trust) Edit (“HQ 2nd Floor”): Mueva la siguiente dirección y
haga clic en OK :
Seleccione support y utilice el botón >> para trasladar la dirección de la
columna “Group Members” a la columna “Available Members”.
Objects > Addresses > Groups > (para la zona: Trust): Haga clic en Remove en la columna “Configure”
para “Sales”.
CLI
unset group address trust “HQ 2nd Floor” remove Support
unset group address trust Sales
save
Nota: El dispositivo NetScreen no elimina automáticamente un grupo del que se hayan eliminado todos los
nombres.

Capítulo 5 Bloques para la construcción de directivas Servicios
SERVICIOS
Los servicios son tipos de tráfico para los que existen estándares de protocolos. Cada servicio tiene asociados un
protocolo de transporte y uno o varios números de puertos de destino, como el puerto TCP nº 21 para FTP y el
puerto TCP nº 23 para Telnet. Al crear una directiva se debe especificar un servicio para ella. Puede seleccionar
uno de los servicios predefinidos del libro de servicios, o bien un servicio personalizado o grupo de servicios que
haya creado. Para consultar qué servicio puede utilizar en una directiva, visualice la lista desplegable Service de la
página “Policy Configuration” (WebUI) o ejecute el comando get service (CLI).
Servicios predefinidos
ScreenOS es compatible con un gran número de servicios predefinidos. Más adelante en esta sección encontrará
información más detallada sobre algunos, a saber:
• “Servicios ICMP” en la pàgina 158
• “RSH ALG” en la pàgina 160
• “Sun Remote Procedure Call Application Layer Gateway” en la pàgina 160
• “Microsoft Remote Procedure Call Application Layer Gateway” en la pàgina 163
• “Real Time Streaming Protocol Application Layer Gateway” en la pàgina 169
• “Protocolo H.323 para “Voice-over-IP”” en la pàgina 181
• “Protocolo de inicio de sesión (“Session Initiation Protocol” o “SIP”)” en la pàgina 200
Puede visualizar la lista de servicios predefinidos o personalizados, o bien los grupos de servicios en el dispositivo
NetScreen mediante WebUI o CLI.
Mediante WebUI:
Objects > Services > Predefined
Objects > Services > Custom
Objects > Services > Groups

Mediante CLI:
get service [ group | predefined | user ]
La respuesta del comando CLI get service pre-defined es similar a ésta:
Name Proto Port Group Time out (min) Flag

ANY 0 0/65535 other 1 Pre-defined
AOL 6 5190/5194 remote 30 Pre-defined
BGP 6 179 other 30 Pre-defined
DHCP-Relay 17 67 info seeking 1 Pre-defined
DNS 17 53 info seeking 1 Pre-defined
FINGER 6 79 info seeking 30 Pre-defined
FTP 6 21 remote 30 Pre-defined
FTP-Get 6 21 remote 30 Pre-defined
FTP-Put 6 21 remote 30 Pre-defined
GOPHER 6 70 info seeking 30 Pre-defined
H.323 6 1720 remote 2160 Pre-defined
--- more ---
Nota: Cada servicio predefinido tiene un rango de puertos de origen entre 1 y 65535, que abarca todo el conjunto
de números de puerto válidos. Esto evita que posibles atacantes obtengan acceso a través de un puerto de origen
que se encuentre fuera del rango. Si necesita utilizar un rango de puertos de origen distinto para cualquier servicio
predefinido, cree un servicio personalizado. Para obtener más información, consulte “Servicios personalizados” en
la pàgina 153.

Servicios personalizados
En lugar de utilizar servicios predefinidos, puede crear fácilmente servicios personalizados. Puede asignar a cada
servicio personalizado los atributos siguientes:
• Nombre
• Protocolo de transporte
• Números de los puertos de origen y de destino para los servicios que utilizan TCP o UDP
• Valores de tipos y códigos para los servicios que utilizan ICMP
• Valor del tiempo de espera
Si crea un servicio personalizado en un sistema virtual (vsys) que tiene el mismo nombre que un servicio
personalizado previamente definido en el sistema raíz, el servicio en el vsys asume el tiempo de espera
predeterminado para el protocolo de transporte especificado (TCP, UDP o ICMP). Para definir el tiempo de espera
personalizado para un servicio en un vsys distinto del predeterminado cuando un servicio personalizado con el
mismo nombre en el sistema raíz ya disponga de su propio tiempo de espera, cree el servicio personalizado en el
vsys y en el sistema raíz en el orden siguiente:
1. Primero, cree un servicio personalizado con un tiempo de espera personalizado en vsys.
2. A continuación, cree otro servicio personalizado con el mismo nombre pero con otro tiempo de espera en el
sistema raíz.
Los ejemplos siguientes describen cómo agregar, modificar y eliminar un servicio personalizado.
nombres creados para los servicios personalizados), consulte “Convenciones de nomenclatura y conjuntos de
caracteres” en la pàgina xiv.

Ejemplo: Agregar un servicio personalizado

Para agregar un servicio personalizado al libro de servicios se necesita la información siguiente:
• Un nombre para el servicio, en este ejemplo “cust-telnet”
• Un rango de números de puertos de origen: 1 – 65535
• Un rango de números de puertos de destino para recibir la petición del servicio, por ejemplo: 23000 –
23000.
• Si el servicio utiliza el protocolo TCP o UDP u otro protocolo compatible con las especificaciones de
Internet. En este ejemplo, el protocolo es TCP.
WebUI
Objects > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK :
Service Name: cust-telnet
Service Timeout: Custom (seleccione), 30 (escriba)
Transport Protocol: TCP (seleccione)
Source Port Low: 1
Source Port High: 65535
Destination Port Low: 23000
Destination Port High: 23000
CLI
set service cust-telnet protocol tcp src-port 1-65535 dst-port 23000-23000
4
set service cust-telnet timeout 30
save
4. El valor del tiempo de espera se expresa en minutos. Si no se establece expresamente, el valor del tiempo de espera de un servicio personalizado es de
180 minutos. Si no desea que un servicio caduque al cumplirse su tiempo de espera, introduzca never .

Ejemplo: Modificar un servicio personalizado

En este ejemplo modificará el servicio personalizado “cust-telnet” cambiando el rango de puertos de destino a
23230-23230.
Utilice el comando set service service_name clear para eliminar la definición de un servicio personalizado sin
eliminar el servicio del libro de servicios:
WebUI
Objects > Services > Custom > Edit (para cust-telnet): Introduzca los siguientes datos y haga clic en OK :
Destination Port Low: 23230
Destination Port High: 23230
CLI
set service cust-telnet clear
set service cust-telnet + tcp src-port 1-65535 dst-port 23230-23230
save
Ejemplo: Eliminar un servicio personalizado

En este ejemplo eliminará el servicio personalizado “cust-telnet”.
WebUI
Objects > Services > Custom: Haga clic en Remove en la columna “Configure” para “cust-telnet”.
CLI
unset service cust-telnet
save

Tiempos de espera de servicios

Para los servicios predefinidos o personalizados se puede establecer un umbral de tiempo de espera (en minutos).
Se puede utilizar el tiempo de espera predeterminado del servicio, especificar un tiempo de espera personalizado o
no utilizar ningún tiempo de espera.
Algunos detalles sobre el comportamiento de los tiempos de espera de servicios:
• Cuando una directiva se refiere a un solo servicio personalizado o predefinido con un tiempo de espera
personalizado, el dispositivo NetScreen aplica ese tiempo de espera.
• Cuando una directiva se refiere a un grupo de servicios, a múltiples servicios o al servicio predefinido ANY,
el dispositivo NetScreen aplica el tiempo de espera correspondiente al último servicio configurado que
coincida con el protocolo (TCP o UDP) + el número del puerto de destino. Por ejemplo, si define los dos
servicios siguientes en el orden siguiente,
set service ftp-1 protocol tcp src 0-65535 dst 2121-2121 timeout 20
set service telnet-1 protocol tcp src 0-65535 dst 2100-2148 timeout 15
y luego hace referencia a ftp-1 junto con otros servicios en la misma directiva, el dispositivo NetScreen
aplica el tiempo de espera de 15 minutos definido para telnet-1 en lugar del tiempo de espera de 20
minutos para ftp-1. Esto sucede porque el dispositivo NetScreen almacena los tiempos de espera de los
servicios que utilizan los protocolos TCP y UDP en tablas, una para TCP y otra para UDP. Cuando el
dispositivo NetScreen consulta el tiempo de espera para un servicio mencionado en un grupo de servicios,
para una directiva con servicios múltiples o para el servicio comodín ANY, aplica el tiempo de espera del
primer servicio que encuentra en la tabla; si hubiera múltiples servicios con números de puertos de destino
coincidentes, se utilizará el último servicio configurado e inscrito en la tabla. En el ejemplo antedicho, el
dispositivo NetScreen aplica el tiempo de espera de 15 minutos porque los números de puertos de destino
para telnet-1 (2100-2148) se solapan con los de ftp-1 (2121) y telnet-1 fue definido después de ftp-1. Por lo
tanto, la búsqueda de un servicio con el puerto de destino 2121 descubre primero el tiempo de espera para
telnet-1 y lo aplica.
Para evitar la aplicación no intencionada de un tiempo de espera distinto a un servicio, evite utilizar
servicios con números de puertos de destino coincidentes o aplique el servicio definido primero en una
directiva independiente.

• Para servicios que utilizan ICMP o cualquier protocolo distinto de TCP y UDP, el dispositivo NetScreen
aplicará el tiempo de espera personalizado siempre que una directiva se refiera exclusivamente a ese
servicio. Cuando una directiva haga referencia a varios servicios, el dispositivo NetScreen aplicará el
tiempo de espera predeterminado (1 minuto) para los servicios que utilicen protocolos distintos de TCP y
UDP.
• Cuando una directiva en un sistema virtual (vsys) se refiere a un servicio personalizado y ya hay un servicio
definido con el mismo protocolo + número de puerto de destino en el sistema raíz, el dispositivo NetScreen
aplica al servicio en el nivel vsys el tiempo de espera correspondiente al servicio definido en el nivel raíz.
• No se puede definir explícitamente un tiempo de espera personalizado para un servicio personalizado
creado en el nivel vsys. Sin embargo, se puede aplicar indirectamente un tiempo de espera personalizado
en el nivel vsys creando un servicio personalizado en vsys y aplicando luego el tiempo de espera
personalizado deseado a un servicio con el mismo protocolo + número de puerto en el nivel raíz. Para ello,
siga estos pasos en el orden siguiente:
1. Cree un servicio personalizado en vsys.
2. A continuación, en el sistema raíz, cree otro servicio personalizado con el mismo protocolo y los mismos
números de puertos de destino, y con el tiempo de espera que desee aplicar en el nivel vsys.
Ejemplo: Establecer el tiempo de espera de un servicio

En este ejemplo cambiará el umbral del tiempo de espera del servicio predefinido BGP a 75 minutos:
WebUI
Objects > Services > Predefined > Edit (BGP): Introduzca los siguientes datos y haga clic en OK :
CLI
set service BGP timeout 75
save

Servicios ICMP
ScreenOS es compatible con el protocolo de mensajes de control de Internet (“Internet Control Message Protocol” o
“ICMP”) y admite diversos mensajes ICMP, como los servicios predefinidos o personalizados. Al configurar un
servicio ICMP personalizado, deberá definir su tipo y código5. Existen diversos tipos de mensajes ICMP. Por
ejemplo:
tipo 0 = mensaje de petición de eco (“Echo Request”)
tipo 3 = mensaje de destino inalcanzable (“Destination Unreachable”)
Los tipos de mensajes ICMP también pueden tener un código de mensaje. El código proporciona información más
específica sobre el mensaje. Por ejemplo:
Tipo de mensaje Código de mensaje

5 = Reenviar (“Redirect”) 0 = Reenvía el datagrama de la red (o subred)
1 = Reenvía el datagrama del host
2 = Reenvía el datagrama del tipo de servicio y red
3 = Reenvía el datagrama del tipo de servicio y host
11 = Códigos de tiempo 0 = Tiempo de vida excedido en tránsito (“Time to Live exceeded in

excedido (“Time Exceeded”) Transit”)
1 = Tiempo de reensamblaje de fragmentos excedido (“Fragment
Reassembly Time Exceeded”)
ScreenOS admite cualquier tipo o código dentro del rango 0-255.
5. Para obtener más información sobre los tipos y códigos de ICMP, consulte RFC 792, “Internet Control Message Protocol”.

Ejemplo: Definir un servicio ICMP

En este ejemplo definirá un servicio personalizado denominado “host-unreachable” que utilizará ICMP como
protocolo de transporte. El tipo es 3 (correspondiente a “Destination Unreachable”) y el código es 1 (“Host
Unreachable”). Establecerá el valor del tiempo de espera en 2 minutos.
WebUI
Objects > Services > Custom: Introduzca los siguientes datos y haga clic en OK :
Service Name: host-unreachable
Transport Protocol: ICMP (seleccione)
ICMP Type: 3
ICMP Code: 1
CLI
set service host-unreachable protocol icmp type 5 code 0
set service host-unreachable timeout 2
save

RSH ALG
RSH ALG (puerta de enlace “Remote Shell” en la capa de aplicación) permite a los usuarios autenticados ejecutar
comandos shell en hosts remotos. Los dispositivos NetScreen admiten el servicio RSH en los modos Transparent
(L2), Route (L3) y NAT, pero los dispositivos no admiten la traducción de puertos en el tráfico RSH.
Sun Remote Procedure Call Application Layer Gateway

Sun RPC, también conocido como Open Network Computing (ONC) RPC, permite que un programa que se esté
ejecutando en un equipo pueda ejecutar procedimientos de un programa que se está ejecutando en otro equipo.
Debido al gran número de servicios RPC y a la necesidad de realizar difusiones “broadcast”, la dirección de
transporte de un servicio RPC se negocia dinámicamente basándose en el número de programa y número de
versión del servicio. Hay definidos varios protocolos para asignar el número de programa y el número de versión de
RPC a una dirección de transporte.
Los dispositivos NetScreen admiten Sun RPC como servicio predefinido, permitiendo y denegando el tráfico
basándose en una directiva que usted configure. La puerta de enlace de la capa de aplicación (“application layer
gateway” o “ALG”) proporciona la funcionalidad necesaria para que los dispositivos NetScreen puedan manejar el
mecanismo dinámico de negociación de direcciones de transporte de Sun RPC y para asegurar el cumplimiento de
las directivas de cortafuegos basadas en el número de programa. Se puede definir una directiva de cortafuegos
para permitir o denegar todas las peticiones RPC, o bien para permitir o denegar determinados números de
programa. ALG también admite el modo Route y NAT para las peticiones entrantes y salientes.
Situaciones típicas de llamadas RPC

Cuando un cliente llama a un servicio remoto, necesita encontrar la dirección de transporte del servicio, que en el
caso de TCP/UDP es un número de puerto. Un procedimiento típico para este caso es el siguiente:
1. El cliente envía el mensaje GETPORT al servicio RPCBIND del equipo remoto. El mensaje GETPORT
contiene los números de programa, versión y procedimiento del servicio remoto que desea ejecutar.
2. El servicio RPCBIND responde con un número de puerto.
3. El cliente llama al servicio remoto usando el número de puerto devuelto.
4. El servicio remoto responde al cliente.

Un cliente también puede utilizar el mensaje CALLIT para llamar al servicio remoto directamente sin conocer el
número de puerto del servicio. En este caso, el procedimiento es el siguiente:
1. El cliente envía el mensaje CALLIT al servicio RPCBIND del equipo remoto. El mensaje CALLIT contiene
los números de programa, versión y procedimiento del servicio remoto que desea ejecutar.
2. RPCBIND llama al servicio para el cliente.
3. RCPBIND responde al cliente si la llamada se ha realizado con éxito. La respuesta contiene el resultado de
la llamada y el número de puerto del servicio.
Servicios Sun RPC

La tabla siguiente enumera los servicios Sun RPC predefinidos.
Nombre Número del Descripción

programa
SUN-RPC-PORTMAPPER 100000 El protocolo de asignación de puertos Sun RPC Portmapper Protocol
es un servicio basado en puertos TCP/UDP, incluyendo el puerto
TCP/UDP nº 111. Todos los demás servicios de esta tabla están
basados en el número del programa.
SUN-RPC-ANY N/D Cualquier servicio Sun RPC
SUN-RPC-MOUNTD 100005 Demonio de montaje Sun RPC Mount Daemon
SUN-RPC-NFS 100003 Sistema de archivos en red Sun RPC Network File System
100227
SUN-RPC-NLOCKMGR 100021 Administrador de bloqueos de red Sun RPC Network Lock Manager
SUN-RPC-RQUOTAD 100011 Demonio de cuotas remotas Sun RPC Remote Quota Daemon
SUN-RPC-RSTATD 100001 Demonio de estado remoto Sun RPC Remote Status Daemon
SUN-RPC-RUSERD 100002 Demonio de usuarios remotos Sun RPC Remote User Daemon
SUN-RPC-SADMIND 100232 Demonio de administración del sistema Sun RPC System
Administration Daemon
SUN-RPC-SPRAYD 100012 Demonio Sun RPC SPRAY Daemon

Nombre Número del Descripción

programa
SUN-RPC-STATUS 100024 Sun RPC STATUS
SUN-RPC-WALLD 100008 Demonio Sun RPC WALL Daemon
SUN-RPC-YPBIND 100007 Servicio de asignación de página amarilla Sun RPC Yellow Page
Bind Service
Ejemplo: Servicios Sun RPC

Dado que los servicios Sun RPC utilizan puertos negociados dinámicamente, no se pueden utilizar objetos de
servicios convencionales basándose en puertos TCP/UDP fijos para autorizarlos en la directiva de seguridad. Para
ello es necesario crear objetos “sun rpc service” utilizando números de programa. Por ejemplo, NFS utiliza dos
números de programa: 100003 y 100227. Los puertos TCP/UDP correspondientes son dinámicos. Para permitir los
números de programa, cree un objeto de servicio sun-rpc-nfs que contenga estos dos números. El ALG asignará
los números de programa a puertos TCP/UDP negociados dinámicamente y permitirá o denegará el servicio
basándose en una directiva que usted configure.
En este ejemplo, creará un objeto de servicio denominado my-sunrpc-nfs para utilizar Sun RPC Network File
System, identificado por dos identificadores de programa: 100003 y 100227.
WebUI
Objects > Services > Sun RPC Services > New: Introduzca los siguientes datos y haga clic en Apply :
Service Name: my-sunrpc-nfs
Service Timeout: (seleccione)
Program ID Low: 100003
Program ID High: 100003
Program ID Low: 100227
Program ID High: 100227

CLI
set service my-sunrpc-nfs protocol sun-rpc program 100003-100003
set service my-sunrpc-nfs + sun-rpc program 100227-100227
save
Microsoft Remote Procedure Call Application Layer Gateway

MS RPC es la implementación de Microsoft del RPC del entorno de computación distribuida (“Distributed
Computing Environment” o DCE). Como Sun RPC (consulte “Sun Remote Procedure Call Application Layer
Gateway” en la pàgina 160), MS RPC permite que un programa que se está ejecutando en un equipo pueda
ejecutar procedimientos de un programa que se está ejecutando en otro equipo. Debido al gran número de
servicios RPC y a la necesidad de realizar difusiones “broadcast”, la dirección de transporte de un servicio RPC se
negocia dinámicamente basándose en el identificador universal único (“Universal Unique IDentifier” o “UUID”). En
ScreenOS, el protocolo de asignación Endpoint Mapper está definido para asignar el UUID específico a una
dirección de transporte.
Los dispositivos NetScreen admiten MS RPC como servicio predefinido, permitiendo y denegando el tráfico
basándose en una directiva que usted configure. ALG proporciona la funcionalidad necesaria para que los
dispositivos NetScreen puedan manejar el mecanismo de negociación dinámica de direcciones de transporte de
MS RPC y garantizar el cumplimiento de las directivas de cortafuegos basadas en UUID. Se puede definir una
directiva de cortafuegos para permitir o denegar todas las peticiones RPC, o bien para permitir o denegar
determinados números de UUID. ALG también admite el modo Route y NAT para las peticiones entrantes y
salientes.

Servicios de MS RPC
La tabla siguiente enumera los servicios MS RPC predefinidos.
Nombre UUID Descripción

MS-RPC-EPM e1af8308-5d1f-11c9-91a4-08002b14a0fa Protocolo Remote Procedure Call
(RPC) Endpoint Mapper (EPM) de
Microsoft, un servicio basado en
puertos TCP/UDP, incluyendo el puerto
TCP/UDP nº 135. Todos los demás
servicios de esta tabla están basados
en UUID.
MS-RPC-ANY N/D Cualesquiera servicios Remote
Procedure Call (RPC) de Microsoft
MS-AD-BR ecec0d70-a603-11d0-96b1-00a0c91ece30 Servicios de copia de seguridad y
16e0cf3a-a604-11d0-96b1-00a0c91ece30 restauración de Active Directory de
Microsoft
MS-AD-DRSUAPI e3514235-4b06-11d1-ab04-00c04fc2dcd2 Servicio de replicación de Active
Directory de Microsoft
MS-AD-DSROLE 1cbcad78-df0b-4934-b558-87839ea501c9 Servicio DSROLE de Active Directory
de Microsoft
MS-AD-DSSETUP 3919286a-b10c-11d0-9ba8-00c04fd92ef5 Servicio de configuración de Active
Directory de Microsoft
MS-DTC 906b0ce0-c70b-1067-b317-00dd010662da Servicio distribuido de coordinación de
transacciones Distributed Transaction
Coordinator de Microsoft
MS-EXCHANGE-DATABASE 1a190310-bb9c-11cd-90f8-00aa00466520 Servicio de base de datos de Microsoft
Exchange
MS-EXCHANGE-DIRECTORY f5cc5a18-4264-101a-8c59-08002b2f8426 Servicio de directorios de Microsoft
f5cc5a7c-4264-101a-8c59-08002b2f8426 Exchange
f5cc59b4-4264-101a-8c59-08002b2f8426


MS-EXCHANGE-INFO-STORE 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde Servicio de almacenamiento de
1453c42c-0fa6-11d2-a910-00c04f990f3b información Microsoft Exchange
10f24e8e-0fa6-11d2-a910-00c04f990f3b Information Store
1544f5e0-613c-11d1-93df-00c04fd7bd09
MS-EXCHANGE-MTA 9e8ee830-4459-11ce-979b-00aa005ffebe Servicio Exchange MTA de Microsoft
38a94e72-a9bc-11d2-8faf-00c04fa378ff
MS-EXCHANGE-STORE 99e66040-b032-11d0-97a4-00c04fd6551d Servicio de almacén de Microsoft
89742ace-a9ed-11cf-9c0c-08002be7ae86 Exchange
a4f1db00-ca47-1067-b31e-00dd010662da
a4f1db00-ca47-1067-b31f-00dd010662da
MS-EXCHANGE-SYSATD 67df7c70-0f04-11ce-b13f-00aa003bac6c Servicio System Attendant de Microsoft
f930c514-1215-11d3-99a5-00a0c9b61b04 Exchange
83d72bf0-0d89-11ce-b13f-00aa003bac6c
469d6ec0-0d87-11ce-b13f-00aa003bac6c
06ed1d30-d3d3-11cd-b80e-00aa004b9c30
MS-FRS f5cc59b4-4264-101a-8c59-08002b2f8426 Servicio de replicación de archivos de
d049b186-814f-11d1-9a3c-00c04fc9b232 Microsoft
a00c021c-2be2-11d2-b678-0000f87a8f8e
MS-IIS-COM 70b51430-b6ca-11d0-b9b9-00a0c922e750 Servicio COM GUID/UUID de Microsoft
a9e69612-b80d-11d0-b9b9-00a0c922e70 Internet Information Server
MS-IIS-IMAP4 2465e9e0-a873-11d0-930b-00a0c90ab17c Servicio IMAP4 de Microsoft Internet
Information Server
MS-IIS-INETINFO 82ad4280-036b-11cf-972c-00aa006887b0 Servicio INETINFO de Microsoft
Internet Information Server
MS-IIS-NNTP 4f82f460-0e21-11cf-909e-00805f48a135 Servicio NNTP de Microsoft Internet
Information Server


MS-IIS-POP3 1be617c0-31a5-11cf-a7d8-00805f48a135 Servicio POP3 de Microsoft Internet
Information Server
MS-IIS-SMTP 8cfb5d70-31a4-11cf-a7d8-00805f48a135 Servicio SMTP de Microsoft Internet
Information Server
MS-ISMSERV 68dcd486-669e-11d1-ab0c-00c04fc2dcd2 Servicio Microsoft Inter-site Messaging
130ceefb-e466-11d1-b78b-00c04fa32883
MS-MESSENGER 17fdd703-1827-4e34-79d4-24a55c53bb37 Servicio Microsoft Messenger
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc
MS-MQQM fdb3a030-065f-11d1-bb9b-00a024ea5525 Servicio de administración de colas de
76d12b80-3467-11d3-91ff-0090272f9ea3 mensajes Microsoft Windows Message
1088a980-eae5-11d0-8d9b-00a02453c33 Queue Management
5b5b3580-b0e0-11d1-b92d-0060081e87f0
41208ee0-e970-11d1-9b9e-00e02c064c39
MS-NETLOGON 12345678-1234-abcd-ef00-01234567cffb Servicio Microsoft Netlogon
MS-SCHEDULER 1ff70682-0a51-30e8-076d-740be8cee98b Servicio Microsoft Scheduler
378e52b0-c0a9-11cf-822d-00aa0051e40f
0a74ef1c-41a4-4e06-83ae-dc74fb1cdd53
MS-WIN-DNS 50abc2a4-574d-40b3-9d66-ee4fd5fba076 Servidor DNS de Microsoft Windows
MS-WINS 45f52c28-7f9f-101a-b52b-08002b2efabe Servicio WINS de Microsoft
811109bf-a4e1-11d1-ab54-00a0c91e9b45

Grupos de servicios MS RPC

La tabla siguiente enumera los grupos de servicios MS RPC predefinidos.
Nombre Descripción
MS-AD Active Directory de Microsoft, incluyendo MS-AD-BR, MS-AD-DRSUAPI,
MS-AD-DSROLE y MS-AD-DSSETUP
MS-EXCHANGE Microsoft Exchange, incluyendo MS-EXCHANGE-DATABASE,
MS-EXCHANGE-DIRECTORY, MS-EXCHANGE-INFO-STORE,
MS-EXCHANGE-MTA, MS-EXCHANGE-STORE y MS-EXCHANGE-SYSATD
MS-IIS Microsoft Internet Information Server, incluyendo MS-IIS-COM, MS-IIS-IMAP4,
MS-IIS-INETINFO, MS-IIS-NNTP, MS-IIS-POP3 y MS-IIS-SMTP
Ejemplo: Servicios para MS RPC

Dado que los servicios MS RPC utilizan puertos negociados dinámicamente, no se pueden utilizar objetos de
servicios convencionales basándose en puertos TCP/UDP fijos para autorizarlos en la directiva de seguridad. En
lugar de ello, deben crearse objetos de servicios MS RPC utilizando UUIDs. El servicio MS Exchange Info Store,
por ejemplo, utiliza los cuatro UUIDs siguientes:
• 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
• 1453c42c-0fa6-11d2-a910-00c04f990f3b
• 10f24e8e-0fa6-11d2-a910-00c04f990f3b
• 1544f5e0-613c-11d1-93df-00c04fd7bd09
Los puertos TCP/UDP correspondientes son dinámicos. Para permitirlos, cree un objeto de servicio
ms-exchange-info-store del servicio que contenga estos cuatro UUIDs. Basándose en estos cuatro UUID, el ALG
asignará los números de programa a puertos TCP/UDP negociados dinámicamente y permitirá o denegará el
servicio basándose en una directiva que usted configure.
En este ejemplo, creará un objeto de servicio denominado my-ex-info-store que incluirá los UUIDs del servicio Info
Store de MS Exchange.

WebUI
Objects > Services > MS RPC: Introduzca los siguientes datos y haga clic en Apply :
Service Name: my-ex-info-store
UUID: 0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
UUID: 1453c42c-0fa6-11d2-a910-00c04f990f3b
UUID: 10f24e8e-0fa6-11d2-a910-00c04f990f3b
UUID: 1544f5e0-613c-11d1-93df-00c04fd7bd09
CLI
set service my-ex-info-store protocol ms-rpc uuid
0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde
set service my-ex-info-store + ms-rpc uuid 1453c42c-0fa6-11d2-a910-00c04f990f3b
set service my-ex-info-store + ms-rpc uuid 10f24e8e-0fa6-11d2-a910-00c04f990f3b
set service my-ex-info-store + ms-rpc uuid 1544f5e0-613c-11d1-93df-00c04fd7bd09
save

Real Time Streaming Protocol Application Layer Gateway

RTSP es un protocolo a nivel de aplicación que permite controlar la entrega de una o varias secuencias multimedia
sincronizadas, tales como audio y vídeo. Aunque RTSP es capaz de suministrar secuencias de datos por sí mismo
interpolando las secuencias de medios continuos con la secuencia de control, se suele utilizar más como “control
remoto de red” para servidores multimedia. El protocolo fue diseñado como medio para seleccionar canales de
entrega, como UDP, multicast UDP y TCP, así como para seleccionar el mecanismo de entrega basándose en el
protocolo RTP (“Real Time Protocol”). RTSP también puede utilizar el protocolo SDP (“Session Description Protocol”)
(consulte “SDP” en la pàgina 207) como medios para proporcionar información al cliente para el control agregado
de una presentación compuesta por secuencias de unos o varios servidores y el control no agregado de una
presentación compuesta por múltiples secuencias procedentes de un solo servidor. Los orígenes de datos pueden
ser suministrados en directo o clips almacenados.
Los dispositivos NetScreen admiten RTSP como servicio y permiten o deniegan el tráfico RTSP basándose en una
directiva que usted configure. ALG es necesario porque RTSP utiliza números de puerto asignados dinámicamente
que se incluyen en los datos del paquete durante el establecimiento de la conexión de control. ALG realiza el
seguimiento de los números de puerto asignados dinámicamente y abre los correspondientes ojos de aguja
(consulte “Creación de ojos de aguja” en la pàgina 208). En el modo NAT, ALG traduce las direcciones y puertos IP
según se requiera. Los dispositivos NetScreen admiten RTSP en los modos de ruta, transparente, NAT basado en
interfaz y NAT basado en directivas.
La siguiente ilustración representa una sesión RTSP típica. El cliente inicia una sesión (por ejemplo, cuando el
usuario hace clic en el botón de reproducción de RealPlayer), establece una conexión TCP al servidor RTSP en el
puerto 554 y envía el mensaje OPTIONS (los mensajes también se denominan métodos) para descubrir qué
funciones de audio y vídeo soporta el servidor. El servidor responde al mensaje OPTIONS especificando el nombre
y la versión del servidor, así como un identificador de sesión, por ejemplo 24256-1. (Para obtener más información
sobre métodos, consulte “Métodos de petición del protocolo SIP” en la pàgina 201 y RFC 2326, sección 11).
A continuación, el cliente envía el mensaje DESCRIBE con la URL del archivo multimedia que desea. El servidor
responde al mensaje DESCRIBE con una descripción del medio utilizando el formato SDP. Seguidamente, el
cliente envía el mensaje SETUP, que especifica los mecanismos de transporte de secuencias de medios
aceptables para el cliente, por ejemplo RTP/RTCP o RDT, y los puertos en los que recibirá los medios. Con NAT, el
ALG RTSP supervisa estos puertos y los traduce cuando sea necesario. El servidor responde al método SETUP
seleccionando uno de los protocolos de transporte, lo que pone de acuerdo al cliente y al servidor en cuanto al
mecanismo para el transporte de los medios. A continuación, el cliente envía el método PLAY y el servidor
comienza a enviar la secuencia multimedia al cliente.

Cliente RealPlayer Dispositivo Servidor RealMedia

Puerto 3408 NetScreen Puerto 554
1. SYN (puerto 3408 al puerto RTSP 554)

2. SYN ACK
3. ACK
4. OPTIONS (admitidas)
5. RTSP OK (sesión 24256-1 creada)
6. DESCRIBE (presentación de medios)
7. RTSP OK (con SDP de presentación de medios)
8. SDP (continuación)
9. SETUP (el cliente “escucha” en el puerto 6970
a la espera de medios)
10. RTSP OK (sesión 2456-1 desde el puerto 9086)
11. SET_PARAM
12. RTSP OK
13. PLAY
14. RTSP OK (información RTP especificada)
15. Datos RTP enviados desde el servidor
Puerto Puerto
6970 16. Datos RTCP ocasionales 9086
17. TEARDOWN
17. RSTP OK
17. TCP RST

Métodos de petición RTSP

La tabla siguiente enumera los métodos que se pueden aplicar a un recurso (objeto multimedia), la dirección o
direcciones de flujo de la información y si el método es requerido, recomendado u opcional. Por presentación se
entiende información tal como las direcciones de red, la codificación y el contenido de un conjunto compuesto por
una o varias secuencias presentadas al cliente como provisión de medios completa. Una secuencia es una
instancia de medios única, por ejemplo de audio o de vídeo, así como todos los paquetes creados por un origen
durante la sesión.
Método Sentido Objeto Requisito

Cliente a servidor Presentación, secuencia Cliente a servidor requerido
OPTIONS
Servidor a cliente Presentación, secuencia Servidor a cliente opcional
DESCRIBE Cliente a servidor Presentación, secuencia Recomendado
Cliente a servidor Presentación, secuencia
ANNOUNCE Opcional
Servidor a cliente Presentación, secuencia
SETUP Cliente a servidor Secuencia Requerido
Cliente a servidor
GET_PARAMETER Presentación, secuencia Opcional
Servidor a cliente
Cliente a servidor
SET_PARAMETER Presentación, secuencia Opcional
Servidor a cliente
PLAY Cliente a servidor Presentación, secuencia Requerido
PAUSE Cliente a servidor Presentación, secuencia Recomendado
RECORD Cliente a servidor Presentación, secuencia Opcional
REDIRECT Servidor a cliente Presentación, secuencia Opcional
TEARDOWN Cliente a servidor Presentación, secuencia Requerido
Nota: En el futuro podrían definirse métodos adicionales.

Definición de los métodos:

• OPTIONS: El cliente consulta al servidor qué características de audio o vídeo admite y otros datos como el
nombre y la versión del servidor y la identificación de la sesión.
• DESCRIBE: Para el intercambio de los datos de inicialización de medios, como velocidad del reloj, tablas
de colores y cualquier información independiente del transporte que el cliente pueda necesitar para
reproducir la secuencia de medios. Generalmente, el cliente envía la URL del archivo que está solicitando y
el servidor responde con una descripción del medio en formato SDP. (Consulte “SDP” en la pàgina 207).
• ANNOUNCE: El cliente utiliza este método para publicar una descripción de la presentación o del objeto
multimedia identificado por la URL solicitada. El servidor utiliza este método para actualizar la descripción
de la sesión en tiempo real.
• SETUP: El cliente especifica los mecanismos de transporte aceptables, como los puertos en los que
recibirá la secuencia de medios y el protocolo de transporte.
• GET_PARAMETER: Consulta el valor de una presentación o el parámetro de la secuencia especificado en
el URL. Este método se puede utilizar sin cuerpo de entidad para verificar la presencia del cliente o del
servidor. Para verificar si el cliente o servidor está “vivo” también se puede utilizar el comando “ping”.
• SET_PARAMETER: El cliente utiliza este método para establecer el valor de un parámetro de la
presentación o secuencia especificado por el URL. Por cuestiones relacionadas con el cortafuegos, este
método no se puede utilizar para establecer parámetros de transporte.
• PLAY: Ordena al servidor que comience a enviar datos usando el mecanismo especificado en SETUP. El
cliente no enviará peticiones PLAY hasta que todas las peticiones SETUP sean correctas. El servidor pone
en cola las peticiones PLAY por orden y retrasa la ejecución de nuevas peticiones PLAY hasta que se haya
completado una petición PLAY activa. Las peticiones PLAY pueden o no contener un rango especificado.
El rango puede contener un parámetro de tiempo, expresado en UTC (hora universal coordinada), para
comenzar la reproducción, que también se puede utilizar para sincronizar secuencias procedentes de
diversos orígenes.
• PAUSE: Detiene temporalmente la transmisión de una presentación activa. Si la URL solicitada especifica
una secuencia particular, por ejemplo de audio, esto equivale a silenciarla. La sincronización de pistas se
mantiene al reanudar la reproducción o grabación, aunque los servidores pueden cerrar la sesión si PAUSE
corresponde a la duración especificada en el parámetro de tiempo de espera en SETUP. Una petición
PAUSE descarta todas las peticiones PLAY existentes en la cola.

• RECORD: Comienza a grabar el rango de medios definido en la descripción de la presentación. Con una
marca de hora UTC se indican las horas de comienzo y de final, de lo contrario el servidor utilizará las horas
de comienzo y de final de la descripción de la presentación.
• REDIRECT: Informa al cliente de que debe conectarse a otro servidor; también contiene tanto su
información de ubicación como, posiblemente, un parámetro de rango de esa nueva URL. Para seguir
recibiendo medios para este URI, el cliente debe generar una petición TEARDOWN para la sesión actual y
un SETUP para la nueva sesión.
• TEARDOWN: Detiene la entrega de la secuencia del URI dado y libera los recursos asociados a la misma.
Salvo que todos los parámetros de transporte sean definidos por la descripción de la sesión, debe emitirse
una petición SETUP para que la sesión pueda volver a reproducirse.
Códigos de estado de RTSP

RTSP utiliza códigos de estado para proporcionar información sobre peticiones del cliente y del servidor. Los
códigos de estado incluyen un código de resultado de tres cifras interpretable por la máquina, así como una frase
descriptiva del motivo. El cliente puede elegir si desea visualizar la frase del motivo. Los códigos de estado están
clasificados de la siguiente manera:
• Informativo (100 a 199): petición recibida y en proceso
• Éxito (200 a 299): acción recibida correctamente, comprendida y aceptada
• Redirección (300 a 399): se requiere una acción adicional para completar la petición
• Error del cliente (400 a 499): la petición es sintácticamente incorrecta y no se puede llevar a cabo
• Error del servidor (500 a 599): el servidor no pudo cumplir una petición aparentemente válida
La tabla siguiente enumera todos los códigos de estado definidos para RTSP 1.0 y las frases de motivo
recomendadas. Las frases de motivo se pueden revisar o redefinir sin que ello afecte al funcionamiento del
protocolo.
Código de Frase del motivo Código de Frase del motivo
estado estado
100 Continue 414 Request-URI Too Large
200 OK 415 Unsupported Media Type

Código de Frase del motivo Código de Frase del motivo

estado estado
201 Created 451 Unsupported Media Type
250 Low on Storage Space 452 Conference Not Found
300 Multiple Choices 453 Not Enough Bandwidth
301 Moved Permanently 454 Session Not Found
303 See Other 455 Method Not Valid in This State
304 Not Modified 456 Header Field Not Valid for Resource
305 Use Proxy 457 Invalid Range
400 Bad Request 458 Parameter is Read-Only
401 Unauthorized 459 Aggregate operation not allowed
402 Payment Required 460 Only aggregate operation allowed
403 Forbidden 461 Unsupported transport
404 Not Found 462 Destination unreachable
405 Method Not Allowed 500 Internal Server Error
406 Not Acceptable 501 Not Implemented
407 Proxy Authentication Required 502 Bad Gateway
408 Request Time-out 503 Service Unavailable
410 Gone 504 Gateway Time-out
411 Length Required 505 RTSP Version not supported
412 Precondition Failed 551 Option not supported
413 Request Entity Too Large
Nota: Para ver las definiciones completas de los códigos de estado, consulte RFC 2326, “Real Time Streaming
Protocol (RTSP)”.

Ejemplo: Servidor de medios en un dominio privado

En este ejemplo, el servidor de medios se encuentra en la zona Trust y el cliente en la zona Untrust. Usted decide
colocar una MIP en la interfaz ethernet3 hacia el servidor de medios en la zona Trust y luego crear una directiva
para permitir que el tráfico de RTSP pase desde el cliente en la zona Untrust al servidor de medios en la zona Trust.
ethernet1 ethernet3
Trust 10.1.1.1 1.1.1.1 Untrust
Dispositivo
LAN NetScreen LAN
Servidor de Mip de dispositivo Cliente

medios virtual 1.1.1.5
10.1.1.3 en Ethernet3
1.1.1.3 -> 10.1.1.3
WebUI
1. Interfaces
Zone Name: Trust
Manage IP: 10.1.1.2

Zone Name: Untrust
Manage IP: 1.1.1.2
2. Direcciones
Address Name: media_server
Zone: Trust
Address Name: client
Zone: Untrust
3. MIP
Network > Interfaces > Edit (para ethernet3) > MIP > New: Introduzca los siguientes datos y haga clic
en OK :
Mapped IP 1.1.1.3

4. Directiva
Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), client
Address Book Entry: (seleccione), MIP(1.1.1.3)
Service: RTSP
Action: Permit
CLI
1. Interfaces
set interface ethernet1 trust
set interface ethernet1 ip 10.1.1.1
set interface ethernet3 untrust

2. Direcciones
set address trust media_server 10.1.1.3/24
set address untrust client 1.1.1.5
3. MIP
set interface ethernet3 mip (1.1.1.3) host 10.1.1.3
4. Directiva
set policy from untrust to trust client mip(1.1.1.3) rtsp permit
save

Ejemplo: Servidor de medios en un dominio público

En este ejemplo, el servidor de medios se encuentra en la zona Untrust y el cliente en la zona Trust. Usted colocará
un conjunto de DIP en la interfaz ethernet3 para ejecutar NAT cuando el servidor de medios responda al cliente
desde la zona Untrust y luego creará una directiva para permitir que el tráfico RTSP fluya desde la zona Trust a la
zona Untrust.
ethernet1 ethernet3
10.1.1.1 1.1.1.1
Trust Untrust
Dispositivo
LAN LAN
Conjunto de DIP
en ethernet3
Cliente Servidor de medios
1.1.1.5 a 1.1.1.50
10.1.1.3 1.1.1.3
WebUI
1. Interfaz
Zone Name: Trust
Manage IP: 10.1.1.2
Zone Name: Untrust
Manage IP: 1.1.1.2

2. Direcciones
Address Name: client
Zone: Trust
Address Name: media_server
Zone: Untrust
3. Conjunto de DIP
Network > Interfaces > Edit (para ethernet3) > DIP > New: Introduzca los siguientes datos y haga clic en
OK :
ID: 5
IP Address Range: (seleccione) 1.1.1.5 ~ 1.1.1.50
Port Translation: (seleccione)
4. Directiva
Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry (seleccione): client
Address Book Entry (seleccione): media_server
Service: RTSP

Action: Permit
> Advanced: Introduzca los siguientes datos y haga clic en OK :
NAT:
Source Translation: (seleccione)
(DIP on): 5 (1.1.1.5-1.1.1.50)/port-xlate
CLI
1. Interfaz

2. Direcciones
set address trust client ip 10.1.1.3/24
set address untrust media_server ip 1.1.1.3/24
3. Conjunto de DIP
set interface ethernet3 dip 5 1.1.5 1.1.1.50
4. Directiva
set policy from trust to untrust client media_server rtsp nat dip 5 permit
save

Protocolo H.323 para “Voice-over-IP”

El protocolo H.323 permite asegurar la comunicación de voz mediante IP (“Voice-over-IP” o “VoIP”) entre equipos
terminales, como teléfonos IP y dispositivos de multimedia. En estos sistemas de telefonía, los equipos selectores
(“gatekeeper”) gestionan el registro y la admisión de llamadas, así como el estado de las llamadas “VoIP”. Los
equipos selectores pueden residir en dos zonas diferentes o en la misma zona.
Equipo selector Equipo selector

Permitido Internet

Permitido
Punto final Punto final
Nota: En los ejemplos siguientes se utilizan teléfonos IP con fines ilustrativos, aunque pueden configurarse otros
©
equipos que utilicen el protocolo VoIP, como dispositivos multimedia de NetMeeting .
Ejemplo: Equipo selector (“gatekeeper”) en la zona Trust (modo “transparente”

o “ruta”)
En el ejemplo siguiente configurará dos directivas para permitir al tráfico H.323 pasar entre los hosts de telefonía IP
y un equipo selector en la zona Trust y un teléfono IP en la dirección IP 2.2.2.5 de la zona Untrust. En este ejemplo,
el dispositivo NetScreen puede estar en modo transparente (“Transparent”) o de ruta (“Route”). Las dos zonas de
seguridad Trust y Untrust se encuentran en el dominio de enrutamiento trust-vr.

Equipo Internet
selector
Teléfonos Teléfono IP
IP de punto de punto final
final 2.2.2.5

WebUI
1. Dirección
Address Name: IP_Phone
Zone: Untrust
2. Directivas
Source Address:
Address Book Entry: (seleccione), IP_Phone
Service: H.323
Action: Permit
Source Address:
Service: H.323
Action: Permit

CLI
1. Dirección
set address untrust IP_Phone 2.2.2.5/32
2. Directivas
set policy from trust to untrust any IP_Phone h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
save
Ejemplo: Equipo selector (“gatekeeper”) en la zona Untrust (modo transparente

o ruta)
Dado que los modos transparente y ruta no requieren ningún tipo de asignación de direcciones, la configuración del
dispositivo NetScreen para un equipo selector en la zona Untrust es generalmente idéntica a la configuración de un
equipo selector en la zona Trust.
En el ejemplo siguiente configurará dos directivas para permitir al tráfico H.323 pasar entre los hosts de telefonía IP
en la zona Trust y el teléfono IP en la dirección IP 2.2.2.5 (y el equipo selector) de la zona Untrust. El dispositivo
puede estar en modo transparente o de ruta. Las dos zonas de seguridad Trust y Untrust se encuentran en el
dominio de enrutamiento trust-vr.
Internet
LAN Gatekeeper
IP_Phone
IP_Phones 2.2.2.5/32

WebUI
1. Direcciones
Address Name: IP_Phone
Zone: Untrust
Address Name: Gatekeeper
Zone: Untrust
2. Directivas
Source Address:
Service: H.323
Action: Permit

Source Address:
Service: H.323
Action: Permit
Source Address:
Address Book Entry: (seleccione), Gatekeeper
Service: H.323
Action: Permit
CLI
1. Direcciones
set address untrust IP_Phone 2.2.2.5/32
set address untrust gatekeeper 2.2.2.10/32
2. Directivas
set policy from trust to untrust any IP_Phone h.323 permit
set policy from trust to untrust any gatekeeper h.323 permit
set policy from untrust to trust IP_Phone any h.323 permit
set policy from untrust to trust gatekeeper any h.323 permit
save

Ejemplo: Llamadas salientes con NAT

Cuando el dispositivo NetScreen utiliza la traducción de direcciones de red (“Network Address Translation” o
“NAT”), un equipo selector (“gatekeeper”) o dispositivo de punto final de la zona Trust tiene una dirección privada, y
cuando se encuentra en la zona Untrust tiene una dirección pública. Cuando un dispositivo NetScreen se establece
en el modo NAT, debe asignarse una dirección IP pública a cada dispositivo que necesite recibir tráfico entrante con
una dirección privada.
En este ejemplo, los dispositivos de la zona Trust son el host de punto final (10.1.1.5) y el equipo selector
(10.1.1.25). IP_Phone2 (2.2.2.5) está en la zona Untrust. Configurará el dispositivo NetScreen para permitir tráfico
entre el host de punto final “IP_Phone1” y el equipo selector en la zona Trust y el host “IP_Phone2” de punto final en
la zona Untrust. Las dos zonas de seguridad Trust y Untrust se encuentran en el dominio de enrutamiento trust-vr.
ethernet1 ethernet3 Puerta de enlace

10.1.1.1/24 1.1.1.1/24 1.1.1.250
Equipo Internet
selector
10.1.1.25
IP_Phone1 IP_Phone2
10.1.1.5 MIP 1.1.1.25 -> 10.1.1.25 2.2.2.5
MIP 1.1.1.5 -> 10.1.1.5
WebUI
1. Interfaces
Zone Name: Trust
Seleccione los siguientes datos y haga clic en OK :

Interface Mode: NAT

Zone Name: Untrust
2. Direcciones
Address Name: IP_Phone1
Zone: Trust
Zone: Trust
Zone: Untrust

3. Direcciones IP asignadas
Network > Interfaces > Edit (para ethernet3) > MIP > New: Introduzca los siguientes datos y haga clic en
OK :
Mapped IP 1.1.1.5
Netmask: 255.255.255.255
OK :
Mapped IP 1.1.1.25
Netmask: 255.255.255.255
4. Ruta

5. Directivas
Source Address:
Address Book Entry: (seleccione), IP_Phone1
Service: H.323
Action: Permit
Source Address:
Service: H.323
Action: Permit
Source Address:
Service: H.323
Action: Permit

Source Address:
Service: H.323
Action: Permit
CLI
1. Interfaces

2. Direcciones
set address trust IP_Phone1 10.1.1.5/32
set address trust gatekeeper 10.1.1.25/32
set address untrust IP_Phone2 2.2.2.5/32
set interface ethernet3 mip 1.1.1.5 host 10.1.1.5
4. Ruta

5. Directivas
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust gatekeeper IP_Phone2 h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust IP_Phone2 mip (1.1.1.25) h.323 permit
save
Ejemplo: Llamadas entrantes con NAT

En este ejemplo configurará el dispositivo NetScreen para aceptar llamadas entrantes sobre un límite NAT. Para
ello puede crear un conjunto de direcciones DIP para direcciones de destino de asignación dinámica. Esto difiere de
la mayoría de configuraciones, en las que un conjunto DIP sólo proporciona direcciones de origen.
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
LAN
Internet
Conjunto de DIP con

ID 5
1.1.1.12 ~ 1.1.1.150
El nombre del conjunto de DIP puede ser DIP (id _num) para un DIP definido por el usuario o DIP (interface) cuando
el conjunto de DIP utilice la misma dirección que una dirección IP de interfaz. Puede utilizar tales entradas de
direcciones como direcciones de destino en directivas, junto con servicios H.323, SIP o otros protocolos VoIP (voz
sobre IP) para admitir llamadas entrantes.
En el ejemplo siguiente se utiliza DIP en una configuración VoIP H.323. La palabra clave “incoming” ordena al
dispositivo agregar las direcciones DIP y de interfaz a la zona global.

WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: Untrust
2. DIP con NAT entrante

Network > Interface > Edit (para ethernet3) > DIP > New: Introduzca los siguientes datos y haga clic en OK :
ID: 5
IP Address Range: (seleccione), 1.1.1.12 ~ 1.1.1.150
In the same subnet as the interface IP or its secondary IPs: (seleccione)
Incoming NAT: (seleccione)

3. Direcciones
Objects > Addresses > List > New (para Trust): Introduzca los siguientes datos y haga clic en OK :
Address Name: IP_Phones1
Zone: Trust
Objects > Addresses > List > New (para Untrust): Introduzca los siguientes datos y haga clic en OK :
Zone: Untrust
4. Directivas
Source Address:
Address Book Entry: (seleccione), IP_Phones1
Service: H.323
Action: Permit

Source Address:
Address Book Entry: (seleccione), DIP(5)
Service: H.323
Action: Permit
CLI
1. Interfaces
set interface ethernet3 dip 5 1.1.1.12 1.1.1.150 incoming
3. Direcciones
set address trust IP_Phones1 10.1.1.5/24
4. Directivas
set policy from trust to untrust IP_Phones1 any h.323 nat src dip 5 permit
set policy from untrust to trust IP_Phone2 dip(5) h.323 permit
save

Ejemplo: Equipo selector en la zona Untrust con NAT

En este ejemplo, el equipo selector (2.2.2.25) y el host IP_Phone2 (2.2.2.5) se encuentran en la zona Untrust y el
host IP_Phone1 (10.1.1.5) en la zona Trust. Configurará el dispositivo NetScreen para permitir tráfico entre el host
IP_Phone1 en la zona Trust y el host IP_Phone2 (más el equipo selector) en la zona Untrust. Las dos zonas de
seguridad Trust y Untrust se encuentran en el dominio de enrutamiento trust-vr.
Equipo
selector
ethernet3 2.2.2.25
ethernet1 1.1.1.1/24
10.1.1.1/24 Puerta de enlace
Modo NAT 1.1.1.250
Internet
LAN
IP_Phone1 IP_Phone2
10.1.1.5 MIP 1.1.1.5 -> 10.1.1.5 2.2.2.5
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT

Zone Name: Untrust
2. Direcciones
Zone: Trust
Zone: Untrust
Zone: Untrust

3. Dirección IP asignada
Network > Interfaces > Edit (para ethernet3) > MIP > New: Introduzca los siguientes datos y haga clic
en OK :
Mapped IP 1.1.1.5
Netmask: 255.255.255.255
4. Ruta
5. Directivas
Source Address:
Service: H.323
Action: Permit

Source Address:
Service: H.323
Action: Permit
Source Address:
Service: H.323
Action: Permit
Source Address:
Service: H.323
Action: Permit

CLI
1. Interfaces

2. Direcciones
set address trust IP_Phone1 10.1.1.5/32
set address untrust gatekeeper 2.2.2.25/32
4. Ruta
5. Directivas
set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
set policy from trust to untrust IP_Phone1 gatekeeper h.323 permit
set policy from untrust to trust IP_Phone2 mip(1.1.1.5) h.323 permit
set policy from untrust to trust gatekeeper mip(1.1.1.5) h.323 permit
save

Protocolo de inicio de sesión (“Session Initiation Protocol” o “SIP”)

El protocolo de inicio de sesión (“Session Initiation Protocol” o “SIP”) es un protocolo conforme al estándar del
equipo de ingeniería para el desarrollo de Internet (“Internet Engineering Task Force” o “IETF”) en el que se define
cómo iniciar, modificar y finalizar sesiones multimedia a través de Internet. Estas sesiones pueden ser de
conferencias, telefonía o transferencias de datos multimedia, con prestaciones como la mensajería inmediata
(“instant messaging”) y la movilidad de aplicaciones en entornos de red.
Los dispositivos NetScreen admiten SIP como servicio y pueden monitorizar el tráfico SIP, permitiéndolo o
rechazándolo según una directiva configurada por el usuario. SIP es un servicio predefinido en ScreenOS y utiliza
el puerto 5060 como puerto de destino.
Esencialmente, SIP se utiliza para distribuir la descripción de la sesión y, durante ésta, para negociar y modificar
sus parámetros. SIP también se utiliza para terminar una sesión multimedia.
El usuario incluye la descripción de la sesión en una petición INVITE o ACK. La descripción de la sesión indica el
tipo de multimedia de la sesión, por ejemplo, voz o vídeo. Para describir la sesión, SIP puede utilizar diversos
protocolos de descripción; NetScreen sólo admite el protocolo de descripción de la sesión (“Session Description
Protocol” o “SDP”).
SDP proporciona la información necesaria para que un sistema pueda unirse a una sesión multimedia. SDP puede
proporcionar datos como direcciones IP, números de puerto, fechas y horas. Observe que la dirección IP y el
número de puerto que figuran en el encabezado del protocolo SDP (los campos “c=” y “m=”, respectivamente)
corresponden a la dirección y al puerto donde el cliente desea recibir las secuencias multimedia (“streams”), y no
representan la dirección IP y el número de puerto donde se origina la petición SIP (aunque pueden coincidir). Para
obtener más información, consulte “SDP” en la pàgina 207.
Los mensajes del protocolo SIP consisten en peticiones de un cliente a un servidor y en las correspondientes
respuestas a esas peticiones enviadas por el servidor al cliente con el propósito de establecer una sesión (o
llamada). Un agente de usuario (“User Agent” o “UA”) es una aplicación que se ejecuta en los puntos finales de la
llamada y consta de dos partes: el cliente del agente de usuario (“User Agent Client” o “UAC”), que envía peticiones
SIP de parte del usuario, y un servidor del agente del usuario (“User Agent Server” o “UAS”), que escucha las
respuestas y notifica al usuario cuando llegan. Como ejemplos de agentes de usuario pueden citarse los servidores
proxy SIP y los teléfonos SIP.

Métodos de petición del protocolo SIP

El modelo transaccional del SIP contempla una serie de mensajes de petición y de respuesta, cada uno con un
campo method que describe el propósito del mensaje. ScreenOS admite los siguientes tipos de métodos y códigos
de respuesta:
• INVITE: Un usuario envía una petición INVITE para invitar a otro usuario a participar en una sesión. El
cuerpo de una petición INVITE puede contener la descripción de la sesión. En el modo NAT, las
direcciones IP en los campos de encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route:
se modifican según consta en la tabla “Encabezados SIP” en la pàgina 219.
• ACK: El usuario que generó la petición INVITE envía una petición ACK para confirmar la recepción de la
respuesta final a la invitación INVITE. Si la petición INVITE original no contenía la descripción de la sesión,
entonces la petición ACK debe incluirla. En el modo NAT, las direcciones IP en los campos de encabezado
Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route: se modifican según consta en la tabla
“Encabezados SIP” en la pàgina 219.
• OPTIONS: Utilizado por el agente del usuario (UA) para obtener información sobre las capacidades del
proxy del protocolo SIP. Un servidor responde con información sobre los métodos, protocolos de
descripción de sesiones y codificación de mensajes que admite. En el modo NAT, cuando la petición
OPTIONS se envía desde un NAT fuera del UA a un NAT dentro del proxy, el ALG del protocolo SIP
traduce la dirección en Request-URL y la dirección IP del campo To: a la dirección IP correspondiente al
cliente interno. Cuando el UA se encuentra dentro del NAT y el proxy fuera del NAT, el ALG del SIP traduce
los campos From:, Via: y Call-ID: según se muestra en la tabla en “Encabezados SIP” en la pàgina 219.
• BYE: Un usuario envía una petición BYE para abandonar una sesión. Una petición BYE de cualquier
usuario cierra automáticamente la sesión. En el modo NAT, las direcciones IP en los campos de
encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route: se modifican según consta en la
tabla “Encabezados SIP” en la pàgina 219.
• CANCEL: Un usuario puede enviar una petición CANCEL para cancelar una petición INVITE pendiente.
Una petición CANCEL no tiene ningún efecto si el servidor SIP que procesó la petición INVITE envió una
respuesta final a dicho INVITE antes de recibir la petición CANCEL. En el modo NAT, las direcciones IP en
los campos de encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route: se modifican según
consta en la tabla “Encabezados SIP” en la pàgina 219.

• REGISTER: Un usuario envía una petición REGISTER a un servidor de registrar SIP para informarle de la
ubicación actual del usuario. El servidor de registro SIP registra toda la información que recibe en las
peticiones REGISTER y pone esta información a disposición de cualquier servidor SIP que intente localizar
a un usuario. En el modo NAT, las peticiones REGISTER se gestionan como sigue:
– Peticiones REGISTER procedentes de un cliente externo a un servidor de registro interno: Cuando el
ALG del SIP recibe la petición REGISTER entrante traduce la dirección IP, si existe, en el
Request-URL. Sólo se permiten mensajes REGISTER entrantes a direcciones MIP o VIP. Para la
respuesta saliente no se requiere traducción.
– Peticiones REGISTER procedentes de un cliente interno a un registro externo: Cuando el ALG del SIP
recibe la petición REGISTER saliente, traduce las direcciones IP de los campos To:, From:, Via:,
Call-ID: y Contact:. Para la respuesta entrante se realiza una traducción inversa.
• Info: Utilizado para comunicar la información de señales durante la sesión a lo largo de la ruta de señales
para la llamada. En el modo NAT, las direcciones IP en los campos de encabezado Via:, From:, To:,
Call-ID:, Contact:, Route: y Record-Route: se modifican según consta en la tabla “Encabezados SIP” en la
pàgina 219.
• Subscribe: Utilizado para solicitar el estado actual y actualizaciones de estado a un nodo remoto. En el
modo NAT, la dirección Request-URI se transforma en una dirección IP privada si los mensajes proceden
de la red externa y entran en la red interna. Las direcciones IP en los campos de encabezado Via:, From:,
To:, Call-ID:, Contact:, Route: y Record-Route: se modifican según consta en la tabla “Encabezados SIP”
en la pàgina 219.
• Notify: Se envía para informar a suscriptores sobre cambios en el estado al que están suscritos. En el modo
NAT, la dirección IP en el campo de encabezado Request-URI se transforma en una dirección IP privada si
el mensaje procede de la red externa y entra en la red interna. La dirección IP en los campos de
encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route: se modifica según consta en la
• Refer: Se utiliza para enviar al destinatario (identificado por Request-URI) a un tercero mediante la
información de contacto proporcionada en la petición. En el modo NAT, la dirección Request-URI se
transforma en una dirección IP privada si el mensaje procede de la red externa y entra en la red interna. Las
direcciones IP en los campos de encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route:
se modifican según consta en la tabla “Encabezados SIP” en la pàgina 219.

Por ejemplo, si el usuario A de una red privada establece una referencia para el usuario B, que se
encuentra en una red pública, hacia el usuario C, que también pertenece a la red privada, el ALG del SIP
asigna nueva dirección IP y número de puerto al usuario C para que el usuario B pueda ponerse en
contacto con él. Sin embargo, si el usuario C está registrado con un servidor de registro, su asignación de
puertos se almacena en la tabla ALG NAT y se reutiliza para realizar la traducción.
• Update: Se utiliza para abrir un ojo de aguja para información SDP nueva o actualizada. Los campos de
encabezado Via:, From:, To:, Call-ID:, Contact:, Route: y Record-Route: se modifican según consta en la
• Códigos de respuesta 1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx: Utilizados para indicar el estado de una
transacción. Los campos del encabezado se modifican según se muestra en la tabla en “Encabezados SIP”
en la pàgina 219.

Clases de respuestas SIP

Los códigos de respuesta indican el estado de una transacción SIP y consisten en los códigos agrupados en las
clases siguientes:
• Informativos (100 a 199): petición recibida, continúa procesando la petición
• Éxito (200 a 299): acción recibida correctamente, comprendida y aceptada
• Redirección (300 a 399): se requiere una acción adicional para completar la petición
• Error del cliente (400 a 499): la petición es sintácticamente incorrecta o no se puede ejecutar en este
servidor
• Error del servidor (500 a 599): el servidor no pudo cumplir una petición aparentemente válida
• Fallo global (600 a 699): la petición no se puede realizar en ningún servidor
A continuación se incluye una lista completa de los actuales códigos de respuesta del protocolo SIP. NetScreen
admite todos.
1xx 100 Trying (Intentando) 180 Ringing (Llamando) 181 Call is being forwarded
(Reenviando llamada)
182 Queued (En cola) 183 Session progress (Progreso de
la sesión)
2xx 200 OK 202 Accepted (Aceptado)
3xx 300 Multiple choices (Varias 301 Moved permanently (Movido 302 Moved temporarily (Movido
opciones) permanentemente) temporalmente)
305 Use proxy (Utilizar proxy) 380 Alternative service (Servicio
alternativo)

4xx 400 Bad request (Petición 401 Unauthorized (No autorizado) 402 Payment required (Requiere
incorrecta) pago)
403 Forbidden (Prohibido) 404 Not found (No encontrado) 405 Method not allowed (Método no
permitido)
406 Not acceptable (No 407 Proxy authentication required 408 Request time-out (Petición
aceptable) (Requiere autenticación del proxy) caducada)
409 Conflict (Conflicto) 410 Gone (Ausente) 411 Length required (Requiere
longitud)
413 Request entity too large 414 Request-URL too large (URL 415 Unsupported media type (Tipo de
(Tamaño de la petición de la petición demasiado grande) medio incompatible)
excesivo)
420 Bad extension (Extensión 480 Temporarily not available 481 Call leg/transaction does not exist
incorrecta) (Temporalmente no disponible) (Tramo de la llamada o transacción
inexistente)
482 Loop detected (Detectado 483 Too many hops (Demasiado 484 Address incomplete (Dirección
bucle) saltos) incompleta)
485 Ambiguous (Ambiguo) 486 Busy here (Ocupado aquí) 487 Request cancelled (Petición
cancelada)
488 Not acceptable here (No
aceptable aquí)
5xx 500 Server internal error (Error 501 Not implemented (No 502 Bad gateway (Puerta de enlace
interno del servidor) implementado) incorrecta)
502 Service unavailable 504 Gateway time-out (Puerta de 505 SIP version not supported
(Servicio no disponible) enlace caducada) (Versión de SIP incompatible)
6xx 600 Busy everywhere 603 Decline (Declinar) 604 Does not exist anywhere (No
(Ocupado en todas partes) existe en ninguna parte)
606 Not acceptable (No
aceptable)

ALG – Application-Layer Gateway

Existen dos tipos de tráfico SIP, el de señalización y las secuencia de medios (“streams”). El tráfico de señalización
de SIP consiste en mensajes de petición y de respuesta intercambiados entre el cliente y el servidor y utiliza
protocolos de transporte como UDP o TCP. La secuencia multimedia transporta los datos (por ejemplo, de audio), y
utiliza protocolos de la capa de aplicación tales como protocolo de transporte en tiempo real (“Real-time Transport
Protocol” o “RTP”) sobre UDP.
Los dispositivos NetScreen admiten mensajes de señalización SIP en el puerto 5060. Basta con crear una directiva
que permita el servicio SIP para que el dispositivo NetScreen filtre el tráfico de señalización SIP como cualquier otro
tipo de tráfico, permitiéndolo o rechazándolo. La secuencia multimedia, sin embargo, utiliza números de puertos
asignados dinámicamente y que pueden cambiar varias veces durante el curso de una llamada. Sin puertos fijos es
imposible crear una directiva de direcciones estáticas para controlar el tráfico multimedia. En este caso, el
dispositivo NetScreen invoca el ALG de SIP. El ALG de SIP lee los mensajes del protocolo SIP y su contenido SDP
y extrae la información del número de puerto que necesita para abrir dinámicamente pequeños6 ojos de aguja por
los que permitir a la secuencia de medios atravesar el dispositivo NetScreen.
SIP ALG supervisa las transacciones SIP y crea y administra dinámicamente los “ojos de aguja basándose en la
información que extrae de esas transacciones. NetScreen SIP ALG admite todos los métodos y respuestas del
protocolo SIP (consulte “Métodos de petición del protocolo SIP” en la pàgina 201 y “Clases de respuestas SIP” en la
pàgina 204). Puede permitir a las transacciones SIP atravesar el cortafuegos de NetScreen creando una directiva
estática que permita el servicio SIP. Esta directiva habilita el dispositivo NetScreen para que intercepte tráfico SIP y
ejecute una de las siguientes acciones: permitir o denegar el tráfico o habilitar SIP ALG para abrir ojos de aguja por
los que entregar la secuencia multimedia. SIP ALG sólo necesita abrir ojos de aguja para las peticiones y
respuestas SIP que contienen información multimedia (SDP). En cuanto a los mensajes SIP que no contienen SDP,
el dispositivo NetScreen simplemente los deja pasar.
6. Por “ojo de aguja” se entiende la apertura limitada de un puerto para permitir determinado tráfico exclusivo.

SIP ALG intercepta los mensajes SIP que contienen SDP y, utilizando un analizador sintáctico, extrae la
información que requiere para crear ojos de aguja. SIP ALG examina la porción SDP del paquete y un analizador
sintáctico extrae datos tales como direcciones IP y números de puerto, que SIP ALG registra en una tabla de ojos
de aguja. SIP ALG utiliza las direcciones IP y los números de puerto registrados en la tabla de ojos de aguja para
abrir nuevos ojos de aguja que permitan a las secuencias multimedia atravesar el dispositivo NetScreen.
Nota: Los dispositivos NetScreen no admiten SDP encriptado. Si un dispositivo NetScreen recibe un mensaje SIP
con el SDP encriptado, SIP ALG permite de todos modos que pase a través del cortafuegos, pero genera un
mensaje para el registro informando al usuario de que no puede procesar el paquete. Si SDP está encriptado, SIP
ALG no puede extraer la información que necesita para abrir ojos de aguja. Consecuentemente, el contenido
multimedia descrito en el SDP no puede atravesar el dispositivo NetScreen.
SDP
Las descripciones de sesiones SDP consisten en un conjunto de líneas de texto. Pueden contener información de
la sesión y del medio. La información a nivel de sesión se refiere a toda la sesión, mientras que la información a
nivel de medio se refiere a una determinada secuencia multimedia. Una descripción de sesión SDP siempre
contiene información a nivel de sesión al principio de la descripción, y puede contener información a nivel de
medio7, que se incluye después.
De los muchos campos presentes en la descripción SDP, dos son particularmente útiles para SIP ALG porque
contienen la información de la capa de transporte. Ambos campos son los siguientes:
• c= para información de la conexión
Este campo puede aparecer a nivel de sesión o de medio. Se muestra en este formato:
c=<tipo de red><tipo de dirección><dirección de conexión>
Actualmente, el dispositivo NetScreen admite solamente “IN” (abreviatura de Internet) como tipo de red,
“IP4” como tipo de dirección y una dirección IP8 o nombre de dominio unicast como dirección IP de destino
(conexión).
7. En la descripción de la sesión SDP, la información a nivel del medio comienza con el campo “m=”.
8. Generalmente, la dirección IP de destino también puede ser una dirección IP multicast, pero por el momento NetScreen no admite multicast con SIP.

Si la dirección IP de destino es una dirección IP unicast, SIP ALG crea ojos de aguja usando la dirección IP
y los números de puerto especificados en el campo de descripción de medios m=.
• m= para anuncio de medio
Este campo aparece a nivel de medios y contiene la descripción del medio. Se muestra en este formato:
m=<medio><puerto><transporte><lista de formatos>
Actualmente, el dispositivo NetScreen admite solamente “audio” como medio y “RTP” como protocolo de
transporte de la capa de aplicación. El número de puerto indica el destino de la secuencia multimedia (y no
su origen). La lista de formatos (“fmt list”) proporciona información sobre el protocolo de la capa de
aplicación utilizado por el medio.
En esta versión de ScreenOS, el dispositivo NetScreen abre puertos solamente para RTP y RTCP. Cada
9
sesión RTP tiene una sesión RTCP (“Real-time Transport Control Protocol” o protocolo de control del
transporte en tiempo real) correspondiente. Por lo tanto, siempre que una secuencia multimedia utilice
RTP, SIP ALG debe reservar puertos (crear ojos de aguja) tanto para el tráfico RTP como RTCP. De forma
predeterminada, el número de puerto para RTCP es el siguiente al del puerto RTP.
Creación de ojos de aguja

Los ojos de aguja para el tráfico RTP y RTCP comparten la misma dirección IP de destino. La dirección IP
procede del campo “c=” en la descripción de sesión de SDP. Debido a que el campo “c=” puede aparecer
tanto en la porción del nivel de sesión como en la del nivel del medio dentro de la descripción de la sesión
SDP, el analizador sintáctico (“parser”) determina la dirección IP basándose en las reglas siguientes
(siguiendo las convenciones de SDP):
– En primer lugar, el analizador sintáctico de SIP ALG verifica si hay un campo “c=” que contenga una
dirección IP en el nivel de medios. Si hay alguno, extrae dicha dirección IP y SIP ALG la utiliza para
crear un ojo de aguja para el medio.
– Si no hay ningún campo “c=” a nivel de medio, el analizador sintáctico de SIP ALG extrae la dirección
IP del campo “c=” en el nivel de sesión y SIP ALG la utiliza para crear un ojo de aguja para el medio.
Si la descripción de la sesión no contiene un campo “c=” en ningún nivel, significa que existe un error
en la pila del protocolo, por lo que el dispositivo NetScreen descarta el paquete y registra el evento.
9. RTCP proporciona sincronización de medios e información sobre los miembros de la sesión y la calidad de la comunicación.

La lista siguiente muestra la información que SIP ALG necesita para crear un ojo de aguja. Esta
información procede de la descripción de la sesión SDP y de los parámetros del dispositivo NetScreen:
– Protocol: UDP
– Source IP: unknown
– Source port: unknown
– Destination IP: El analizador sintáctico extrae la dirección IP de destino del campo “c=” en el nivel de
medio o de sesión.
– Destination port: El analizador sintáctico extrae el número del puerto de destino para RTP del campo
“m=” en el nivel de medios y calcula el número del puerto de destino para RTCP utilizando esta
fórmula: RTP port number.
– Lifetime: Este valor indica el tiempo (en segundos) que permanece abierto un ojo de aguja para
permitir el paso de un paquete. Un paquete debe pasar a través del ojo de aguja antes de que
caduque este tiempo. Cuando caduca, SIP ALG elimina el ojo de aguja.
Cuando un paquete atraviesa el ojo de aguja dentro del periodo de vigencia, inmediatamente después
SIP ALG elimina el ojo de aguja para el sentido de procedencia del paquete.
La ilustración siguiente describe una configuración de llamada entre dos clientes SIP y cómo SIP ALG
crea ojos de aguja para permitir el tráfico RTP y RTCP. La ilustración asume que el dispositivo
NetScreen tiene una directiva que permite el tráfico SIP, abriendo el puerto 5060 para mensajes de
señalización SIP.

Dispositivo NetScreen
Proxy SIP
Cliente SIP A Cliente SIP B
1.1.1.1 2.2.2.2

1. El Cliente A envía una petición “INVITE” 2. Por SDP,
destinada al Cliente B hacia el proxy SIP a través SIP ALG
del puerto 5060 del dispositivo NetScreen crea un ojo
SDP: 1.1.1.1:2000 (dirección IP:número de de aguja
puerto) para
1.1.1.1:2000 3. El proxy SIP transmite la petición “INVITE” al
Cliente B
4. El Cliente B contesta al proxy SIP con una

5. El proxy SIP remite la respuesta “Ringing” respuesta “Ringing” (“Llamando”)
del Cliente B al Cliente A a través del puerto
5060 del dispositivo NetScreen
7. Por SDP,
SIP ALG
crea un ojo 6. El Cliente B envía una respuesta “200 OK” al
de aguja proxy SIP como contestación a la petición INVITE
para SDP: 2.2.2.2:3000 (dirección IP:número de
8. El proxy SIP reenvía la respuesta “200 OK” 2.2.2.2:3000 puerto)
del Cliente B al Cliente A a través del
dispositivo NetScreen
9. El Cliente A envía una respuesta “ACK”
destinada al Cliente B al proxy SIP a través
del puerto 5060 del dispositivo NetScreen 10. El proxy SIP reenvía la respuesta “ACK” al
Cliente B
11. El Cliente B envía el medio (tráfico RTP/RTCP)

Ojo de aguja 1 al Cliente A a través del ojo de aguja 1
12. El Cliente A envía el medio (tráfico RTP/RTCP)
al Cliente B a través del ojo de aguja 2
Ojo de aguja 2

Nota: SIP ALG no crea ojos de aguja para el tráfico RTP y RTCP cuando la dirección IP de destino es
0.0.0.0 (ya que indica que la sesión está retenida). Para poner una sesión en estado retenido (“on hold”),
por ejemplo, durante una comunicación telefónica, un usuario (Usuario A) envía al otro usuario (Usuario B)
un mensaje SIP en el cual la dirección IP de destino es 0.0.0.0. De este modo se indica al Usuario B que
no envíe ningún medio hasta nuevo aviso. Si aún así el Usuario B envía algún medio, el dispositivo
NetScreen descarta los paquetes.
Tiempo de espera por inactividad de la sesión

Normalmente, una llamada termina cuando uno de los clientes envía una petición BYE o CANCEL. SIP ALG
intercepta la petición BYE o CANCEL y elimina todas las sesiones de medios de esa llamada. Existen posibles
causas o problemas que impedirían a los clientes de una llamada enviar peticiones BYE o CANCEL, por ejemplo,
un fallo de alimentación eléctrica. En este caso, la llamada podría continuar indefinidamente, consumiendo recursos
en el dispositivo NetScreen. La función de tiempo de espera por inactividad permite al dispositivo NetScreen
supervisar el “estado vital” de la llamada para terminarla si no hay actividad durante un periodo determinado de
tiempo.
Una llamada puede tener uno o varios canales de voz. Cada canal de voz tiene dos sesiones (o dos secuencias de
medios), una para RTP y otra para RTCP. En cuanto a la gestión de las sesiones, el dispositivo NetScreen trata las
sesiones de cada canal de voz como un grupo. Los ajustes tales como el tiempo de espera por inactividad se
aplican a nivel de grupo, no a cada sesión.
Existen dos tipos de tiempo de espera por inactividad que determinan la duración de un grupo:
• Signaling Inactivity Timeout: Este parámetro indica el tiempo máximo (en segundos) que una llamada
puede seguir activa sin que se señalice tráfico SIP. Cada vez que se genera un mensaje SIP durante una
llamada, este tiempo de espera se restablece. El ajuste predeterminado es de 43.200 segundos (12 horas).
• Media Inactivity Timeout: Este parámetro indica el tiempo máximo (en segundos) que una llamada puede
permanecer activa sin que se produzca tráfico de medios (RTP o RTCP) dentro de un grupo. Cada vez que
se genera un paquete RTP o RTCP durante una llamada, este tiempo de espera se restablece. El ajuste
predeterminado es de 120 segundos.
Si cualquiera de estos tiempos de espera caduca, el dispositivo NetScreen elimina todas las sesiones de esa
llamada en su tabla, terminando de ese modo la llamada.

Protección contra ataques SIP

La capacidad de procesamiento de llamadas del servidor proxy del SIP puede verse afectada por la repetición de
peticiones INVITE del SIP, tanto malévolas como por error del cliente o del servidor, denegado inicialmente. Para
impedir que el servidor proxy del SIP sea saturado por tales peticiones, puede utilizar el comando sip protect deny
para configurar el dispositivo NetScreen de modo que supervise las peticiones INVITE y las correspondientes
respuestas del servidor proxy. Si alguna respuesta contiene un código de respuesta 3xx, 4xx o 5xx (véase “Clases
de respuestas SIP” en la pàgina 204), ALG guarda la dirección IP de la petición y la dirección IP del servidor proxy
en una tabla. El dispositivo NetScreen comprueba posteriormente todas las peticiones INVITE realizadas contra
esta tabla y, durante un número configurable de segundos (el predeterminado es tres), descarta cualquier paquete
que coincida con entradas en la tabla. También puede configurar el dispositivo NetScreen para que supervise las
peticiones INVITE a un servidor proxy determinado especificando la dirección IP de destino. La protección contra
ataques del SIP se configura globalmente.
Ejemplo: SIP Protect Deny

En este ejemplo configurará el dispositivo NetScreen para que proteja un solo servidor proxy de SIP (1.1.1.3/24)
contra peticiones INVITE repetitivas a las que ya haya denegado el servicio. Los paquetes se descartan durante
cinco segundos, transcurridos los cuales el dispositivo NetScreen reanuda el reenvío de peticiones INVITE
procedentes de esos orígenes.
WebUI
Nota: Para proteger servidores proxy del SIP contra inundaciones causadas por peticiones INVITE, debe
utilizar CLI.
CLI
set sip protect deny dst-ip 1.1.1.3/24
set sip protect deny timeout 5
save

Ejemplo: Tiempos de espera por inactividad de señalización o de medios

En este ejemplo configurará el tiempo de espera por inactividad de señalización en 30.000 segundos y el tiempo de
espera por inactividad de medios en 90 segundos.
WebUI
Nota: Para establecer tiempos de espera para señalizaciones SIP e inactividad de medios, debe utilizar
CLI.
CLI
set sip signaling-inactivity-timeout 30000
set sip media-inactivity-timeout 90
save
Ejemplo: Protección contra inundaciones UDP

Puede proteger el dispositivo NetScreen contra inundaciones UDP por zona y por dirección de destino. En este
ejemplo, establecerá un umbral de 80.000 por segundo para el número de paquetes UDP que se pueden recibir en
la dirección IP 1.1.1.5, en la zona Untrust, antes de que el dispositivo NetScreen genere una alarma y descarte los
paquetes subsiguientes durante el resto de ese segundo.
Nota: Este ejemplo utiliza un comando general de ScreenOS, y no es necesariamente específico de SIP. Para
obtener más información sobre la protección contra inundaciones de UDP y cómo determinar los ajustes más
eficaces, consulte “Inundación UDP” en la pàgina 4 -69.
WebUI
Screening > Screen: Introduzca los siguientes datos y haga clic en Apply :
Zone: Untrust
UDP Flood Protection (seleccione)

>Destination IP: Escriba lo siguiente y haga clic en la flecha Atrás de su

explorador de Internet para regresar a la página de configuración de la
pantalla:
Destination IP: 1.1.1.5
Threshold: 80000
Add: (seleccione)
CLI
set zone untrust screen udp-flood dst-ip 1.1.1.5 threshold 80000
save
Ejemplo: Máximo de conexiones SIP

En este ejemplo impedirá ataques de inundación en la red SIP procedentes de atacantes de la zona Untrust,
estableciendo un máximo de 20 sesiones simultáneas desde una sola dirección IP. Si el dispositivo NetScreen
detecta más de 20 intentos de conexión desde la misma dirección IP, comienza a descartar los intentos
subsiguientes hasta que el número de sesiones caiga por debajo del máximo especificado.
Nota: Este ejemplo utiliza un comando general de ScreenOS, y no es necesariamente específico de SIP. Para
obtener más información sobre límites de sesiones basados en orígenes y cómo determinar los ajustes más
eficaces, consulte “Límites de sesiones según sus orígenes y destinos” en la pàgina 4 -42.
WebUI
Screening > Screen (Zone: Untrust): Introduzca los siguientes datos y haga clic en OK :
Source IP Based Session Limit: (seleccione)
Threshold: 20 Sessions
CLI
set zone untrust screen limit-session source-ip-based 20
save

SIP con traducción de direcciones de red (NAT)

El protocolo de traducción de direcciones de red (NAT) permite a múltiples equipos de una subred privada compartir
una sola dirección IP pública para acceder a Internet. Para el tráfico saliente, NAT reemplaza la dirección IP privada
del equipo dentro de la subred privada por la dirección IP pública. Para el tráfico entrante, la dirección IP pública se
transforma en la dirección privada y el mensaje se enruta al equipo apropiado de la subred privada.
La utilización conjunta de NAT con el servicio SIP es más complicada, porque los mensajes del SIP contienen
direcciones IP tanto en los encabezados como en el cuerpo SIP. Los encabezados SIP contienen información sobre
el llamante y el receptor, y el dispositivo NetScreen traduce esta información para ocultarla a la red exterior. El
cuerpo del SIP contiene la información del protocolo de descripción de sesión (“Session Description Protocol” o
“SDP”), que contiene las direcciones IP y números de puerto para la transmisión de los medios. El dispositivo
NetScreen traduce la información del SDP para asignar los recursos necesarios para enviar y recibir los medios.
La forma en que se reemplazan las direcciones IP y los números de puerto en mensajes SIP depende de la
dirección del mensaje. Para los mensajes salientes, la dirección IP y el número de puerto privados del cliente se
reemplazan por la dirección IP y el número de puerto públicos del cortafuegos de NetScreen. Para los mensajes
entrantes, la dirección pública del cortafuegos se reemplaza por la dirección privada del cliente.
Cuando se envía un mensaje INVITE a través del cortafuegos, SIP ALG recoge información del encabezado del
mensaje en una tabla de llamadas, que utiliza para reenviar los mensajes subsiguientes al punto de destino
correcto. Cuando llega un nuevo mensaje, por ejemplo un ACK o 200 OK, ALG compara los campos From:, To: y
Call-ID: con la tabla de llamadas para identificar el contexto de llamada del mensaje. Si llega un nuevo mensaje
INVITE que coincida con la llamada existente, ALG lo procesa como REINVITE.
Cuando llega un mensaje con información del SDP, ALG asigna puertos y crea una asignación NAT entre ellos y los
puertos en el SDP. Dado que el SDP requiere puertos consecutivos para los canales del protocolo en tiempo real
(“Real Time Protocol” o “RTP”) y del protocolo de control en tiempo real (“Real Time Control Protocol” o “RTCP”),
ALG proporciona puertos pares-impares consecutivos. Si no encuentra ningún par de puertos, descarta el mensaje
SIP.

Llamadas salientes
Cuando una llamada del SIP se inicia mediante un mensaje de petición SIP desde la red interna hacia la red
externa, NAT reemplaza las direcciones IP y los números de puerto en el SDP y crea un enlace para asignar las
direcciones IP y los números de puerto al cortafuegos de NetScreen. Los encabezados SIP de los campos Via:,
Contact:, Route: y Record-Route:, si están presentes, también se vinculan a la dirección IP del cortafuegos. ALG
almacena estas asignaciones para utilizarlas en retransmisiones y para los mensajes de respuesta del SIP.
A continuación, SIP ALG abre ojos de aguja en el cortafuegos para permitir el paso de medios a través del
dispositivo NetScreen por los puertos dinámicamente asignados, negociados basándose en la información del SDP
y de los campos de encabezado Via:, Contact: y Record-Route:. Los ojos de aguja también permiten que los
paquetes entrantes alcancen las direcciones IP y puertos Contact:, Via: y Record-Route:. Al procesar el tráfico de
retorno, ALG vuelve a insertar los campos SIP originales Contact:, Via:, Route: y Record-Route: en los paquetes.
Llamadas entrantes
Las llamadas entrantes se inician desde la red pública hacia direcciones IP públicas asignadas (MIP) o hacia
direcciones IP de interfaces del dispositivo NetScreen. Las MIPs son direcciones IP configuradas
estáticamente que apuntan a hosts internos; las direcciones IP de interfaz son registradas dinámicamente por
el ALG mientras supervisa los mensajes REGISTER enviados por hosts internos al servidor de registro del SIP.
(Para obtener más información, consulte “Soporte de llamadas SIP entrantes utilizando el servidor de registro del
SIP” en la pàgina 226). Cuando el dispositivo NetScreen recibe un paquete SIP entrante, genera una sesión y
reenvía la carga de datos del paquete al SIP ALG.
El ALG examina el mensaje de petición del SIP (inicialmente un INVITE) y, basándose en la información del SDP,
abre las puertas para los medios salientes. Cuando llega un mensaje de respuesta OK 200, el SIP ALG aplica NAT
a las direcciones y puertos IP y abre ojos de aguja en la dirección de salida. (Las puertas abiertas tienen un plazo
de vida corto y caducan si no se recibe rápidamente un mensaje de respuesta 200 OK).
Cuando llega una respuesta OK 200, el proxy del SIP examina la información SDP y lee las direcciones IP y
números de puerto de cada sesión de medios. El SIP ALG del dispositivo NetScreen aplica NAT a las direcciones y
números de puerto, abre ojos de aguja para el tráfico saliente y restablece el tiempo de espera para las puertas en
la dirección de entrada.

Cuando llega la señal ACK de 200 OK, también atraviesa el SIP ALG. Si el mensaje contiene información del SDP,
el ALG del SIP garantiza que las direcciones IP y los números de puerto no sean cambiados con respecto al
anterior INVITE; si lo son, el ALG elimina los ojos de aguja antiguos y crea otros nuevos para permitir el paso de los
medios. El ALG también supervisa los campos SIP Via:, Contact: y Record-Route: y abre nuevos ojos de aguja si
detecta que estos campos han cambiado.
Llamadas reenviadas
Una llamada es reenviada cuando, por ejemplo, el usuario A externo a la red llama al usuario B dentro de la red y
éste reenvía la llamada al usuario C fuera de la red. El ALG del SIP procesa la señal INVITE del usuario A como
llamada entrante normal. Pero cuando el ALG examina la llamada reenviada desde B a C, que se encuentra fuera
de la red, y detecta que B y C se pueden alcanzar a través de la misma interfaz, no abre ojos de aguja en el
cortafuegos, ya que los medios podrán fluir directamente entre el usuario A y el usuario C.
Terminación de la llamada
El mensaje BYE se utiliza para terminar una llamada. Cuando el dispositivo NetScreen recibe un mensaje BYE,
traduce los campos del encabezado igual que hace con cualquier otro mensaje, pero debido a que los mensajes
BYE debe ser confirmados por el receptor con 200 OK, el ALG retrasa el desmontaje de la llamada durante cinco
segundos para dar tiempo a que se transmita el 200 OK.
Mensajes de llamada Re-INVITE

Los mensajes Re-INVITE se utilizan para agregar nuevas sesiones de medios a una llamada y para eliminar
sesiones de medios existentes. Cuando se agregan nuevas sesiones de medios a una llamada, se abren nuevos
ojos de aguja en el cortafuegos y se crean nuevos enlaces de direcciones. El proceso es idéntico al establecimiento
original de la llamada. Cuando se eliminan una o más sesiones de medios de una llamada, los ojos de aguja se
cierran y los enlaces se anulan, igual que con un mensaje BYE.

Temporizadores de sesiones de llamadas

El ALG del SIP utiliza el valor Session-Expires para caducar una sesión si no se recibe ningún mensaje Re-INVITE
o UPDATE. El ALG obtiene el valor Session-Expires, si está presente, de la respuesta 200 OK al INVITE y utiliza
este valor para señalizar el tiempo de espera. Si el ALG recibe otro INVITE antes de que la sesión caduque,
restablece todos los valores del tiempo de espera a este nuevo INVITE o a valores predeterminados, y el proceso
se repite.
Como medida preventiva, el ALG del SIP utiliza valores de tiempo de espera codificados para definir el tiempo
máximo que una llamada puede existir. Esto garantiza que el dispositivo NetScreen esté protegido en los siguientes
casos:
• El sistema final se viene abajo durante una llamada y el mensaje BYE no se recibe nunca.
• Usuarios malévolos nunca envían un BYE para intentar atacar un ALG de SIP.
• Implementaciones pobres del proxy del SIP no pueden procesar Record-Route y nunca envían un mensaje
BYE.
• Fallos de red impiden la recepción de un mensaje BYE.
Cancelación de la llamada
Cualquier interlocutor puede cancelar una llamada enviando un mensaje CANCEL. En el momento de recibir un
mensaje CANCEL, el ALG del SIP cierra los ojos de aguja (que haya abiertos) en todo el cortafuegos y libera los
enlaces de direcciones. Antes de liberar los recursos, el ALG retrasa la caducidad del canal de control durante unos
cinco segundos para dar tiempo a que pase la señal 200 OK final. La llamada se termina cuando expira el tiempo
de espera de cinco segundos, tanto si llega una respuesta 487 como una “non-200”.
Bifurcación
La bifurcación permite a un proxy del SIP enviar un solo mensaje INVITE a múltiples destinos simultáneamente.
Cuando llegan los diferentes mensajes de respuesta 200 OK para esa única llamada, el ALG del SIP analiza pero
actualiza la información de la llamada con el mensaje primer mensaje 200 OK que recibe.

Mensajes del SIP

El formato de un mensaje del SIP consta de una sección de encabezado SIP y del cuerpo SIP. En mensajes de
petición, la primera línea de la sección de encabezado es la línea de petición, que incluye el tipo de método,
Request-URL y la versión del protocolo. En mensajes de respuesta, la primera línea es la línea de estado, que
contiene un código de estado. Los encabezados SIP contienen las direcciones IP y números de puerto utilizados
para la señalización. El cuerpo SIP, separado de la sección de encabezado por una línea en blanco, está reservado
para la información de descripción de la sesión, que es opcional. Actualmente, los dispositivos NetScreen sólo
admiten el protocolo SDP. El cuerpo SIP contiene las direcciones IP y los números de puerto utilizados para
transportar los medios.
En el modo NAT, el dispositivo NetScreen traduce la información de los encabezados SIP para ocultar la
información a la red exterior. NAT se aplica a la información del cuerpo SIP para asignar recursos, es decir,
números de puerto en los que se recibirán los medios.
Encabezados SIP
En el siguiente ejemplo de mensaje de petición del SIP, NAT reemplaza las direcciones IP en los campos del
encabezado, mostrados en negrita, para ocultarlos a la red exterior.
INVITE bob@10.150.20.5 SIP/2.0
Via: SIP/2.0/UDP 10.150.20.3:5434
From: alice@10.150.20.3
To: bob@10.150.20.5
Call-ID: a12abcde@10.150.20.3
Contact: alice@10.150.20.3:5434
Route: <sip:netscreen@10.150.20.3:5060>
Record-Route: <sip:netscreen@10.150.20.3:5060>

El método aplicado para traducir las direcciones IP depende del tipo y de la dirección del mensaje, que puede ser
uno de los siguientes:
• Petición entrante
• Respuesta saliente
• Petición saliente
• Respuesta entrante
La tabla siguiente muestra cómo se aplica NAT en cada uno de estos casos. Observe que, para varios de los
campos de encabezado, el ALG necesita saber algo más que la mera procedencia interior o exterior de los
mensajes. También necesita saber qué cliente inició la llamada y si el mensaje es una petición o una respuesta.
Tipo de mensaje Campos Acción

Petición entrante To: Reemplazar dirección ALG por dirección local
(de pública a privada) From: Ninguna
Call-ID: Ninguna
Via: Ninguna
Request-URL: Reemplazar dirección ALG por dirección local
Contact: Ninguna
Record-Route: Ninguna
Route: Ninguna


Respuesta saliente To: Reemplazar dirección ALG por dirección local
(de privada a pública) From: Ninguna
Call-ID: Ninguna
Via: Ninguna
Request-URL: N/D
Contact: Reemplazar dirección local por dirección ALG
Record-Route: Reemplazar dirección local por dirección ALG
Route: Ninguna
Petición saliente To: Ninguna
(de privada a pública) From: Reemplazar dirección local por dirección ALG
Call-ID: Reemplazar dirección local por dirección ALG
Via: Reemplazar dirección local por dirección ALG
Request-URL: Ninguna
Contact: Reemplazar dirección local por dirección ALG
Record-Route: Reemplazar dirección local por dirección ALG
Route: Reemplazar dirección ALG por dirección local


Respuesta saliente To: Ninguna
(de pública a privada) From: Reemplazar dirección ALG por dirección local
Call-ID: Reemplazar dirección ALG por dirección local
Via: Reemplazar dirección ALG por dirección local
Request-URL: N/D
Contact: Ninguna
Record-Route: Reemplazar dirección ALG por dirección local
Route: Reemplazar dirección ALG por dirección local

Cuerpo SIP
La información SDP en el cuerpo SIP contiene direcciones IP que ALG utiliza para crear canales para la secuencia
de medios. La traducción de la sección SDP también asigna recursos, es decir, números de puerto para enviar y
recibir los medios.
El siguiente extracto de una sección SDP muestra los campos que se traducen para la asignación de recursos.
o=user 2344234 55234434 IN IP4 10.150.20.3
c=IN IP4 10.150.20.3
m=audio 43249 RTP/AVP 0
Los mensajes SIP pueden contener más de una secuencia de medios. El concepto es similar a adjuntar varios
archivos a un mensaje de correo electrónico. Por ejemplo, un mensaje INVITE enviado desde un cliente SIP a un
servidor SIP puede tener los siguientes campos:
c=IN IP4 10.123.33.4
c=IN IP4 10.123.33.4

c=IN IP4 10.123.33.4

Los dispositivos NetScreen admiten hasta seis canales SDP negociados para cada dirección, hasta un total de 12
canales por llamada. Para obtener más información, consulte “SDP” en la pàgina 207.
Supuesto de NAT con el protocolo SIP

En la ilustración siguiente, ph1 envía un mensaje SIP INVITE a ph2. Observe cómo el dispositivo NetScreen
traduce las direcciones IP en los campos del encabezado, mostrados en fuente en negrilla.
La sección SDP del mensaje INVITE indica dónde el llamante está dispuesto a recibir medios. Observe que el ojo
de aguja de los medios contiene dos números de puertos, 52002 y 52003, para RTCP y RTP. El ojo de aguja
Via/Contact proporciona el número de puerto 5060 para la señalización del SIP.

Observe cómo, en el mensaje de respuesta 200 OK, las traducciones realizadas en el mensaje INVITE se invierten.
Las direcciones IP de este mensaje, al ser públicas, no se traducen, pero las puertas se abren para permitir el
acceso de la secuencia de medios a la red privada.
.
SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2
Red interna Red externa
INVITE Sip: ph2@6.6.6.2 SIP/2.0

Via: SIP/2.0/UDP 5.5.5.1 :5060 INVITE Sip: ph2@6.6.6.2 SIP/2.0
Call-ID: a1234 @5.5.5.1 Via: SIP/2.0/UDP 6.6.6.1 : 1234
From: ph1@ 5.5.5.1 Call-ID: a1234@6.6.6.1
To: ph2@6.6.6.2 From: ph1@ 6.6.6.1
CSeq 1 INVITE To: ph2@6.6.6.2
Content-type: application/sdp CSeq 1 INVITE
Content-Length: 98 Content-type: application/sdp
Content-Length: 98
V=O
o=ph1 3123 1234 IP IP4 5.5.5.1 V=O
c=IN IP4 5.5.5.1 o=ph1 3123 1234 IP IP4 6.6.6.1
m=audio 45002 RTP/AVP 0 c=IN IP4 6.6.6.1
Ojo de aguja de los medios
Cualquier
5.5.5.1 6.6.6.1 IP
45002/45003 52002/52003 Cualquier
puerto
Ojo de aguja Via/Contact

Cualquier
5.5.5.1 6.6.6.1 IP
5060 1234 Cualquier
puerto

SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1 6.6.6.2 SIP ph2

SIP/2.0 200 OK
Via: SIP/2.0/UDP 6.6.6.1 : 1234
SIP/2.0 200 OK Call-ID: a1234@6.6.6.1
Via: SIP/2.0/UDP 5.5.5.1 :5060 From: ph1@ 6.6.6.1
Call-ID: a1234 @5.5.5.1 To: ph2@ 6.6.6.2
From: ph1@ 5.5.5.1 CSeq 1 INVITE
To: ph2@6.6.6.2 Content-type: application/sdp
CSeq 1 INVITE Content-Length: 98
Content-type: application/sdp Contact: sip 6.6.6.6 : 5060
Content-Length: 98
V=0
V=0 o=ph2 5454 565642 IP IP4
o=ph2 5454 565642 IP IP4 6.6.6.2
6.6.6.2 c=IN IP4 6.6.6.2
c=IN IP4 6.6.6.2 m=audio 62002 RTP/AVP 0
Ojo de aguja de los medios
Cualquier
IP 6.6.6.2
Cualquier 62002/62003
puerto
Ojo de aguja Via/Contact
Cualquier
IP 6.6.6.2
Cualquier 5060
puerto
ACK SIP:ph2@6.6.6.2 SIP/2.0

.... ACK SIP:ph2@6.6.6.2 SIP/2.0
....

Soporte de llamadas SIP entrantes utilizando el servidor de registro del SIP

El registro del SIP proporciona una función de descubrimiento que permite a los proxies y servidores de
ubicaciones SIP identificar las ubicaciones donde los usuarios desean ser contactados. Un usuario registra una o
más ubicaciones de contacto enviando un mensaje REGISTER al servidor de registro. Los campos To: y Contact:
del mensaje REGISTER contienen la URI de la dirección del registro y al menos una URI de contacto, según
muestra la ilustración siguiente. El registro crea enlaces en un servicio de ubicación que asocia la dirección del
registro a la dirección o a las direcciones de contacto.
El dispositivo NetScreen supervisa los mensajes REGISTER salientes, aplica NAT a estas direcciones y almacena
la información en una tabla de DIP entrante. A continuación, cuando se recibe un mensaje INVITE desde fuera de la
red, el dispositivo NetScreen utiliza la tabla de DIP entrante para identificar a qué host interno enrutar el mensaje
INVITE. Puede aprovechar el servicio de registro del proxy SIP para permitir llamadas entrantes configurando DIP
de interfaz o conjuntos de DIP en la interfaz de salida del dispositivo NetScreen. DIP de interfaz es adecuado para
gestionar llamadas entrantes en una pequeña oficina, mientras que la creación de conjuntos de DIP se recomienda
para redes más grandes o entornos empresariales.
Nota: El soporte de llamadas entrantes usando DIP de interfaz o un conjunto de DIP sólo se admite para los
servicios SIP y H.323.
Para llamadas entrantes, actualmente los dispositivos NetScreen sólo admiten UDP y TCP. Actualmente tampoco
se admite la resolución de nombres de dominio, por lo que las URIs deben contener direcciones IP, según muestra
la ilustración siguiente.

Tabla de DIP entrante
5.5.5.1 : 1234 6.6.6.1 : 5555 3600
Dispositivo
NetScreen Servidor de
registro
6.6.6.2
SIP ph1 5.5.5.1 5.5.5.2 6.6.6.1
REGISTER sip: 6.6.6.2 SIP/2.0

From: ph1@ 5.5.5.1 Agregar
entrada a la
To: ph1@ 5.5.5.1 tabla de DIP
CSeq 1 INVITE entrante REGISTER sip:6.6.6.2 SIP/2.0
Contact <sip: 5.5.5.1:1234 > From: ph1@ 6.6.6.1
Expires: 7200 To: ph1@ 6.6.6.1
CSeq 1 INVITE
Contact <sip: 6.6.6.1:5555 >
Expires: 7200
200 OK
Actualizar From: ph1@ 6.6.6.1
200 OK
el valor del To: ph1@ 6.6.6.1
From: ph1@ 5.5.5.1 CSeq 1 INVITE
To: ph1@ 5.5.5.1 tiempo de
espera Contact <sip: 6.6.6.1:5555 >
CSeq 1 INVITE Expires: 3600
Contact <sip: 5.5.5.1:1234 >
Expires: 3600

Ejemplo: Llamada entrante (DIP de interfaz)

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 en la zona Trust y phone2 y el servidor proxy en
la interfaz ethernet3 de la zona Untrust. Usted configurará la DIP de interfaz en la interfaz ethernet3 para aplicar
NAT a las llamadas entrantes, a continuación creará una directiva que permita el tráfico SIP desde la zona Untrust
a la zona Trust y hará referencia a esa DIP en la directiva. También creará una directiva que permita el tráfico
SIP desde la zona Trust a la zona Untrust utilizando NAT Source. Esto permitirá a phone1 en la zona Trust
registrarse en el proxy de la zona Untrust. Para obtener una explicación sobre cómo funciona DIP entrante con
el servicio de registro SIP, consulte “Soporte de llamadas SIP entrantes utilizando el servidor de registro del SIP” en
la pàgina 226.
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
Dispositivo
NetScreen
LAN Internet
DIP de interfaz en
phone1 ethernet3 phone2 Servidor proxy
10.1.1.3 1.1.1.4 1.1.1.3
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT

Zone Name: Untrust
2. Direcciones
Address Name: phone1
Zone: Trust
Zone: Untrust
Address Name: proxy
Zone: Untrust


Network > Interface > Edit (para ethernet3) > DIP > New: Seleccione la opción Incoming NAT y haga clic
en OK .
4. Directivas
Source Address:
Address Book Entry: (seleccione) phone1
Address Book Entry: (seleccione) any
Service: SIP
Action: Permit
> Advanced: Escriba lo siguiente y haga clic en Return para establecer las
opciones avanzadas y regresar a la página de configuración básica:
NAT:
(DIP on): None (Use Egress Interface IP)
Source Address:
Address Book Entry: (seleccione), DIP(ethernet3)
Service: SIP
Action: Permit

CLI
1. Interfaces

2. Direcciones
set address trust phone1 10.1.1.3/24
set address untrust phone2 1.1.1.4/24
set address untrust proxy 1.1.1.3/24
set interface ethernet3 dip interface-ip incoming
set dip sticky
4. Directivas
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save

Ejemplo: Llamada entrante (conjunto de DIP)

En este ejemplo, phone1 se encuentra en la zona Trust y phone2 y el servidor proxy en la zona Untrust. Usted
configurará un conjunto de DIP en la interfaz ethernet3 para aplicar NAT a las llamadas entrantes, y a continuación
creará una directiva que permita el tráfico SIP desde la zona Untrust a la zona Trust y hará referencia al conjunto de
DIP en la directiva. También creará una directiva que permita el tráfico SIP desde la zona Trust a la zona Untrust
utilizando NAT Source. Esto permitirá a phone1 en la zona Trust registrarse en el proxy de la zona Untrust. Para
obtener una explicación sobre cómo funciona DIP con el servicio de registro SIP, consulte “Soporte de llamadas
SIP entrantes utilizando el servidor de registro del SIP” en la pàgina 226.
ethernet1 ethernet3
Trust 10.1.1.1/24 1.1.1.1/24 Untrust
LAN Internet
Conjunto de DIP en
phone1 ethernet3 phone2 Servidor proxy
10.1.1.3 1.1.1.20 -> 1.1.1.40 1.1.1.4 1.1.1.3
WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT

Zone Name: Untrust
2. Direcciones
Zone: Trust
Zone: Untrust
Address Name: proxy
Zone: Untrust

3. Conjunto de DIP con NAT entrante

ID: 5
IP Address Range: (seleccione), 1.1.1.20 ~ 1.1.1.40
4. Directivas
Source Address:
Address Book Entry: (seleccione), phone1
Service: SIP
Action: Permit
NAT:
(DIP on): 5 (1.1.1.20-1.1.1.40)/port-xlate))

Source Address:
Address Book Entry: (seleccione) Any
Address Book Entry: (seleccione) DIP(5)
Service: SIP
Action: Permit
CLI
1. Interfaces

2. Direcciones
3. Conjunto de DIP con NAT entrante
set interface ethernet3 dip 5 1.1.1.20 1.1.1.40 incoming
set dip sticky
4. Directivas
set policy from trust to untrust phone1 any sip nat src dip 5 permit
set policy from untrust to trust any dip(5) sip permit
save

Ejemplo: Llamada entrante con MIP

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 en la zona Trust y phone2 y el servidor proxy en la
interfaz ethernet3 de la zona Untrust. Usted pondrá una MIP en la interfaz ethernet3 para phone1, luego creará una
directiva que permita el tráfico SIP desde la zona Untrust a la zona Trust y hará referencia a esa MIP en la directiva.
También creará una directiva permitiendo que phone1 se registre con el servidor proxy en la zona Untrust. Este
ejemplo es similar a los dos ejemplos anteriores (“Ejemplo: Llamada entrante (DIP de interfaz)” en la pàgina 228 y
“Ejemplo: Llamada entrante (conjunto de DIP)” en la pàgina 232), salvo que con una MIP se necesita una dirección
pública por cada dirección privada en la zona Trust, mientras que con DIP de interfaz o un conjunto de DIP, una
sola dirección de interfaz puede servir múltiples direcciones privadas.
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
LAN Internet
phone1 MIP de dispositivo virtual phone2 Servidor

10.1.1.3 en ethernet3 proxy
1.1.1.4
1.1.1.1/24
WebUI
1. Interfaces
Zone: Trust

Interface Mode: NAT

Zone: Untrust
2. Direcciones
Zone: Trust
Zone: Untrust
Address Name: proxy
Zone: Untrust

3. MIP
OK :
Mapped IP: 1.1.1.3
Netmask: 255.255.255.255
4. Directiva
Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), any
Service: SIP
Action: Permit
CLI
1. Interfaces

2. Direcciones
3. MIP
4. Directiva
set policy from untrust to trust any mip(1.1.1.3) sip permit
save
Ejemplo: Proxy en la zona privada

En este ejemplo, phone1 y el servidor proxy del SIP están en la interfaz ethernet1 en la zona (privada) Trust, y
phone2 está en la interfaz ethernet3 en la zona Untrust. Pondrá una MIP en la interfaz ethernet3 hacia el servidor
proxy para permitir que phone2 se registre en el proxy y luego creará una directiva permitiendo el tráfico SIP desde
la zona Untrust a la zona Trust y hará referencia a esa MIP en la directiva. También creará una directiva desde la
zona Trust a la zona Untrust para permitir que phone1 efectúe llamadas externas.
ethernet1 ethernet3
10.1.1.1/24 1.1.1.1/24
Trust Untrust
Dispositivo
NetScreen
Internet
LAN
MIP de dispositivo phone2

Servidor proxy phone1 virtual
10.1.1.4 10.1.1.3 1.1.1.4
en ethernet3
1.1.1.2 -> 10.1.1.4

WebUI
1. Interfaces
Zone: Trust
Interface Mode: NAT
Zone: Untrust
2. Direcciones
Zone: Trust
Zone: Untrust

Address Name: proxy
Zone: Trust
3. MIP
Network > Interfaces > Edit (para loopback.3) > MIP > New: Introduzca los siguientes datos y haga clic en
OK :
Mapped IP: 1.1.1.2
Netmask: 255.255.255.255
4. Directivas
Source Address:
Address Book Entry: (seleccione) any
Service: SIP
Action: Permit
NAT:

Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Service: SIP
Action: Permit
CLI
1. Interfaces

2. Direcciones
set address trust proxy 10.1.1.4/24
3. MIP
4. Directivas
set policy from trust to untrust any phone2 sip nat src permit
set policy from untrust to trust phone2 mip(1.1.1.2) sip permit
save

Ejemplo: Proxy en la zona pública

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 en la zona Trust y phone2 y el servidor proxy en la
interfaz ethernet3 de la zona (pública) Untrust. Usted configurará DIP de interfaz en la interfaz Untrust y creará una
directiva permitiendo el tráfico SIP desde la zona Untrust a la zona Trust y hará referencia a esa DIP en la directiva.
También creará una directiva de Trust a Untrust para permitir que phone1 se registre en el servidor proxy en la zona
Untrust. Este ejemplo es similar a los ejemplos anteriores de llamadas entrantes (consulte “Ejemplo: Llamada
entrante (conjunto de DIP)” en la pàgina 232 y “Ejemplo: Llamada entrante con MIP” en la pàgina 236) y, como en
esos ejemplos, puede utilizar la DIP o MIP en la interfaz Untrust.
ethernet1 ethernet3
Trust 10.1.1.1/24 1.1.1.1/24 Untrust
LAN Internet
phone1 DIP de interfaz phone2 Servidor proxy

10.1.1.3 en ethernet3 1.1.1.4 1.1.1.3
WebUI
1. Interfaces
Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply:
Zone: Trust

Interface Mode: NAT
Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK:

Zone: Untrust
2. Direcciones
Zone: Trust
Zone: Untrust
Address Name: proxy
Zone: Untrust

3. DIP de interfaz
Network > Interface > Edit (para ethernet3) > DIP: Seleccione la casilla de verificación Incoming NAT .
4. Directivas
Source Address:
Service: SIP
Action: Permit
NAT:
Source Address:
Address Book Entry: (seleccione) DIP(ethernet3)
Service: SIP
Action: Permit

CLI
1. Interfaces

2. Direcciones
3. DIP de interfaz
4. Directivas
set policy from trust to untrust phone1 any sip nat src permit
set policy from untrust to trust any dip(ethernet3) sip permit
save

Ejemplo: Zona triple, proxy en DMZ

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 de la zona Trust, phone2 en la interfaz ethernet3 de
la zona Untrust y el servidor proxy en la interfaz ethernet2 de DMZ. Usted situará una MIP en la interfaz ethernet2
hacia phone1 en la zona Trust, creará una directiva desde DMZ a la zona Trust y luego hará referencia a esa MIP
en la directiva. De hecho, con tres zonas necesitará crear directivas bidireccionales entre cada una de ellas. Las
flechas en la ilustración siguiente muestran el flujo del tráfico SIP cuando phone2 de la zona Untrust genere una
llamada a phone1 en la zona Trust.
Untrust
Internet
phone2
1.1.1.4
ethernet3 ethernet2
10.1.1.1/24 2.2.2.2/24
DMZ
Dispositivo
NetScreen
ethernet1
10.1.1.1/24 MIP de Servidor
dispositivo proxy
virtual 2.2.2.4
en ethernet2
phone1 2.2.2.3 -> 10.1.1.3
LAN
10.1.1.3
Trust

WebUI
1. Interfaces
Zone: Trust

Interface Mode: NAT
Zone Name: DMZ
Zone Name: Untrust
2. Dirección
Zone: Trust

Zone: Untrust
Address Name: proxy
Zone: DMZ
3. MIP
OK :
Mapped IP 2.2.2.3
Netmask: 255.255.255.255
4. Directivas
Source Address:
Address Book Entry: (seleccione), proxy
Service: SIP
Action: Permit

NAT:
Source Translation: Enable
Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: SIP
Action: Permit
Source Address:
Service: SIP
Action: Permit
Source Address:

Service: SIP
Action: Permit
Policies > (From: DMZ, To: Trust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Service: SIP
Action: Permit
Source Address:
Service: SIP
Action: Permit
NAT:

CLI
1. Interfaces
set interface ethernet2 zone dmz
2. Direcciones
set address dmz proxy 2.2.2.4
3. MIP
set interface2 mip 2.2.2.3 host 10.1.1.3
4. Directivas
set policy from trust to dmz phone1 proxy sip nat src permit
set policy from dmz to untrust proxy phone2 sip permit
set policy from untrust to trust phone2 phone1 sip permit
set policy from untrust to dmz phone2 proxy sip permit
set policy from dmz to trust proxy mip(2.2.2.3) sip permit
set policy from trust to untrust phone1 phone2 sip nat src permit
save

Ejemplo: Untrust intrazonal

En este ejemplo, phone2 se encuentra en la interfaz ethernet2 de la zona Untrust, phone3 en una subred en la
interfaz ethernet3 de la zona Untrust, y el servidor proxy en la interfaz ethernet1 de la zona Trust. Para permitir
tráfico SIP intrazonal entre los dos teléfonos de la zona Untrust, creará una interfaz de loopback, agregará
ethernet2 y ethernet3 a un grupo de loopback y finalmente situará una MIP en la interfaz de loopback apuntando a
la dirección IP del servidor proxy. Crear una interfaz de loopback le permitirá utilizar una sola MIP para el servidor
proxy en la zona Trust. Dado que el bloqueo está activado de forma predeterminada en la zona Untrust, también
debe desactivarlo para permitir la comunicación intrazonal. Para obtener más información sobre la utilización de
interfaces de loopback, consulte “MIP y la interfaz de bucle invertido (loopback)” en la pàgina 7 -107.
Untrust
phone1 phone2
1.1.1.4 1.1.2.4
Internet
ethernet4 ethernet3
1.1.1.1/24 1.1.2.1/24
Loopback.1
1.1.4.1/24
MIP en Loopback.1
1.1.4.5 -> 10.1.1.5
ethernet1
10.1.1.1/24
proxy
10.1.1.5
LAN
Trust

WebUI
1. Interfaces
Zone: Trust

Interface Mode: NAT
Zone: Untrust
Zone: Untrust
Zone: Untrust (trust-vr)

2. Direcciones
Address Name: proxy
Zone: Trust
Zone: Untrust
Zone: Untrust
3. Grupo Loopback
As member of loopback group: (seleccione) loopback.1
Zone Name: Untrust
As member of loopback group: (seleccione) loopback.1
Zone Name: Untrust

4. MIP
Network > Interfaces > Edit (para loopback.1) > MIP > New: Introduzca los siguientes datos y haga clic en
OK :
Mapped IP 1.1.4.5
Netmask: 255.255.255.255
5. Bloqueo
Network > Zones > Edit (para Untrust): Introduzca los siguientes datos y haga clic en OK :
Block Intra-Zone Traffic: (anule la selección)
6. Directivas
Source Address:
Service: SIP
Action: Permit
NAT:

Source Address:
Service: SIP
Action: Permit
CLI
1. Interfaces



set interface loopback.1 ip 1.1.4.1/24
set interface loopback.1 route
2. Direcciones

3. Grupo Loopback
set interface ethernet2 loopback-group loopback.1
4. MIP
set interface loopback.1 mip 1.1.4.5 host 10.1.1.5
5. Bloqueo
unset zone untrust block
6. Directivas
set policy from trust to untrust proxy any sip nat src permit
set policy from untrust to trust any mip(1.1.4.5) sip permit
save

Ejemplo: Trust intrazonal

En este ejemplo, phone1 se encuentra en la interfaz ethernet1 de la zona Trust, phone2 en la interfaz ethernet2 en
una subred de la zona Trust, y el servidor proxy en la interfaz ethernet3 de la interfaz Untrust. Para permitir que
ambos teléfonos de la zona Trust se comuniquen entre sí, usted configurará DIP de interfaz en la interfaz ethernet3
para permitir que entren en contacto con el servidor proxy, y luego establecerá directivas determinadas para
permitir el tráfico SIP bidireccional entre las zonas Trust y Untrust. De forma predeterminada, el bloqueo está
desactivado en la zona Trust (como lo está en las zonas personalizadas que defina).
phone1 ethernet1
10.1.1.3 10.1.1.1/24 servidor proxy
ethernet3 3.3.3.4
Trust 3.3.3.3/24 Untrust
Dispositivo
NetScreen
Internet
LAN
phone2 DIP de interfaz

ethernet2 en ethernet3
10.1.2.2 10.1.2.1/24
WebUI
1. Interfaces
Zone: Trust

Interface Mode: NAT

Zone: Trust

Interface Mode: NAT
Zone: Untrust
2. Direcciones
Zone: Trust
Zone: Trust

Address Name: proxy
Zone: Untrust

4. Directivas
Source Address:
Service: SIP
Action: Permit
NAT:

Source Address:
Address Book Entry: (seleccione) proxy
Service: SIP
Action: Permit
> Advanced: Introduzca los siguientes datos y haga clic en Return para
establecer las opciones avanzadas:
NAT:
CLI
1. Interfaces



2. Direcciones
3. DIP de interfaz
4. Directivas
set policy from trust to untrust any proxy sip nat src permit
set policy from untrust to trust proxy dip(ethernet3) sip permit
save
Ejemplo: VPN de malla completa para SIP

En este ejemplo, la oficina central y dos sucursales están unidas por una VPN de malla completa. Cada sitio tiene
un solo dispositivo NetScreen. El servidor proxy se encuentra en la zona Trust de la oficina central, phone1 en la
zona Trust de la sucursal primera y phone2 en la zona Trust de la sucursal segunda. Todas las interfaces que
conectan los dispositivos se encuentran en sus respectivas zonas Untrust. En cada dispositivo configurará dos
túneles, conectados entre sí, para crear una red completamente interconectada.
Nota: Los dispositivos NetScreen utilizados en este ejemplo deben tener disponibles cuatro interfaces
configurables independientemente.

Nota: La zona Untrust de cada Proxy

dispositivo no se muestra Oficina central 10.1.3.3
Zona Trust
Trust
eth2/8-10.1.3.1
tunnel.1 tunnel.2
6.6.6.6 Central 7.7.7.7
Untrust Untrust
eth2/1-1.1.1.1 eth2/2-1.1.2.1
Enrutador de la puerta Enrutador de la

de enlace puerta de enlace
A la central: 1.1.1.1 A la central: 1.1.2.1
A branch-1:3.3.3.3 1 A branch-2:2.2.2.
VP
N
N
Untrust
VP
Untrust
2
eth3-3-3.3.3.3 eth3-2.2.2.2
interfaz tunnel.1 interfaz tunnel.2
no numerada Branch-1 VPN 3 Branch-2 no numerada
Trust Untrust Untrust Trust

eth1-10.1.1.1 eth4-4.4.4.4 eth4-5.5.5.5 eth1-10.1.2.1
Enrutador de la puerta de enlace

Zona Trust A branch-1: 4.4.4.4 Zona Trust
A branch-2: 5.5.5.5
interfaz tunnel.3 interfaz tunnel.3

Sucursal primera phone1 no numerada no numerada
phone2 Sucursal segunda
10.1.1.3 10.1.2.3

Nota: En este ejemplo, cada sección del WebUI enumera solamente rutas navegacionales que conducen a las
páginas necesarias para configurar el dispositivo. Para consultar los parámetros y valores específicos que necesita
establecer para cualquier sección del WebUI, consulte la sección de CLI que le sigue.
WebUI (para la central)

1. Interfaces
Network > Interfaces > Edit (para ethernet2/1)
Network > Interfaces > New Tunnel IF
2. Dirección
Objects > Addresses > List > New
3. VPN
VPNs > AutoKey IKE > New: > Advanced
4. Enrutamiento
Network > Routing > Routing Entries > New
5. Directivas
Policies > (From: Untrust, To: Trust) New
Policies > (From: Trust, To: Untrust) New

CLI (para la central)

1. Interfaces
set interface ethernet2/8 zone trust
set interface ethernet2/8 nat
set interface tunnel.1 zone untrust
2. Dirección
3. VPN
set ike gateway to-branch-1 address 3.3.3.3 main outgoing-interface ethernet2/1
preshare “netscreen” sec-level standard
set ike gateway to-branch-2 address 2.2.2.2 main outgoing-interface ethernet2/2
preshare “netscreen” sec-level standard
set vpn vpn_branch-1 gateway to-branch-1 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-1 id 1 bind interface tunnel.1
set vpn vpn-branch-2 gateway to-branch-2 no-reply tunnel idletime 0 sec-level
standard
set vpn vpn-branch-2 id 2 bind interface tunnel.2

4. Enrutamiento
set route 10.1.2.0/24 interface tunnel.2
5. Directivas
set policy from untrust to trust any proxy sip permit
set policy from trust to untrust proxy any sip permit
save
WebUI (Sucursal 2)
1. Interfaces
Network > Interfaces > Edit (para ethernet1)
2. Dirección
3. VPN
4. Enrutamiento
5. Directivas

CLI (Sucursal 2)
1. Interfaces

set interface tunnel.1 ip unnumbered interface ethernet3
2. Dirección
3. VPN
set ike gateway to-central address 1.1.1.1 Main outgoing-interface ethernet3
preshare "netscreen" sec-level standard
set ike gateway to-ns50 address 5.5.5.5 Main outgoing-interface ethernet4
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level
standard
set vpn vpncentral id 4 bind interface tunnel.1
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 id 5 bind interface tunnel.3

4. Rutas
5. Directivas
set policy from trust to untrust phone1 any sip permit
set policy from untrust to trust any phone1 sip permit
save
WebUI (Sucursal 1)
1. Interfaces
2. Dirección
3. VPN
4. Enrutamiento
5. Directivas

CLI (Sucursal 1)
1. Interfaces
2. Dirección
3. VPN
set ike gateway to-central address 1.1.2.1 main outgoing-interface ethernet3
set ike gateway to-ns50 address 4.4.4.4 main outgoing-interface ethernet4
set vpn vpncentral gateway to-central no-replay tunnel idletime 0 sec-level
standard
set vpn vpncentral bind interface tunnel.2
set vpn vpn-ns50 gateway to-ns50 no-replay tunnel idletime 0 sec-level standard
set vpn vpn-ns50 bind interface tunnel.3

4. Rutas
5. Directivas
set policy from trust to untrust phone2 any sip permit
set policy from untrust to trust any phone2 sip permit
save
Administración del ancho de banda para servicios de VoIP

Juniper Networks recomienda los siguientes métodos de administración del ancho de banda para servicios de VoIP,
utilizando los mecanismos de asignación de tráfico estándar de ScreenOS.
• Garantizar el ancho de banda para el tráfico VoIP: La manera más eficaz de asegurar calidad para el
servicio VoIP sin impedir otros tipos de tráfico en la interfaz es crear una directiva que garantice el ancho de
banda mínimo necesario para la cantidad prevista de tráfico VoIP en la interfaz y establecer una cola de
prioridades al más alto nivel. La ventaja de esta estrategia es que VoIP podrá utilizar ancho de banda
adicional cuando esté disponible, mientras que otros tipos de tráfico podrán utilizar el ancho de banda no
garantizado para VoIP cuando no esté siendo utilizado por VoIP.
• Limitar el ancho de banda para el tráfico que no es VoIP: Estableciendo un ancho de banda máximo para el
tráfico que no es VoIP, se pone el ancho de banda restante a disposición del tráfico VoIP. También se
establecerá una cola de prioridades al más alto nivel para el tráfico VoIP. El inconveniente de este método
es que el tráfico no VoIP no puede utilizar ancho de banda adicional aunque no esté siendo utilizado por el
tráfico VoIP.
• Utilizar una cola de prioridades y el marcado Differentiated Services Codepoint (DSCP): Garantizando el
ancho de banda para el tráfico VoIP y limitando el ancho de banda para el tráfico no VoIP se permite
controlar el flujo de datos en el dispositivo NetScreen. El marcado DSCP permite conservar los ajustes de
cola de prioridades “corriente abajo”, así como mantener o cambiar el valor DSCP recibido establecido por
el dispositivo de red o enrutador emisor “corriente arriba”, de modo que el enrutador del siguiente salto,
típicamente el enrutador LAN o WAN “fronterizo”, pueda hacer cumplir la calidad del servicio (“Quality of
Service” o QoS) en su dominio DiffServ. De forma predeterminada en configuraciones VPN, el dispositivo

NetScreen copia el marcado DSCP desde el encabezado interno del paquete IP al encabezado externo, de
modo que el enrutador del salto siguiente pueda hacer cumplir la calidad de servicio (QoS) correcta en el
tráfico codificado. Para obtener información sobre el funcionamiento de DSCP con niveles de prioridad en
directivas, consulte “Asignación de tráfico” en la pàgina 327.

La ilustración siguiente muestra cómo los ajustes de niveles de prioridad pueden afectar al uso del ancho de banda
garantizado (“guaranteed bandwidth” o “gbw”) y del ancho de banda máximo (“maximum bandwidth” o “mbw”) en
una interfaz ethernet1 (2 Mbps). La ilustración asume que usted ha determinado la necesidad de permitir al menos
ocho llamadas de VoIP (ancho de banda de 8 x 64 kbps por llamada, obteniendo un total de 512 kbps) y,
ocasionalmente, hasta 16 llamadas. Ha garantizado el ancho de banda restante al tráfico general de la oficina y ha
establecido el ancho de banda máximo para que el tráfico de la oficina disponga del ancho de banda no garantizado
al servicio de VoIP. Esto crea un solapamiento de 512 kbps en el ancho de banda máximo para los servicios de
VoIP y del tráfico de la oficina, indicado mediante líneas discontinuas.
El lado izquierdo de la ilustración muestra la utilización del ancho de banda con esos ajustes y un elevado tráfico de
oficina atravesando la interfaz, así como uso un nivel de utilización bajo de VoIP. Si VoIP necesitase
repentinamente más ancho de banda, a menos que su prioridad fuese superior a la de los servicios del tráfico de la
oficina, no podría conseguirla. El lado derecho de la ilustración muestra el grado de utilización del ancho de banda
en las mismas circunstancias que cuando VoIP tiene alta prioridad y el tráfico de la oficina tiene una prioridad
inferior. Para obtener más información sobre niveles de configuración de ancho de banda y de la prioridad, consulte
“Asignación de tráfico” en la pàgina 359.
Utilizar niveles de prioridad con ajustes del ancho de banda

Ajustes de ancho de banda Agregar ajustes de niveles
garantizado y máximo de prioridad
Ancho de banda total de 2 Mbps
Ancho de banda total de 2 Mbps

VoIP
gbw 512 kbps
VoIP
Tráfico de la oficina
mbw 1536 kbps mbw 1024 kbps
Tráfico de la
oficina
gbw 1024 kbps
VoIP Tráfico de la oficina

Grupos de servicios
Un grupo de servicios es un conjunto de servicios agrupados bajo un nombre. Una vez creado un grupo que
contenga varios servicios, se pueden aplicar servicios a las directivas a nivel de grupo, simplificando la
administración.
La opción de grupo de servicios de NetScreen tiene las siguientes características:
• Se puede hacer referencia a cada entrada del libro de servicios en uno o más grupos de servicios.
• Cada grupo de servicios puede contener entradas predefinidas y entradas definidas por el usuario en el
libro de servicios.
Los grupos de servicios están sujetos a las siguientes limitaciones:
• Los grupos de servicios no pueden llamarse igual que los servicios; por ejemplo, si existe un servicio
llamado “FTP”, no puede existir un grupo de servicios con el mismo nombre.
• Si en una directiva se hace referencia a un grupo de servicios, éste se puede editar, pero para eliminarlo
será necesario eliminar primero la referencia en la directiva.
• Si se elimina una entrada personalizada del libro de servicios, la entrada también será eliminada en todos
los grupos que contengan referencias a la misma.
• Un grupo de servicios no puede contener a otro grupo de servicios como miembro.
• El término “ANY” de servicio integral no se puede agregar a grupos.
• Un servicio sólo puede pertenecer a un grupo a la vez.

Ejemplo: Crear un grupo de servicios

En este ejemplo creará un grupo de servicios llamado “grp1” que incluirá los servicios IKE, FTP y LDAP.
WebUI
Objects > Services > Groups > New: Introduzca el siguiente nombre de grupo, mueva los siguientes servicios
y haga clic en OK :
Group Name: grp1
Seleccione IKE y utilice el botón << para mover el servicio de la columna
Seleccione FTP y utilice el botón << para mover el servicio de la columna
Seleccione LDAP y utilice el botón << para mover el servicio de la columna
CLI
set group service grp1
set group service grp1 add ike
set group service grp1 add ftp
set group service grp1 add ldap
save
Nota: Si intenta agregar un servicio a un grupo de servicios inexistente, el dispositivo NetScreen creará
ese grupo. Asegúrese también de que los grupos que contengan referencias a otros grupos no estén
autoincluidos en la lista de referencias.

Ejemplo: Modificar un grupo de servicios

En este ejemplo cambiará los miembros del grupo de servicios llamado “grp1” que creó en el “Ejemplo: Crear un
grupo de servicios” en la pàgina 275. Eliminará los servicios IKE, FTP y LDAP, y agregará HTTP, FINGER e IMAP.
WebUI
Objects > Services > Groups > Edit (para grp1): Mueva los siguientes servicios y haga clic en OK :
Seleccione IKE y utilice el botón >> para mover el servicio de la columna
“Group Members” a la columna “Available Members”.
Seleccione FTP y utilice el botón >> para mover el servicio de la columna
Seleccione LDAP y utilice el botón >> para mover el servicio de la columna
Seleccione HTTP y utilice el botón << para mover el servicio de la columna
Seleccione Finger y utilice el botón << para mover el servicio de la columna
Seleccione IMAP y utilice el botón << para mover el servicio de la columna
CLI
unset group service grp1 clear
set group service grp1 add http
set group service grp1 add finger
set group service grp1 add imap
save

Ejemplo: Eliminar un grupo de servicios

En este ejemplo eliminará un grupo de servicios denominado “grp1”.
WebUI
Objects > Services > Groups: Haga clic en Remove (para grp1).
CLI
unset group service grp1
save
Nota: El dispositivo NetScreen no elimina automáticamente un grupo del que se hayan eliminado todos los
miembros.

Capítulo 5 Bloques para la construcción de directivas Conjuntos de DIP
CONJUNTOS DE DIP
Un conjunto de IPs dinámicas (DIP) es un rango de direcciones IP del cual el dispositivo NetScreen toma
direcciones de forma dinámica o determinista para aplicar la traducción de direcciones de red a la dirección IP de
origen (NAT-src) en los encabezados de paquetes IP. (Para obtener más información sobre la traducción
determinista de direcciones de origen, consulte “NAT-Src desde un conjunto de DIP con desplazamiento de
direcciones” en la pàgina 7 -25). Si el rango de direcciones de un conjunto de DIP pertenece a la misma subred que
la dirección IP de la interfaz, el conjunto debe excluir la dirección IP de la interfaz, las direcciones IP del enrutador y
cualquier dirección IP asignada (MIP) o virtual (VIP) que pueda haber en esa misma subred. Si el rango de
direcciones se encuentra en la subred de una interfaz extendida, el conjunto debe excluir la dirección IP extendida
de la interfaz.
Existen tres clases de interfaces que se pueden enlazar a conjuntos de IPs dinámicas (DIP): interfaces físicas y
subinterfaces para el tráfico de red y VPN, e interfaces de túnel sólo para túneles VPN.
A la zona DMZ Túneles VPN
A la zona Untrust
A la zona Trust
Cortafuegos de NetScreen
10.10.1.2– 210.10.1.2– 220.10.1.2– 10.20.1.2– 10.30.1.2–
10.10.1.20 210.10.1.20 220.10.1.20 10.20.1.20 10.30.1.20
Conjuntos de DIP
ethernet1 ethernet2 ethernet3 Tunnel Tunnel

Interfaces
10.10.1.1/24 210.10.1.1/24 220.10.1.1/24 10.20.1.1/24 10.30.1.1/24
Las interfaces físicas Las interfaces de túnel

conducen a redes o solamente conducen a
túneles VPN. túneles VPN.

Traducción de direcciones de puertos

Utilizando la traducción de direcciones de puertos (“Port Address Translation” o “PAT”), varios hosts pueden
compartir la misma dirección IP, para lo cual el dispositivo NetScreen mantiene una lista de los números de puerto
asignados con el fin de distinguir qué sesión pertenece a qué host. Con PAT habilitada, puede haber hasta ~64.500
hosts compartiendo una misma dirección IP.
Algunas aplicaciones, como la interfaz de usuario extendida para NetBIOS (“NetBIOS Extended User Interface” o
“NetBEUI”) y el servicio de nombres de Internet de Windows (“Windows Internet Naming Service” o “WINS”),
requieren números de puerto específicos y no funcionan correctamente si se les aplica PAT. Se puede especificar
que PAT no se ejecute para tales aplicaciones (es decir, que se utilice un puerto fijo) al aplicar DIP. Para DIP de
puerto fijo, el dispositivo NetScreen guarda en su tabla de “hash” la dirección IP del host original, permitiendo así al
dispositivo NetScreen asociar la sesión correcta a cada host.
Ejemplo: Crear un conjunto de DIP con PAT

En este ejemplo creará un túnel VPN para que los usuarios locales puedan alcanzar un servidor FTP en un sitio
remoto. Sin embargo, las redes internas de ambos sitios utilizan el mismo espacio de direcciones privado
10.1.1.0/24. Para solucionar este problema de solapamiento de direcciones, creará una interfaz de túnel en la zona
Untrust del dispositivo NetScreen local, le asignará la dirección IP 10.10.1.1/24 y le asociará un conjunto de DIP
que contendrá un rango de una sola dirección (10.10.1.2-10.10.1.2) y tendrá habilitada la traducción de direcciones
de puertos.
Los administradores del sitio remoto también deberán crear una interfaz de túnel con una dirección IP en un
espacio de direcciones neutral, tal como 10.20.2.1/24, y configurar una dirección IP asignada (MIP) a su servidor
FTP, como 10.20.2.5 hacia el host 10.1.1.5.
Nota: Este ejemplo incluye solamente la configuración de la interfaz de túnel y del conjunto de DIP que la
acompaña. Por ver un ejemplo completo con todos los pasos de configuración necesarios para este supuesto,
consulte “Sitios VPN con direcciones superpuestas” en la pàgina 5 -203.

WebUI
Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga clic en OK:
Tunnel Interface Name: tunnel.1
Zone (VR): Untrust (trust-vr)
Fixed IP: (seleccione)
IP Address / Netmask: 10.10.1.1/24
Network > Interfaces > Edit (para tunnel.1) > DIP > New: Introduzca los siguientes datos y haga clic en OK:
ID: 510
IP Address Range: 10.10.1.2 ~ 10.10.1.2
CLI
set interface tunnel.1 zone untrust-tun
set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2
save
Nota: Dado que PAT está habilitada de forma predeterminada, no existe ningún argumento para
habilitarla. Para crear el mismo conjunto de DIP según lo definido anteriormente, pero sin PAT (es decir,
con números de puerto fijos), haga lo siguiente:
• (WebUI) Network > Interfaces > Edit (para tunnel.1) > DIP > New: Desactive la casilla de verificación
Port Translation y haga clic en OK.
• (CLI) set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2 fix-port
10. Puede utilizar el número de identificación mostrado, que es el siguiente número correlativo disponible, o bien escribir otro número.

Ejemplo: Modificar un conjunto de DIP

En este ejemplo cambiará el rango de direcciones de un conjunto de DIP existente (ID 5) de 10.20.1.2 – 10.20.1.2 a
10.20.1.2 – 10.20.1.10. Este conjunto está asociado a tunnel.1. Observe que para cambiar el rango del conjunto de
DIP mediante la interfaz de línea de comandos CLI, primero debe eliminar (o desactivar) el conjunto de DIP
existente y crear un nuevo conjunto.
Nota: No hay directivas que utilicen este conjunto de DIP en particular. Para que una directiva utilice un conjunto
de DIP, primero debe eliminar la directiva o modificarla para que no pueda utilizar el conjunto de DIP antes de que
usted lo haya modificado.
WebUI
Network > Interfaces > Edit (para tunnel.1) > DIP > Edit (para ID 5): Introduzca los siguientes datos y haga
clic en OK :
IP Address Range: 10.20.1.2 ~ 10.20.1.10
CLI
unset interface tunnel.1 dip 5
set interface tunnel.1 dip 5 10.20.1.2 10.20.1.10
save
Direcciones DIP “sticky”

Cuando un host inicia varias sesiones que satisfacen las condiciones de una directiva que requiere la traducción de
direcciones de red (NAT) y se le asigna una dirección de un conjunto de DIP con la traducción de puertos
habilitada11, el dispositivo NetScreen asigna una dirección IP de origen distinta a cada sesión. Tal asignación de
direcciones aleatoria puede resultar problemática para los servicios que generan múltiples sesiones que requieren
la misma dirección IP de origen para cada sesión.
11. Para los conjuntos de DIP que no realizan la traducción de puertos, el dispositivo NetScreen asigna una dirección IP a todas las sesiones simultáneas del
mismo host.

Por ejemplo, es importante tener la misma dirección IP para varias sesiones cuando se utiliza el cliente AOL Instant
Messaging (AIM). Creará una sesión durante el inicio de su sesión y otra por cada chat. Para que el servidor AIM
pueda verificar que un nuevo chat pertenece a un usuario autenticado, debe comparar la dirección IP de origen del
inicio de sesión con la dirección de la sesión de chat. Si son diferentes (posiblemente porque hubiesen sido
asignadas aleatoriamente desde un conjunto de DIP durante el proceso NAT), el servidor AIM rechazará la sesión
de chat.
Para garantizar que el dispositivo NetScreen asigna la misma dirección IP de un conjunto de DIP a las diferentes
sesiones simultáneas de un host, puede habilitar la característica “sticky” de la dirección DIP ejecutando el
comando CLI set dip sticky .
Interfaz extendida y DIP

Si las circunstancias requieren que la dirección IP de origen del tráfico saliente por el cortafuegos sea traducida a
una dirección de una subred diferente de la subred en la que se encuentra la interfaz de salida, puede utilizar la
opción extendida de la interfaz. Esta opción permite implantar una segunda dirección IP y un conjunto de DIP
auxiliar en una interfaz de otra subred. Después se puede habilitar NAT sobre una base de directivas y especificar
para la traducción el conjunto de DIP creado en la interfaz extendida.
Ejemplo: Usar DIP en otra subred

En este ejemplo, dos sucursales tienen líneas punto a punto con la sede central. La oficina central les exige utilizar
solamente las direcciones IP autorizadas que les ha asignado. Sin embargo, las oficinas reciben de su proveedor
de servicios (“ISP”) otras direcciones IP para el tráfico de Internet. Para la comunicación con la oficina central,
utilizará la opción de interfaz extendida para configurar el dispositivo NetScreen en cada sucursal de modo que
traduzca la dirección IP de origen a la dirección autorizada en todos los paquetes enviados a la oficina central. Las
direcciones IP autorizadas y asignadas para las sucursales A y B son las siguientes:
Dirección IP asignada Dirección IP autorizada

(por el ISP) (por la oficina central)
Utilizada para la interfaz física de la zona Utilizada para la DIP de interfaz extendida de
Untrust la zona Untrust
Oficina A 195.1.1.1/24 211.10.1.1/24
Oficina B 201.1.1.1/24 211.20.1.1/24

En ambos sitios, los dispositivos NetScreen tienen una zona Trust y una zona Untrust. Todas las zonas de
seguridad se encuentran en el dominio de enrutamiento trust-vr. Enlazará ethernet1 a la zona Trust y le asignará la
dirección IP 10.1.1.1/24. Enlazará ethernet3 a la zona Untrust y le asignará la dirección IP generada por los
correspondientes ISP: 195.1.1.1/24 para la Oficina A y 201.1.1.1/24 para la Oficina B. A continuación, creará una
interfaz extendida con un conjunto de DIP que contendrá la dirección IP autorizada en ethernet3:
• Oficina A: IP de la interfaz extendida 211.10.1.10/24; conjunto de DIP 211.10.1.1 – 211.10.1.1; PAT
habilitada
• Oficina B: IP de la interfaz extendida 211.20.1.10/24; conjunto de DIP 211.20.1.1 – 211.20.1.1; PAT
habilitada

Establecerá la interfaz de la zona Trust en modo NAT. Utilizará la dirección IP de la interfaz de la zona Untrust
como dirección de origen en todo el tráfico saliente, salvo en el tráfico enviado a la sede central. Configurará una
directiva para la sede central que traducirá la dirección de origen a una dirección del conjunto de DIP en la interfaz
extendida. (El número de identificación del conjunto de DIP es 5. Contiene una dirección IP que, mediante la
traducción de direcciones de puertos, permite gestionar las sesiones de unos ~64.500 hosts). La dirección MIP
utilizada por la sede central para el tráfico entrante será 200.1.1.1, que deberá introducir como “HQ” (oficina central)
en la libreta de direcciones de la zona Untrust de cada dispositivo NetScreen.
Nota: Las líneas arrendadas punto a punto

conectan las sucursales A y B directamente
a la sede central. Oficina central
(HQ)
200.1.1.1
Zona Untrust ISP Zona Untrust
Línea
punto a
Línea punto a
punto punto
Zona Untrust, ethernet3 I n t e r n e t Zona Untrust, ethernet3
El ISP asigna 195.1.1.1/24 El ISP asigna 201.1.1.1/24
(interfaz física) (interfaz física)
HQ autoriza 211.10.1.1/24 HQ autoriza 211.20.1.1/24
(interfaz extendida) ISP ISP (interfaz extendida)
Puerta de enlace Puerta de enlace
predeterminada 195.1.1.254 predeterminada 201.1.1.254
Zona Trust, ethernet1 Zona Trust, ethernet1
10.1.1.1/24 Oficina A Oficina B 10.1.1.1/24
Zona Trust Zona Trust
Nota: Para poder utilizar una línea punto a punto, cada ISP debe establecer una ruta para el tráfico destinado al
sitio que se encuentra en el extremo de esa línea. Los ISPs desviarán a Internet cualquier otro tráfico que reciban
de un dispositivo NetScreen local.

WebUI (Sucursal A)
1. Interfaces
Zone Name: Trust
Interface Mode: NAT
Zone Name: Untrust
OK :
ID: 5
IP Address Range: 211.10.1.1 ~ 211.10.1.1
Extended IP/Netmask: 211.10.1.10/255.255.255.0
2. Dirección
Address Name: HQ
Zone: Untrust

3. Ruta
Gateway IP address: 195.1.1.254
4. Directivas
Source Address:
Service: ANY
Action: Permit
Source Address:
Address Book Entry: (seleccione), HQ
Service: ANY
Action: Permit
Position at Top: (seleccione)

NAT:
(DIP on): 5 (211.10.1.1-211.10.1.1)/X-late
WebUI (Sucursal B)
1. Interfaces
Zone Name: Trust
Interface Mode: NAT
Zone Name: Untrust
OK :
ID: 5
IP Address Range: 211.20.1.1 ~ 211.20.1.1
Extended IP/Netmask: 211.20.1.10/255.255.255.0

2. Dirección
Address Name: HQ
Zone: Untrust
3. Ruta
4. Directivas
Source Address:
Service: ANY
Action: Permit

Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK:
Source Address:
Address Book Entry: (seleccione), HQ
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 5 (211.20.1.1-211.20.1.1)/X-late
CLI (Sucursal A)
1. Interfaces

set interface ethernet3 ext ip 211.10.1.10 255.255.255.0 dip 5 211.10.1.1
2. Dirección
set address untrust hq 200.1.1.1/32

3. Ruta
4. Directivas
set policy top from trust to untrust any hq any nat src dip 5 permit
save
CLI (Sucursal B)
1. Interfaces

set interface ethernet3 ext ip 211.20.1.10 255.255.255.0 dip 5 211.20.1.1
2. Dirección
set address untrust hq 200.1.1.1/32
3. Ruta
4. Directivas
set policy top from trust to untrust any hq any nat src dip 5 permit
save

Interfaz de bucle invertido ("loopback") y DIP

Una interfaz de bucle invertido es una interfaz lógica que siempre se encuentra en estado activo mientras el
12
dispositivo en el que reside permanezca encendido . En una interfaz loopback se puede crear un conjunto de
direcciones IP dinámicas (DIP) accesible por el grupo de interfaces perteneciente al grupo asociado de interfaces
loopback al realizar la traducción de direcciones de origen. Las direcciones que el dispositivo NetScreen toma de ese
conjunto de DIP se encuentran en la misma subred que la dirección IP de la interfaz loopback, no en la subred de
ninguna de las interfaces miembro. (Observe que las direcciones del conjunto de DIP no deben solaparse con la
dirección IP de la interfaz ni con ninguna dirección MIP que también se haya definido en la interfaz de bucle invertido.)
La principal aplicación de ubicar un conjunto de DIP en una interfaz loopback es traducir direcciones de origen a la
misma dirección o rango de direcciones aunque diferentes paquetes utilicen diferentes interfaces de salida.
Traducción de direcciones de origen

utilizando un conjunto DIP en una interfaz
loopback
IP de origen IP de destino IP de origen IP de destino
1.3.3.2 2.2.2.2 DATOS 1.3.3.2 2.2.2.2 DATOS
ethernet2 ethernet3
1.1.1.1/24 1.2.2.1/24
Interfaz loopback
Sea cual sea la interfaz de loopback.1 Dispositivo
salida, el dispositivo 1.3.3.1/30 Conjunto de DIP NetScreen
NetScreen traduce las 1.3.3.2 – 1.3.3.2
direcciones IP de origen a la
dirección del conjunto de DIP
definido en la interfaz ethernet1
loopback.1. 10.1.1.1/24
Host A Host B
10.1.1.5 10.1.1.6
IP de origen IP de destino IP de origen IP de destino
10.1.1.5 2.2.2.2 DATOS 10.1.1.6 2.2.2.2 DATOS
12. Para obtener más información sobre interfaces de bucle invertido, consulte “Interfaces loopback” en la pàgina 77.

Ejemplo: DIP en una interfaz loopback

En este ejemplo, el dispositivo NetScreen recibe las direcciones IP siguientes de dos interfaces de la zona Untrust
desde diferentes proveedores de servicios de Internet (ISPs): ISP-1 e ISP-2:
• ethernet2, 1.1.1.1/24, ISP-1
• ethernet3, 1.2.2.1/24, ISP-2
Asociará estas interfaces a la zona Untrust y después les asignará las direcciones IP indicadas anteriormente.
También asociará ethernet1 a la zona Trust y le asignará la dirección IP 10.1.1.1/24.
Desea que el dispositivo NetScreen traduzca la dirección de origen del tráfico saliente de la zona Trust a una oficina
remota en la zona Untrust. La dirección traducida debe ser la misma dirección IP (1.3.3.2), porque la oficina remota
tiene una directiva que permite el tráfico entrante solamente de esa dirección IP. Previamente habrá obtenido las
direcciones IP públicas 1.3.3.1 y 1.3.3.2 y habrá notificado a ambos ISPs que estará utilizando estas direcciones
además de las direcciones que ellos asignen al dispositivo.
Configurará una interfaz loopback.1 con la dirección IP 1.3.3.1/30 y un conjunto de DIP de 1.3.3.2 – 1.3.3.2 en esa
interfaz. El conjunto de DIP tendrá la identificación número 10. Después hará a ethernet1 y ethernet2 miembros del
grupo loopback correspondiente a loopback.1.
Definirá una dirección “r-office” con la dirección IP 2.2.2.2/32 para la oficina remota. También definirá rutas
predeterminadas para las interfaces ethernet1 y ethernet2, que apuntarán a los enrutadores de los proveedores
“ISP-1” e “ISP-2”, respectivamente.
Definirá rutas a dos puertas de enlace para que el tráfico saliente las utilice. Dado que no tiene ninguna preferencia
por una ruta u otra, no incluirá ninguna métrica en ninguna de ellas. El tráfico saliente podrá seguir cualquier ruta13.
Por último, creará una directiva que aplicará la traducción de direcciones de red de origen (NAT-src) al tráfico
saliente hacia la oficina remota. La directiva hará referencia al conjunto de DIP con la identificación 10.
13. Para indicar una ruta preferente, incluya métricas en ambas rutas y asigne a su ruta preferida una métrica más alta, es decir, un valor más cercano a 1.

r-office
IP de origen IP de destino 2.2.2.2
1.3.3.2 2.2.2.2 DATOS
ISP -1 Zona ISP -2

Untrust
ethernet2, 1.1.1.1/24 ethernet3, 1.2.2.1/24

El dispositivo puerta de enlace puerta de enlace
NetScreen traducirá 1.1.1.250 1.2.2.250
todas las direcciones Conjunto de DIP
IP de origen de los con ID 10
paquetes destinados (en Loopback.1)
a 2.2.2.2 de 10.1.1.X 1.3.3.2 – 1.3.3.2
ethernet1, 10.1.1.1/24 Loopback.1
a 1.3.3.2, Modo NAT
independientemente Zona Untrust
de la interfaz de 1.3.3.1/30
salida utilizada. Zona
10.1.1.0/24 Trust
IP de origen IP de destino
10.1.1.X 2.2.2.2 DATOS
WebUI
1. Interfaces
Zone: Untrust (trust-vr)
As member of loopback group: loopback.1
Zone Name: Trust

Interface Mode: NAT

As member of loopback group: loopback.1
Zone Name: Untrust
Zone Name: Untrust
2. Conjunto de DIP
Network > Interfaces > Edit (para loopback.1) > DIP > New: Introduzca los siguientes datos y haga clic
en OK :
ID: 5
IP Address Range: 1.3.3.2 ~ 1.3.3.2
3. Dirección
Address Name: r-office
Zone: Untrust

4. Rutas
5. Directiva
Source Address:
Address Book Entry: (seleccione), r-office
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 10 (1.3.3.2-1.3.3.2)/port-xlate

CLI
1. Interfaces
set interface loopback.1 ip 1.3.3.1/30



2. Conjunto de DIP
set interface loopback.1 dip 10 1.3.3.2 1.3.3.2
3. Dirección
set address untrust r-office 2.2.2.2/32
4. Rutas
5. Directiva
set policy from trust to untrust any r-office any nat src dip-id 10 permit
save

Grupos de DIP
Cuando se agrupan dos dispositivos NetScreen en un clúster redundante para proporcionar alta disponibilidad
(“high availability” o “HA”) en una configuración activa/activa, ambos dispositivos comparten la misma configuración
y ambos procesan el tráfico simultáneamente. Puede presentarse un problema al definir una directiva para realizar
la traducción de direcciones de red (NAT) si se utiliza un conjunto de DIP situado en una interfaz de seguridad
virtual (“Virtual Security Interface” o “VSI”). Debido a que esa VSI solamente está activa en el dispositivo NetScreen
que actúa como maestro (“master”) del grupo VSD al que está asociada, ningún tráfico enviado al otro dispositivo
NetScreen (el que actúa como respaldo de dicho grupo VSD) puede utilizar ese conjunto de DIP y se descarta.
Utilización problemática de un conjunto de DIP en una directiva en un clúster NSRP:
set policy name out-nat from trust to untrust any any any nat src dip-id 7 permit
Zona Untrust
VSIs de la zona ethernet2 ethernet3:1

Untrust 1.1.1.1/24 1.1.1.2/24 Conjunto de DIP con ID 7
1.1.1.101 – 1.1.1.150
VSD maestro 0 Dispositivo VSD de respaldo 1

A
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de respaldo 0 Dispositivo VSD maestro 1

B
ethernet1 ethernet1:1
VSIs de la zona Trust 10.1.1.1/24 10.1.1.2/24
Debido a que el conjunto de DIP se encuentra en la VSI

de la zona Untrust del grupo VSD 1 (cuyo maestro es
el Dispositivo B), el Dispositivo A (respaldo del grupo Zona Trust
VSD 1) descarta el tráfico recibido en ethernet1
(10.1.1.1/24) que cumple la directiva “out-nat”.

Para solucionar este problema, cree dos conjuntos de DIP (uno en la VSI de la zona Untrust por cada grupo VSD) y
combine ambos conjuntos de DIP en un grupo de DIP, al que luego hará referencia en la directiva. Cada VSI utiliza
su propio conjunto de VSD incluso aunque en la directiva se especifique el grupo de DIP.
Utilización recomendada de un grupo de DIP en una directiva cuando se encuentra en un clúster NSRP:
set policy name out-nat from trust to untrust any any any nat dip-id 9 permit
Conjunto de DIP con ID 8 Conjunto de DIP con ID 7

1.1.1.151 – 210.1.1.200 Zona Untrust 1.1.1.101 – 1.1.1.150
VSIs de la zona ethernet3 ethernet3:1

Untrust 1.1.1.1/24 1.1.1.2/24
Grupo de DIP 9
VSD maestro 0 Dispositivo A VSD de respaldo 1
Clúster NSRP Grupo VSD: 0 Grupo VSD: 1
VSD de respaldo 0 VSD maestro 1

Dispositivo B
ethernet1 ethernet1:1
VSIs de la zona Trust 10.1.1.1/24 10.1.1.2/24
Combinando los conjuntos de DIP situados en ambas
VSIs de la zona Untrust (para los grupos VSD 0 y 1) en un
grupo de DIP, ambos Dispositivos A y B pueden procesar
el tráfico que cumpla la directiva “out-nat”, en la que no se Zona Trust
hace referencia a un conjunto de DIP específico de
interfaz, sino al grupo de DIP compartido.
Nota: Para obtener más información sobre la configuración de dispositivos NetScreen para HA, consulte el

Ejemplo: Grupo de DIP

En este ejemplo proporcionará servicios NAT en dos dispositivos NetScreen (Dispositivos A y B) en un par HA
activo/activo.
Creará dos conjuntos de DIP, DIP 5 (1.1.1.20 – 1.1.1.29) en ethernet3 y DIP 6 (1.1.1.30 – 1.1.1.39) en ethernet3:1.
Después los combinará en un grupo de DIP identificado como DIP 7, al que hará referencia en una directiva.
Las VSIs de los grupos VSD 0 y 1 son:
• VSI de la zona Untrust ethernet3 1.1.1.1/24 (grupo VSD 0)
• VSI de la zona Untrust ethernet3:1 1.1.1.2/24 (grupo VSD 1)
• VSI de la zona Trust ethernet1 10.1.1.1/24 (grupo VSD 0)
• VSI de la zona Trust ethernet1:1 10.1.1.1/24 (grupo VSD 1)
Este ejemplo asume que previamente habrá configurado los Dispositivos A y B en un clúster NSRP, creado el grupo
VSD 1 (NetScreen crea automáticamente el grupo VSD 0 cuando se coloca un dispositivo en un clúster NSRP), y
configurado las interfaces mencionadas. (Para obtener más información sobre la configuración de dispositivos
NetScreen para NSRP, consulte el Volumen 10, “Alta disponibilidad”).
WebUI
1. Conjuntos de DIP
Network > Interfaces > Edit (para ethernet3) > DIP > New: Introduzca los siguientes datos y haga clic
en OK :
ID: 5
IP Address Range: 1.1.1.20 – 1.1.1.29
Network > Interfaces > Edit (para ethernet3:1) > DIP > New: Introduzca los siguientes datos y haga clic
en OK :
ID: 6
IP Address Range: 1.1.1.30 – 1.1.1.39
Nota: En el momento de publicar esta versión, con CLI solamente se puede definir un grupo de DIP.

2. Directiva
Source Address:
Service: ANY
Action: Permit
NAT:
DIP On: (seleccione), 7
CLI
1. Conjuntos de DIP
set interface ethernet3 dip 5 1.1.1.20 1.1.1.29
set interface ethernet3:1 dip 6 1.1.1.30 1.1.1.39
2. Grupos de DIP
set dip group 7 member 5
set dip group 7 member 6
3. Directiva
set policy from trust to untrust any any any nat src dip-id 7 permit
save

Capítulo 5 Bloques para la construcción de directivas Tareas programadas
TAREAS PROGRAMADAS
Una tarea programada es un objeto configurable que se puede asociar a una o varias directivas para definir cuándo
deben entrar en vigor. Las tareas programadas permiten controlar el flujo de tráfico en la red y hacer cumplir las
normas de seguridad de la red.
Para definir una tarea programada, introduzca los valores de los parámetros siguientes:
Schedule Name: El nombre que aparece en la lista desplegable “Schedule” del cuadro de diálogo “Policy
Configuration”. Elija un nombre descriptivo que le permita identificar la tarea programada. El nombre debe
ser exclusivo y está limitado a 19 caracteres.
Comment: Cualquier información adicional que desee agregar.
Recurring: Habilite esta opción cuando desee que el programa se repita con una periodicidad semanal.
Start and End Times: Debe configurar tanto la hora de comienzo como de fin. Puede especificar
hasta dos periodos de un mismo día.
Once: Habilite esta opción cuando desee que la tarea programada se ejecute y termine una sola vez.
mm/dd/aaaa hh:mm: Debe introducir tanto la fecha y hora de inicio como la de fin.
Ejemplo: Tarea programada repetitiva

En este ejemplo hay un empleado a tiempo parcial llamado Tom que utiliza el acceso a Internet de la empresa para
asuntos personales después del trabajo. Usted creará una tarea programada para el horario no comercial que
asociará a una directiva para denegar el tráfico TCP/IP saliente generado por el equipo de ese trabajador
(10.1.1.5/32) fuera del horario de oficina normal.
WebUI
1. Tarea programada
Objects > Schedules > New: Introduzca los siguientes datos y haga clic en OK :
Schedule Name: After hours
Comment: For non-business hours
Recurring: (seleccione)

Periodo 1:
Día de la Hora Hora final

semana comienzo
Domingo 00:00 23:59
Lunes 00:00 06:00
Martes 00:00 06:00
Miércoles 00:00 06:00
Jueves 00:00 06:00
Viernes 00:00 06:00
Sábado 00:00 23:59
Periodo 2:
Día de la Hora Hora final

semana comienzo
Domingo 17:00 23:59
Lunes 17:00 23:59
Martes 17:00 23:59
Miércoles 17:00 23:59
Jueves 17:00 23:59
Viernes 17:00 23:59
Sábado 17:00 23:59

2. Dirección
Address Name: Tom
Comment: Temp
Zone: Trust
3. Directiva
Name: No Net
Source Address:
Address Book Entry: (seleccione), Tom
Service: HTTP
Action: Deny
Schedule: After hours

CLI
1. Tarea programada
set schedule “after hours” recurrent sunday start 00:00 stop 23:59
set schedule “after hours” recurrent monday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent tuesday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent wednesday start 00:00 stop 06:00 start
17:00 stop 23:59
set schedule “after hours” recurrent thursday start 00:00 stop 06:00 start
17:00 stop 23:59
set schedule “after hours” recurrent friday start 00:00 stop 06:00 start 17:00
stop 23:59
set schedule “after hours” recurrent saturday start 00:00 stop 23:59 comment
“for non-business hours”
2. Dirección
set address trust tom 10.1.1.5/32 “temp”
3. Directiva
set policy from trust to untrust tom any http deny schedule “after hours”
save

Capítulo 6
Directivas
6
El comportamiento predeterminado de un dispositivo NetScreen es rechazar todo el tráfico entre zonas de
seguridad (tráfico interzonal)1 y, a excepción del tráfico dentro de la zona Untrust, permitir todo el tráfico entre
interfaces asociadas a una misma zona (tráfico intrazonal). Para permitir que determinado tráfico interzonal pase
por un dispositivo NetScreen, debe crear directivas interzonales que tengan preferencia sobre el comportamiento
predeterminado. De forma análoga, para impedir que determinado tráfico intrazonal pueda pasar por un dispositivo
NetScreen, debe crear las correspondientes directivas intrazonales.
En este capítulo se describe en qué consisten las directivas y cómo se relacionan entre sí los diversos elementos
que componen una directiva. Está dividido en las secciones siguientes:
• “Elementos básicos” en la pàgina 307
• “Tres tipos de directivas” en la pàgina 308
– “Directivas interzonales” en la pàgina 308
– “Directivas intrazonales” en la pàgina 309
– “Directivas globales” en la pàgina 310
• “Listas de conjuntos de directivas” en la pàgina 311
• “Definición de directivas” en la pàgina 312
– “Directivas y reglas” en la pàgina 312
– “Anatomía de una directiva” en la pàgina 314
• “Directivas aplicadas” en la pàgina 329
– “Visualización de directivas” en la pàgina 329
– “Creación de directivas” en la pàgina 331
– “Introducción del contexto de una directiva” en la pàgina 348
1. De forma predeterminada, los dispositivos NetScreen-5XP y NetScreen-5XT permiten el tráfico desde la zona Trust a la zona Untrust.

Capítulo 6 Directivas
– “Varios elementos por componente de directiva” en la pàgina 349

– “Negación de direcciones” en la pàgina 351
– “Modificación y desactivación de directivas” en la pàgina 355
– “Verificación de directivas” en la pàgina 356
– “Reordenamiento de directivas” en la pàgina 357
– “Eliminación de una directiva” en la pàgina 358
Nota: Si configura el enrutamiento multicast en un dispositivo NetScreen, puede que tenga que configurar
directivas multicast. Para obtener información sobre directivas multicast, consulte “Directivas multicast” en la
pàgina 6 -208.

Capítulo 6 Directivas Elementos básicos
ELEMENTOS BÁSICOS
2
Una directiva permite, deniega o canaliza por un túnel los tipos de tráfico especificados de forma unidireccional
entre dos puntos. El tipo de tráfico (o “servicio”), la ubicación de los dos puntos finales y la acción invocada
componen los elementos básicos de una directiva. Aunque puede haber otros componentes, los elementos
requeridos, que juntos constituyen el núcleo de una directiva, son los siguientes:
• Direction (Sentido): La dirección del tráfico entre dos zonas de seguridad (desde una zona de origen a una
zona de destino)
• Source address (Dirección de origen): La dirección desde la que se inicia el tráfico
• Destination address (Dirección de destino): La dirección a la que se envía el tráfico
• Service (Servicio): El tipo de tráfico transmitido
• Action (Acción): La acción realizada por el dispositivo NetScreen cuando recibe tráfico que cumple los
cuatro primeros criterios: deny (denegar), permit (permitir), reject (rechazar) o tunnel (tunelizar)
Por ejemplo, la directiva indicada en el comando CLI siguiente permite el tráfico FTP desde cualquier dirección de la
zona Trust a un servidor FTP llamado “server1” en la zona DMZ:
set policy from trust to untrust any server1 ftp permit
• Direction (Sentido): from trust to untrust (es decir, de la zona Trust a la zona Untrust)
• Source address (Dirección de origen): any (es decir, cualquier dirección en la zona Trust. El término “any”
significa una dirección predefinida aplicable a cualquier dirección de una zona)
• Destination address (Dirección de destino): server1 (una dirección definida por el usuario en la libreta de
direcciones de la zona Untrust)
• Service (Servicio): ftp (protocolo de tranferencia de archivos o “File Transfer Protocol”)
• Service (Servicio): El tipo de tráfico transmitido
• Action (Acción): permit (el dispositivo NetScreen permite a este tráfico atravesar su cortafuegos)
2. La acción “tunnel” (túnel VPN o L2TP) contiene implícitamente el concepto “permit” .

Capítulo 6 Directivas Tres tipos de directivas
TRES TIPOS DE DIRECTIVAS

Puede controlar el flujo de tráfico mediante las tres clases de directivas siguientes:
• Mediante la creación de directivas interzonales puede regular el tipo de tráfico que desee permitir desde
una zona de seguridad a otra.
• Mediante directivas intrazonales también puede controlar el tipo de tráfico al que desea permitir cruzar
interfaces asociadas a la misma zona.
• Creando directivas globales puede regular el tráfico entre direcciones, sin importar sus zonas de seguridad.
Directivas interzonales
Las directivas interzonales permiten controlar el tráfico entre zonas de seguridad. Puede establecer directivas
interzonales para denegar, permitir, rechazar o tunelizar el tráfico desde una zona a otra. Aplicando técnicas de
inspección de estado, un dispositivo NetScreen mantiene una tabla de sesiones TCP activas y de “pseudosesiones”
UDP activas para poder permitir respuestas a las peticiones de servicio. Por ejemplo, si tiene una directiva que
permite enviar peticiones HTTP del host A de la zona Trust al servidor B de la zona Untrust, cuando el dispositivo
NetScreen recibe respuestas HTTP del servidor B para el host A, el dispositivo NetScreen comprueba el paquete
recibido con el contenido de su tabla. Si detecta que el paquete es una respuesta a una petición HTTP aprobada, el
dispositivo NetScreen permite al paquete del servidor B de la zona Untrust cruzar el cortafuegos hacia host A en la
zona Trust. Para permitir el tráfico iniciado por el servidor B hacia el host A (no sólo respuestas al tráfico iniciado por
el host A), debe crear una segunda directiva del servidor B en la zona Untrust al host A en la zona Trust.
set policy from trust to untrust “host A” “servidor B” http permit
Host A Servidor B
Zona Trust Dispositivo NetScreen Zona Untrust
Petición HTTP
Respuesta HTTP
Petición HTTP
Nota: El dispositivo NetScreen deniega la petición HTTP

del servidor B porque no hay ninguna directiva que lo permita.

Directivas intrazonales
Las directivas intrazonales permiten controlar el tráfico entre interfaces asociadas a la misma zona de seguridad.
Las direcciones de origen y de destino se encuentran en la misma zona de seguridad, pero llegaron al dispositivo
NetScreen a través de diferentes interfaces del dispositivo NetScreen. Igual que las directivas interzonales, las
directivas intrazonales controlan el tráfico que fluye unidireccionalmente. Para permitir el tráfico iniciado en
cualquier extremo de una ruta de datos, debe crear dos directivas, una para cada sentido.
set policy from trust to trust “host A” “servidor B” any permit ethernet1 ethernet4
set policy from trust to trust “servidor B” “host A” any permit 10.1.1.1/24 10.1.2.1/24
Conmutadores de
capa 2
Host A LAN 1 Servidor B
LAN 2
10.1.1.5 10.1.1.0/24 10.1.2.30
10.1.2.0/24
Zona Trust
Las directivas intrazonales no admiten túneles VPN ni la traducción de direcciones de la red de origen (NAT-src) a
nivel de interfaz ( set interface interface nat ). Sin embargo, las directivas intrazonales admiten NAT-src y NAT-dst
basada en directivas. También admiten la traducción de direcciones de destino cuando la directiva hace referencia
a una dirección IP asignada (MIP) como dirección de destino. (Para obtener información sobre NAT-src, NAT-dst y
MIPs, consulte el Volumen 7, “Traducción de direcciones”.)

Directivas globales
A diferencia de las directivas interzonales e intrazonales, las directivas globales no hacen referencia a zonas de
origen y de destino específicas. Las directivas globales hacen referencia a direcciones de la zona Global definidas
por el usuario o a la dirección “any” de la zona predefinida Global. Estas direcciones pueden pasar por varias zonas
de seguridad. Por ejemplo, si desea proporcionar acceso hacia o desde varias zonas, puede crear una directiva
global con la dirección “any” de la zona Global, que abarca todas las direcciones de todas las zonas.
Nota: En el momento de publicar esta versión, las directivas globales no admiten la traducción de direcciones de
red de origen (NAT-src), túneles VPN ni el modo transparente. Puede, sin embargo, especificar una MIP o VIP
como dirección de destino en una directiva global.

Capítulo 6 Directivas Listas de conjuntos de directivas
LISTAS DE CONJUNTOS DE DIRECTIVAS

Un dispositivo NetScreen mantiene tres diferentes listas de conjuntos de directivas, una por cada una de las
siguientes clases de directivas:
• Directivas interzonales
• Directivas intrazonales
• Directivas globales
Cuando el dispositivo NetScreen recibe un paquete de inicio de una nueva sesión, detecta la interfaz de entrada y
averigua a qué zona de origen está asociada esa interfaz. A continuación, el dispositivo NetScreen realiza una
consulta de rutas para determinar la interfaz de salida y determina a qué zona de destino está asociada esa
interfaz. Utilizando las zonas de origen y de destino, el dispositivo NetScreen puede realizar una consulta de
directivas, consultando las listas de conjuntos de directivas en el orden siguiente:
1. Si las zonas de origen y de destino son diferentes, el dispositivo NetScreen realiza una consulta de
directivas en la lista de conjuntos de directivas interzonales.
(o bien)
Si las zonas de origen y de destino son iguales, el dispositivo NetScreen realiza una consulta de directivas
en la lista de conjuntos de directivas intrazonales.
2. Si el dispositivo NetScreen realiza la consulta de directivas interzonal o intrazonal y no encuentra
coincidencias, consulta la lista de conjuntos de directivas globales.
3. Si el dispositivo NetScreen realiza las consultas de directivas interzonales y globales y no encuentra
coincidencias, aplica al paquete la directiva permitir/denegar predeterminada: unset/set policy
default-permit-all .
(o bien)
Si el dispositivo NetScreen realiza las consultas de directivas intrazonales y globales y no encuentra
coincidencias, aplica al paquete el ajuste de bloqueo intrazonal de esa zona: unset/set zone zone block .
El dispositivo NetScreen consulta cada lista de conjuntos de directivas de arriba abajo. Por lo tanto, las directivas
más específicas deben ubicarse en la lista por encima de las menos específicas. (Para obtener más información
sobre el orden de directivas, consulte “Reordenamiento de directivas” en la pàgina 357).

Capítulo 6 Directivas Definición de directivas
DEFINICIÓN DE DIRECTIVAS
Un cortafuegos representa el límite de una red con un solo punto de entrada y de salida. Como todo el tráfico debe
pasar a través de este punto, puede supervisarlo y dirigirlo implementando listas de conjuntos de directivas (para
directivas interzonales, directivas intrazonales y directivas globales).
Las directivas permiten denegar, permitir, rechazar (denegar y enviar un mensaje de puerto inalcanzable TCP RST
o ICMP al host de origen), encriptar y desencriptar, autenticar, priorizar, programar, filtrar y supervisar el tráfico que
intente pasar de una zona de seguridad a otra. Usted decide qué usuarios y qué datos pueden entrar y salir, así
como cuándo y a dónde pueden ir.
Nota: Para los dispositivos NetScreen que admiten sistemas virtuales, las directivas establecidas en el sistema
raíz no afectan a las directivas establecidas en sistemas virtuales.
Directivas y reglas
Una sola directiva definida por el usuario produce internamente una o más reglas lógicas, y cada regla lógica consta
de un conjunto de componentes: la dirección de origen, la dirección de destino y el servicio. Los componentes
consumen recursos de memoria. Las reglas lógicas que se refieren a los componentes no.
Dependiendo de si en una directiva se utilizan múltiples entradas o grupos para la dirección de origen, la dirección
de destino y los componentes del servicio, el número de reglas lógicas puede ser mucho mayor de lo que puede
parecer al crear la directiva única. Por ejemplo, la directiva siguiente produce 125 reglas lógicas:
1 directiva: 5 direcciones de origen x 5 direcciones de destino x 5 servicios = 125 reglas lógicas
Sin embargo, el dispositivo NetScreen no duplica componentes para cada regla lógica. Las reglas utilizan el mismo
conjunto de componentes en diferentes combinaciones. Por ejemplo, la directiva antedicha que produce 125 reglas
lógicas solamente contiene 15 componentes:
5 direcciones de origen + 5 direcciones de destino + 5 servicios = 15 componentes
Estos 15 componentes se combinan de varias maneras para producir las 125 reglas lógicas generadas por la
directiva única. Permitiendo que múltiples reglas lógicas utilicen el mismo conjunto de componentes en diferentes
combinaciones, el dispositivo NetScreen consume muchos menos recursos que si cada regla lógica tuviera una
relación “uno a uno” con sus componentes.

Dado que el tiempo de instalación de una nueva directiva es proporcional al número de componentes que el
dispositivo NetScreen agrega, elimina o modifica, la instalación de directivas es más rápida cuantos menos
componentes haya. Asimismo, al permitir que un gran número de reglas lógicas comparta un pequeño conjunto de
componentes, NetScreen permite crear más directivas (y el dispositivo NetScreen permite crear más reglas), que lo
que sería posible si cada regla requiriese componentes dedicados.

Anatomía de una directiva

Una directiva debe contener los elementos siguientes:
• ID (generada automáticamente, aunque puede ser definida por el usuario mediante CLI)
• Zonas (de origen y de destino)
• Direcciones (de origen y de destino)
• Servicios
• Acción (permit (permitir), deny (denegar), reject (rechazar), tunnel (tunelizar)
Una directiva también puede contener los elementos siguientes:
• Aplicación
• Nombre
• Tunelización VPN
• Tunelización L2TP
• Deep Inspection
• Colocación al principio de la lista de directivas
• Traducción de direcciones de origen
• Traducción de direcciones de destino
• Autenticación de usuarios
• Copia de seguridad de la sesión HA
• Filtrado de URL
• Registro
• Recuento
• Umbral de alarma de tráfico
• Tareas programadas
• Análisis antivirus
• Asignación de tráfico
El resto de esta sección examina cada uno de los elementos antedichos.

ID
Cada directiva tiene un número de identificación, tanto si el usuario define uno como si el dispositivo NetScreen lo
asigna automáticamente. Solamente se puede definir un número de identificación para una directiva ejecutando el
comando “set policy” de CLI: set policy id number … Una vez conocido el número de identificación, puede entrar
en el contexto de la directiva para ejecutar otros comandos con el fin de modificarla. (Para obtener más información
sobre contextos de directivas, consulte “Introducción del contexto de una directiva” en la pàgina 348).
Zonas
Una zona puede ser un segmento del espacio de red al que se aplican medidas de seguridad (zona de seguridad),
un segmento lógico que tiene asociada una interfaz de túnel VPN (zona de túnel), o una entidad física o lógica que
realiza una función específica (zona de función). Una directiva permite que el tráfico fluya entre dos zonas de
seguridad (directiva interzonal) o entre dos interfaces asociadas a la misma zona (directiva intrazonal). (Para
obtener más información, consulte “Zonas” en la pàgina 31, “Directivas interzonales” en la pàgina 308 y “Directivas
intrazonales” en la pàgina 309).
Direcciones
Las direcciones son objetos que identifican dispositivos de red tales como hosts y redes por su ubicación en
relación al cortafuegos (en una de las zonas de seguridad). Los hosts individuales se especifican utilizando la
máscara 255.255.255.255, que indica que los 32 bits de la dirección son significativos. Las redes se especifican
utilizando su máscara de subred para indicar qué bits son significativos. Para crear una directiva para direcciones
específicas, primero debe crear entradas para los hosts y redes correspondientes en la libreta de direcciones.
También puede crear grupos de direcciones y aplicarles directivas como haría con otras entradas en la libreta de
direcciones. Cuando utilice grupos de direcciones como elementos de directivas, tenga presente que, debido a que
el dispositivo NetScreen aplica la directiva a cada dirección en el grupo, el número disponible de reglas lógicas
internas y de componentes que componen esas reglas se puede agotar más rápidamente de lo esperado. Esto
supone un peligro, especialmente cuando se utilizan grupos de direcciones tanto para el origen como para el
destino. (Para obtener más información, consulte “Directivas y reglas” en la pàgina 312).

Servicios
Los servicios son objetos que identifican los protocolos de aplicación usando información de la capa 4, como los
números de puerto TCP y UDP estándar y universalmente aceptados para los servicios de aplicaciones como
Telnet, FTP, SMTP y HTTP. ScreenOS incluye servicios básicos de Internet predefinidos. También se pueden
definir servicios personalizados.
Puede definir directivas que especifiquen qué servicios deben permitirse, denegarse, encriptarse, autenticarse,
registrarse o contabilizarse.

Acción
Una acción es un objeto que describe el tratamiento que el cortafuegos debe dar al tráfico que recibe.
• Deny bloquea el paquete y le impide atravesar el cortafuegos.
• Permit permite que el paquete atraviese el cortafuegos.
• Reject bloquea el paquete y le impide atravesar el cortafuegos. El dispositivo NetScreen descarta el
3
paquete y envía un segmento de restablecimiento (RST) de TCP al host de origen para el tráfico TCP y un
mensaje de “destino inalcanzable, puerto inalcanzable” ICMP (tipo 3, código 3) para el tráfico UDP. Para los
tipos de tráfico distintos de TCP y UDP, el dispositivo NetScreen descarta el paquete sin notificar al host de
origen, lo cual también ocurre cuando la acción es “deny”.
Nota: Cuando la interfaz de entrada está operando en la capa 2 o 3 y el protocolo es TCP, la dirección IP
de origen en el TCP RST es la dirección IP de destino en el paquete original (descartado). Cuando la
interfaz de entrada está operando en la capa 2 y el protocolo es UDP, la dirección IP de origen en el
mensaje ICMP coincide con la dirección IP de destino en el paquete original. Sin embargo, si la interfaz de
entrada está operando en la capa 3 y el protocolo es UDP, la dirección IP de origen en el mensaje ICMP es
la de la interfaz de entrada.
• Tunnel encapsula los paquetes IP salientes y desencapsula los entrantes. Para un túnel VPN IPSec,
especifique qué túnel VPN utilizar. Para un túnel L2TP, especifique qué túnel L2TP debe utilizarse. Para
L2TP sobre IPSec (“L2TP-over-IPSec”), especifique un túnel VPN de IPSec y un túnel L2TP4.
El dispositivo NetScreen aplica la acción especificada al tráfico que cumple los criterios presentados anteriormente:
zonas (origen y destino), direcciones (origen y destino) y servicio.
3. El dispositivo NetScreen envía un TCP RST después de recibir (y descartar) un segmento TCP con cualquier bit de código activado que no sea RST.
4. Para L2TP sobre IPSec, las direcciones de origen y de destino del túnel VPN IPSec deben ser iguales que las del túnel L2TP.

Aplicación
La opción de la aplicación especifica la aplicación de la capa 7 que apunta al servicio de capa 4 al que se hace
referencia en una directiva. Los servicios predefinidos ya disponen de una asignación a una aplicación de capa 7.
Sin embargo, para los servicios personalizados es necesario vincular explícitamente el servicio a una aplicación,
5
especialmente si se desea que la directiva aplique una puerta de enlace de la capa de aplicación (ALG ) o Deep
Inspection al servicio personalizado.
La aplicación de un ALG a un servicio personalizado implica los dos pasos siguientes:
• Definir un servicio personalizado con un nombre, un tiempo de espera, un protocolo de transporte y los
puertos de origen y de destino.
• Al configurar una directiva, hacer referencia a ese servicio y al tipo de aplicación para el ALG que se desea
aplicar.
Para obtener más información sobre cómo aplicar Deep Inspection a un servicio personalizado, consulte
“Asignación de servicios personalizados a aplicaciones” en la pàgina 4 -179.
Nombre
Puede dar a una directiva un nombre descriptivo para permitir identificar fácilmente su finalidad.
nombres creados para las directivas), consulte “Convenciones de nomenclatura y conjuntos de caracteres” en la
pàgina xiv.
5. NetScreen admite ALGs para numerosos servicios, a saber: DNS, FTP, H.323, HTTP, RSH, SIP, Telnet y TFTP.

Tunelización VPN
Puede aplicar una sola o varias directivas a cualquier túnel VPN que tenga configurado. En WebUI, la opción “VPN
Tunnel” abre una lista desplegable de todos esos túneles. En CLI puede consultar todos los túneles disponibles
ejecutando el comando get vpn . (Para obtener más información, consulte “VPNs punto a punto” en la
pàgina 5 -103 y “VPNs de acceso telefónico” en la pàgina 5 -233).
Cuando las configuraciones VPN de ambos extremos de un túnel VPN utilizan NAT basada en directivas, los
administradores de ambos dispositivos de puerta de enlace necesitan crear una directiva de tráfico saliente y otra
de tráfico entrante (cuatro directivas en total). Cuando las directivas de VPN constituyen un par coincidente (es
decir, las configuraciones de las directivas de tráfico entrante y de tráfico saliente son iguales, salvo que las
direcciones de origen y de destino están invertidas), puede configurar una directiva y seleccionar la casilla de
verificación Modify matching bidirectional VPN policy para crear automáticamente una segunda directiva para el
sentido opuesto. Para la configuración de una nueva directiva, la casilla de verificación “Matching VPN Policy” está
desactivada de forma predeterminada. Para la modificación de una directiva existente que sea un miembro de un
par coincidente, la casilla de verificación está activada de forma predeterminada, y cualquier cambio realizado en
una directiva se propagará a la otra.
Nota: Esta opción solamente está disponible a través de WebUI. No puede haber múltiples entradas para ninguno
de los componentes de directiva siguientes: dirección de origen, dirección de destino o servicio.
Tunelización L2TP
Puede aplicar una sola directiva o varias a cualquier túnel del protocolo (L2TP) que haya configurado. En WebUI, la
opción de L2TP proporciona una lista desplegable de todos esos túneles. En la interfaz CLI, puede visualizar el
estado de los túneles L2TP activos mediante el comando get l2tp tunn_str active y ver todos los túneles
disponibles mediante el comando get l2tp all . También puede combinar un túnel VPN con un túnel L2TP (si ambos
tienen el mismo punto final) para crear un túnel que combine las características de cada uno. Esto se llama
“L2TP-over-IPSec” (L2TP sobre IPSec).
Nota: Un dispositivo NetScreen en modo transparente no admite L2TP.

Deep Inspection
Deep Inspection es un mecanismo para filtrar el tráfico permitido en las capas Network y Transport, examinando no
solamente estas capas, sino las características de contenido y protocolo en la capa de aplicación6. El objetivo de
Deep Inspection es detectar y prevenir cualquier ataque o comportamiento anómalo que pudiera existir en el tráfico
permitido por el cortafuegos NetScreen.
Para configurar una directiva para la protección frente a ataques, debe elegir dos opciones: qué grupo (o grupos) de
ataque utilizar y qué acción tomar si se detecta un ataque. (Para obtener más información, consulte “Deep
Inspection” en la pàgina 4 -135).
Colocación al principio de la lista de directivas

De forma predeterminada, NetScreen coloca las directivas recién creadas al final de la lista de conjuntos de
directivas. Si necesita cambiar la posición de la directiva, puede utilizar cualquiera de los métodos de reordenación
de directivas explicados en “Reordenamiento de directivas” en la pàgina 357. Para evitar el paso adicional de
cambiar la posición de una directiva recién creada en la parte superior de una lista de conjuntos de directivas,
puede seleccionar la opción Position at Top de WebUI, o bien utilizar la palabra clave top en el comando
set policy ( set policy top … ) de CLI.
6. En el modelo OSI (“Open Systems Interconnection ”), la capa “Network” es la 3 (“Layer 3”), la capa “Transport” es la 4 y la capa “Application” es la 7. El
modelo OSI es un modelo estándar en el sector de redes de una arquitectura de protocolos de red. El modelo OSI se compone de siete capas.

Traducción de direcciones de origen

Puede aplicar la traducción de direcciones de origen (NAT-src) al nivel de directivas. Con NAT-src puede traducir la
dirección de origen en la red entrante o saliente y en el tráfico VPN. La nueva dirección de origen puede proceder
de un conjunto de IPs dinámicas (DIP) o de la interfaz de salida. NAT-src también admite la traducción de
direcciones de los puertos de origen (PAT). Para obtener más información sobre todas las opciones de NAT-src
disponibles, consulte “Traducción de direcciones de red de origen” en la pàgina 7 -15.
Nota: También puede realizar la traducción de direcciones de origen a nivel de la interfaz, conocida como
traducción de direcciones de red (NAT). Para obtener más información sobre el nivel de interfaz NAT-src, o
simplemente NAT, consulte “Modo NAT” en la pàgina 127.
Traducción de direcciones de destino

Puede aplicar la traducción de direcciones de destino (NAT-dst) a nivel de directiva. Con NAT-dst puede traducir la
dirección de origen en la red entrante o saliente y en el tráfico VPN. NAT-dst también admite la asignación de
puertos de destino. Para obtener más información sobre todas las opciones de NAT-dst disponibles, consulte
“Traducción de direcciones de red de destino” en la pàgina 7 -35.
Autenticación de usuarios
Seleccionar esta opción requiere que el usuario de autenticación en la dirección de origen autentique su identidad
proporcionando un nombre de usuario y la contraseña antes de permitir al tráfico atravesar el cortafuegos o
introducirse en el túnel VPN. El dispositivo NetScreen puede utilizar la base de datos local o un servidor RADIUS,
SecurID o LDAP externo para realizar la comprobación de la autenticación.
Nota: Si una directiva que requiere autenticación puede aplicarse a una subred de direcciones IP, se requerirá
autenticación para cada dirección IP de esa subred.
Si un host admite múltiples cuentas de usuarios de autenticación (como ocurre con un host Unix ejecutando
Telnet), una vez que el dispositivo NetScreen ha autenticado al primer usuario, el resto de usuarios de ese host
pueden enviar tráfico a través del dispositivo NetScreen sin necesidad de autenticación, al haber heredado los
privilegios del primer usuario.

NetScreen proporciona dos esquemas de autenticación:

• Autenticación en tiempo de ejecución, en la cual el dispositivo NetScreen solicita al usuario de
autenticación que inicie una sesión al recibir tráfico HTTP, FTP o Telnet que cumpla una directiva en la que
esté habilitada la autenticación.
• WebAuth, en la cual el usuario debe autenticarse para poder enviar tráfico a través del dispositivo
NetScreen.

Autenticación en tiempo de ejecución

El proceso de autenticación en tiempo de ejecución ocurre como sigue:
1. Cuando el usuario de autenticación envía una petición de conexión HTTP, FTP o Telnet a la dirección de
destino, el dispositivo NetScreen intercepta el paquete y lo almacena en un búfer.
2. El dispositivo NetScreen envía al usuario de autenticación un mensaje de petición de inicio de sesión.
3. El usuario de autenticación responde a esta petición con su nombre de usuario y contraseña.
4. El dispositivo NetScreen autentica la información de inicio de sesión de usuario de autenticación.
Si la autenticación es correcta, se establece una conexión entre el usuario de autenticación y la dirección
de destino.
Para la petición de conexión inicial, la directiva debe incluir uno o todos los servicios siguientes: Telnet, HTTP o
FTP. Sólo una directiva con uno o todos estos servicios puede iniciar el proceso de autenticación. En una directiva
que implique autenticación de usuario se puede utilizar cualquiera de los siguientes servicios:
• Any (porque “any” (cualquiera) incluye los tres servicios requeridos)
• Telnet, FTP o HTTP
• Un grupo de servicios que incluye el servicio o los servicios que desea, más como mínimo uno de los tres
servicios requeridos para iniciar el proceso de autenticación (Telnet, FTP o HTTP). Por ejemplo, puede
crear un grupo de servicios personalizado llamado “Login” que proporcione los servicios FTP, NetMeeting©
y H.323. Luego, cuando cree la directiva, especifique “Login” como el servicio.
Para cualquier conexión que sigue a una autenticación correcta, todos los servicios especificados en la directiva
son válidos.
Nota: Una directiva con la autenticación habilitada no admite DNS (puerto 53) como servicio.
Autenticación de comprobación previa a la directiva (WebAuth)

El proceso de autenticación de WebAuth es como sigue:
1. El usuario de autenticación establece una conexión HTTP a la dirección IP del servidor de WebAuth.
2. El dispositivo NetScreen envía al usuario de autenticación un mensaje de petición de inicio de sesión.

3. El usuario de autenticación responde a esta petición con su nombre de usuario y contraseña.

4. El dispositivo NetScreen o un servidor de autenticación externo autentica la información de inicio de sesión
del usuario de autenticación.
Si el intento de autenticación tiene éxito, el dispositivo NetScreen permite al usuario de autenticación iniciar
tráfico a los destinos especificados en las directivas que obligan a la autenticación por el método de
WebAuth.
Nota: Para obtener más información sobre estos dos métodos de autenticación de usuarios, consulte “Referencias
a usuarios autenticados en directivas” en la pàgina 8 -44.
Puede restringir o ampliar el rango de los usuarios de autenticación a quienes deba aplicarse la directiva
seleccionando un determinado grupo de usuarios, usuario local o externo o una expresión de grupo. (Para obtener
más información sobre expresiones de grupos, consulte “Expresiones de grupos” en la pàgina 8 -6). Si en una
directiva no se hace referencia a un usuario de autenticación o a un grupo de usuarios (en WebUI, seleccionando la
opción Allow Any ), la directiva se aplicará a todos los usuarios de autenticación del servidor especificado.
Nota: NetScreen vincula los privilegios de autenticación a la dirección IP del host desde el que se conecta el
usuario de autenticación. Si el dispositivo NetScreen autentica a un usuario de un host situado detrás de un
dispositivo NAT que utilice una sola dirección IP para todas las asignaciones NAT, los usuarios de otros hosts
situados detrás de ese dispositivo NAT recibirán automáticamente los mismos privilegios.
Copia de seguridad de la sesión HA

Cuando dos dispositivos NetScreen se encuentran en un clúster NSRP para alta disponibilidad (HA), puede
especificar qué sesiones salvaguardar y cuáles no. Para el tráfico cuyas sesiones no desee salvaguardar, aplique
una directiva con la opción HA session backup desactivada. En WebUI, desactive la casilla de verificación HA
Session Backup . En CLI, utilice el argumento no-session-backup en el comando set policy . De forma
predeterminada, los dispositivos NetScreen de un clúster NSRP salvaguardan las sesiones.

Filtrado de URL
El filtrado de URL, denominado también “web filtering”, permite administrar los accesos a Internet e impedir el
acceso a contenidos no apropiados. Cuando habilite el filtrado de URL en una directiva, debe configurar una de las
siguientes soluciones de filtrado de URL:
• Filtrado de URL integrado, donde el dispositivo NetScreen intercepta cada petición HTTP y determina si
permitir o bloquear el acceso al sitio solicitado basándose en el perfil de filtrado de URL asociado a la
directiva del cortafuegos.
• Filtrado de URL redirigido, donde el dispositivo NetScreen envía la primera petición HTTP de una conexión
TCP a un servidor Websense o a un servidor SurfControl, lo que permite bloquear o permitir el acceso a
diferentes sitios basándose en las URL, nombres de dominio y direcciones IP.
Nota: Para obtener más información sobre el filtrado de URL, consulte “Filtrado de URL” en la pàgina 4 -111.
Registro
Cuando se habilita el registro en una directiva, el dispositivo NetScreen registra todas las conexiones a las
que esa directiva en particular sea aplicable. Los registros se pueden visualizar con WebUI o CLI. En WebUI,
haga clic en Reports > Policies > (para la directiva cuyo registro desee consultar). En CLI, utilice el comando
get log traffic policy id_num .
Nota: Para obtener más información sobre cómo visualizar registros y gráficos, consulte “Supervisión de
dispositivos NetScreen” en la pàgina 3 -85.
Recuento
Cuando se habilita el recuento en una directiva, el dispositivo NetScreen cuenta el número total de bytes de tráfico
para los que esa directiva es aplicable y registra la información en gráficos de historial. Para visualizar los gráficos
de historial de una directiva en WebUI, haga clic en Reports > Policies > (para la directiva cuyo tráfico desea
consultar).

Umbral de alarma de tráfico

Puede establecer un umbral que dispare una alarma cuando el tráfico permitido por la directiva exceda un número
especificado de bytes por segundo, bytes por minuto, o ambos. Debido a que la alarma de tráfico requiere que el
dispositivo NetScreen supervise el número total de bytes, también debe habilitar la función de recuento.
Nota: Para obtener más información sobre alarmas de tráfico, consulte “Alarmas de tráfico” en la pàgina 3 -105.
Tareas programadas
Asociando una programación a una directiva se puede determinar cuándo debe activarse esa directiva. Puede
configurar programaciones repetitivas y como evento único. Las programaciones proporcionan una potente
herramienta para controlar el flujo de tráfico de la red e implementar seguridad en ésta. Como ejemplo de esto
último, si le preocupa que algunos empleados puedan transmitir datos importantes fuera de la empresa, puede
establecer una directiva que bloquee los tipos de tráfico saliente FTP-Put y MAIL después del horario de oficina
normal.
En WebUI, defina tareas programadas en la sección Objects > Schedules . En CLI, ejecute el comando
set schedule .
Nota: En WebUI, las directivas programadas aparecen con un fondo gris para indicar que la hora actual no está
dentro de la programación definida. Cuando una directiva programada se activa, aparece con un fondo blanco.
Análisis antivirus
Algunos dispositivos NetScreen admiten un analizador antivirus interno que se puede configurar para filtrar tráfico
FTP, HTTP, IMAP, POP3 y SMTP. Si el analizador AV incorporado detecta un virus, descarta el paquete y envía un
mensaje al cliente que inició el tráfico para informarle sobre dicho virus.
Nota: Para obtener más información sobre el análisis antivirus, consulte “Análisis antivirus” en la pàgina 4 -86.

Asignación de tráfico
Puede establecer los parámetros de control y asignación del tráfico para cada directiva. Los parámetros de
asignación de tráfico son:
Guaranteed Bandwidth: Tasa de transferencia garantizada en kilobits por segundo (kbps). El tráfico que
no alcanza este umbral pasa con la prioridad más alta sin ser sometido a ningún mecanismo de
administración o asignación del tráfico.
Maximum Bandwidth: Ancho de banda garantizado disponible para el tipo de conexión en kilobits por
segundo (kbps). El tráfico más allá de este umbral se desvía y se descarta.
Nota: Se aconseja no utilizar tasas inferiores a 10 kbps. Las tasas inferiores a este umbral conducen al
descarte de paquetes y a un número excesivo de reintentos que contravienen el objetivo de la
administración del tráfico.
Traffic Priority: Cuando el ancho de banda del tráfico se encuentra entre los ajustes garantizado y
máximo, el dispositivo NetScreen permite pasar primero el tráfico de mayor prioridad, y el tráfico de menor
prioridad sólo cuando no hay otro tráfico de prioridad superior. Existen ocho niveles de prioridad.
DiffServ Codepoint Marking: “Differentiated Services” (“DiffServ”) es un sistema para etiquetar
(o “marcar”) el tráfico de una posición dentro de una jerarquía de prioridades. Puede asignar los ocho
niveles de prioridad de NetScreen al sistema DiffServ. De forma predeterminada, la prioridad más alta
(prioridad 0) del sistema NetScreen corresponde a los tres primeros bits (0111) del campo “DiffServ”
(consulte la RFC 2474), o al campo de precedencia de IP del byte TOS (consulte la RFC 1349), en el
encabezado de paquetes de IP. La prioridad más baja (prioridad 7) del sistema de NetScreen corresponde
a (0000) en el sistema TOS DiffServ.
Nota: Para averiguar más sobre la administración y asignación del tráfico, consulte “Asignación de
tráfico” en la pàgina 359.

Para cambiar la asignación entre los niveles de prioridad de NetScreen y el sistema DiffServ, utilice el
siguiente comando CLI:
set traffic-shaping ip_precedence number0 number1 number2 number3 number4 number5
number6 number7
donde number0 corresponde a la prioridad 0 (la prioridad más alta del sistema TOS DiffServ),
number1 corresponde a la prioridad 1, y así sucesivamente.
Para incluir prioridades de IPs en puntos de código selectores de clase (“class selector codepoints”), es
decir, poner a cero el segundo grupo de tres bits del campo “DiffServ” para asegurar que los niveles de
prioridad establecidos con ip_precedence se conserven y sean correctamente tratados por los
enrutadores de bajada, utilice el comando CLI siguiente:
set traffic-shaping dscp-class-selector
Nota: El comando set traffic-shaping dscp-class-selector sólo se puede configurar desde CLI.

Capítulo 6 Directivas Directivas aplicadas
DIRECTIVAS APLICADAS
Esta sección describe la administración de directivas: visualización, creación, modificación, ordenación y
reordenación y eliminación de directivas.
Visualización de directivas
Para visualizar directivas a través de WebUI, haga clic en Policies . Puede clasificar las directivas mostradas por
zonas de origen y de destino, eligiendo nombres de zonas en las listas desplegables From y To , y haciendo clic en
Go . En CLI, utilice el comando get policy [ all | from zone to zone | global | id number ] .
Iconos de directivas
Para visualizar una lista de directivas, WebUI utiliza iconos para proporcionarle un resumen gráfico de los
componentes de la directiva. La tabla siguiente define los diferentes iconos utilizados en la página de directivas.
Icono Función Descripción

Permitir El dispositivo NetScreen entrega todo el tráfico al que sea aplicable la
directiva.
Denegar El dispositivo NetScreen bloquea todo el tráfico al que sea aplicable la

directiva.
Rechazo El dispositivo NetScreen bloquea todo el tráfico al que sea aplicable la

directiva. Descarta el paquete y envía un segmento de restablecimiento
(RST) de TCP al host de origen para el tráfico TCP y un mensaje de
“destino inalcanzable, puerto inalcanzable” ICMP (tipo 3, código 3) para
el tráfico UDP. Para los tipos de tráfico distintos de TCP y UDP, el
dispositivo NetScreen descarta el paquete sin notificar al host de origen,
lo cual también ocurre cuando la acción es “deny”.
NAT a nivel de directiva El dispositivo NetScreen realiza una traducción de direcciones de la red
de origen o de destino basada en directivas (NAT-src o NAT-dst) sobre
todo el tráfico al que sea aplicable la directiva.


Encapsulado El dispositivo NetScreen encapsula todo el tráfico VPN saliente y
y desencapsulado desencapsula todo el tráfico VPN entrante al que sea aplicable la
directiva.
Directivas VPN Existe una directiva VPN coincidente para el sentido opuesto.
bidireccionales
Autenticación El usuario debe autenticarse al iniciar una conexión.
Antivirus El dispositivo NetScreen envía todo el tráfico al que sea aplicable la

directiva a un analizador antivirus (AV) interno.
Deep Inspection El dispositivo NetScreen aplica Deep Inspection (DI) a todo el tráfico al
que sea aplicable la directiva.
Deep Inspection y El dispositivo NetScreen aplica la protección antivirus y Deep Inspection

antivirus a todo el tráfico al que sea aplicable la directiva.
Filtrado de URL El dispositivo NetScreen envía a un servidor externo de filtrado de URL

todo el tráfico al que sea aplicable la directiva.
L2TP El dispositivo NetScreen encapsula todo el tráfico L2TP saliente y

desencapsula todo el tráfico L2TP entrante al que sea aplicable la
directiva.
Registro Todo el tráfico se registra y se pone a disposición de syslog y correo
electrónico, si están habilitados.
Recuento El dispositivo NetScreen cuenta (en bytes) a cuánto tráfico es aplicable

la directiva.


Alarma Cuando la cantidad de tráfico sobrepasa un umbral establecido, el
dispositivo NetScreen efectúa una entrada en el registro de tráfico
correspondiente a esta directiva. Haciendo clic en el icono se accede al
registro de tráfico situado en la sección de informes “Reports”.
Creación de directivas
Para permitir el flujo de tráfico entre dos zonas, debe crear directivas para permitir, denegar, rechazar o tunelizar el
tráfico entre esas zonas. También puede crear directivas para controlar el tráfico dentro de la misma zona si el
dispositivo NetScreen es el único dispositivo de red capaz de enrutar el tráfico intrazonal entre las direcciones de
origen y de destino referidas en la directiva. También puede crear directivas globales que utilizan direcciones de
origen y de destino en la libreta de direcciones de la zona Global.
Para permitir tráfico bidireccional entre dos zonas (por ejemplo, entre la zona Trust y la zona Untrust) se necesita
crear una directiva para el tráfico de Trust a Untrust y otra para el tráfico de Untrust a Trust. Dependiendo de sus
necesidades, las directivas pueden utilizar la misma dirección IP o bien direcciones diferentes, invirtiendo las
direcciones de origen y destino.
Ubicación de directivas
Se pueden definir directivas entre cualesquiera zonas situadas dentro del mismo sistema, ya sea raíz o virtual. Para
definir una directiva entre el sistema raíz y un sistema virtual (vsys), una de las zonas debe ser compartida. (Para
obtener más información sobre zonas compartidas en lo referente a sistemas virtuales, consulte el Volumen 9,
“Sistemas virtuales”).

Ejemplo: Servicio de correo de directivas interzonales

En este ejemplo creará tres directivas para controlar el flujo de tráfico de correo electrónico.
La primera directiva permitirá a los usuarios internos de la zona Trust enviar y recibir correo electrónico de un
servidor de correo local situado en la zona DMZ. Esta directiva permitirá a los servicios MAIL (es decir, SMTP) y
POP3 generados por los usuarios internos atravesar el cortafuegos de NetScreen para alcanzar el servidor de
correo local.
Las directivas segunda y tercera permitirán al servicio MAIL atravesar el cortafuegos existente entre el servidor de
correo local de la zona DMZ y un servidor de correo remoto de la zona Untrust.
Sin embargo, antes de crear directivas para controlar tráfico entre diferentes zonas de seguridad, debe diseñar el
entorno en el que aplicar esas directivas. Primero asociará interfaces a zonas y les asignará direcciones IP de
interfaces:
• Asocie ethernet1 a la zona Trust y asígnele la dirección IP 10.1.1.1/24.
• Asocie ethernet2 a la zona DMZ y asígnele la dirección IP 1.2.2.1/24.
• Asocie ethernet3 a la zona Untrust y asígnele la dirección IP 1.1.1.1/24.
Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.
En segundo lugar, creará las direcciones que se utilizarán en las directivas:
• Defina una dirección en la zona Trust llamada “corp_net” y asígnele la dirección IP 10.1.1.0/24.
• Defina una dirección en la zona DMZ llamada “mail_svr” y asígnele la dirección IP 1.2.2.5/32.
• Defina una dirección en la zona Untrust llamada “r-mail_svr” y asígnele la dirección IP 2.2.2.5/32.
En tercer lugar, creará un grupo de servicios llamado “MAIL-POP3” que contendrá los dos servicios predefinidos
MAIL y POP3.
En cuarto lugar, configurará una ruta predeterminada en el dominio de enrutamiento trust-vr que señalará al
enrutador externo en 1.1.1.250 a través de ethernet3.
Una vez completados los pasos 1 a 4, podrá crear las directivas necesarias para permitir la transmisión,
recuperación y entrega de correo electrónico dentro y fuera de su red protegida.

WebUI
1. Interfaces
Zone Name: Trust

Interface Mode: NAT
Zone Name: DMZ
Zone Name: Untrust
2. Direcciones
Address Name: corp_net
Zone: Trust

Address Name: mail_svr
Zone: DMZ
Address Name: r-mail_svr
Zone: Untrust
Objects > Services > Groups: Introduzca el siguiente nombre de grupo, mueva los siguientes servicios y haga
clic en OK :
Group Name: MAIL-POP3
Seleccione MAIL y utilice el botón << para mover el servicio de la columna
Seleccione POP3 y utilice el botón << para mover el servicio de la columna
4. Ruta

5. Directivas
Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), corp_net
Address Book Entry: (seleccione), mail_svr
Service: Mail-POP3
Action: Permit
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit
Source Address:
Address Book Entry: (seleccione), r-mail_svr
Service: MAIL
Action: Permit

CLI
1. Interfaces
set interface ethernet2 zone dmz
2. Direcciones
set address trust corp_net 10.1.1.0/24
set address dmz mail_svr 1.2.2.5/32
set address untrust r-mail_svr 2.2.2.5/32
set group service MAIL-POP3
set group service MAIL-POP3 add mail
set group service MAIL-POP3 add pop3
4. Ruta
5. Directivas
set policy from trust to dmz corp_net mail_svr MAIL-POP3 permit
set policy from dmz to untrust mail_svr r-mail_svr MAIL permit
set policy from untrust to dmz r-mail_svr mail_svr MAIL permit
save

Ejemplo: Conjunto de directivas interzonales

Una pequeña empresa de software, ABC Design, ha dividido su red interna en dos subredes, y ambas están en la
zona Trust. Estas dos subredes son:
• Engineering (con la dirección definida como “Eng”).
• Resto de la empresa (con la dirección definida como “Office”).
También tiene una zona DMZ para sus servidores de Web y correo electrónico.
El ejemplo siguiente presenta un conjunto típico de directivas para los siguientes usuarios:
• “Eng” puede utilizar todos los servicios de tráfico saliente salvo FTP-Put, IMAP, MAIL y POP3.
• Los usuarios de “Office” pueden utilizar el correo electrónico y el acceso a Internet, siempre que se
autentiquen a través de WebAuth. (Para obtener más información sobre la autenticación de usuarios
mediante WebAuth, consulte “Usuarios de autenticación” en la pàgina 8 -43).
• Cada usuario de la zona Trust puede acceder a los servidores de web y correo electrónico en la zona DMZ.
• Un servidor de correo remoto de la zona Untrust puede acceder al servidor de correo local de la zona DMZ.
• También hay un grupo de administradores de sistemas (con la dirección definida por el usuario
“sys-admins”), que disponen de permisos completos de acceso de usuario y acceso administrativo a los
servidores de la zona DMZ.
Zona Untrust
Internet
www.abc.com
mail.abc.com
Enrutador externo
NetScreen
Enrutador interno Zona DMZ
“LAN” de “Office” “LAN” de “Eng”
Zona Trust

Este ejemplo se centra solamente en directivas y asume que ya tiene configuradas las interfaces, direcciones,
grupos de servicios y rutas necesarias. Para obtener más información sobre su configuración, consulte “Interfaces”
en la pàgina 53, “Direcciones” en la pàgina 143, “Grupos de servicios” en la pàgina 274 y el Volumen 6,
“Enrutamiento dinámico”.
De zona - Dir origen A la zona - Dir destino Servicio Acción
Trust - Any Untrust - Any Com (grupo de servicios: FTP-Put, IMAP, MAIL, Rechazo
POP3)
Trust - Eng Untrust - Any Any Permitir
Trust - Office Untrust - Any Internet (grupo de servicios: FTP-Get, HTTP, Permitir
HTTPS) (+ WebAuth)

Untrust - Any DMZ - mail.abc.com MAIL Permitir
Untrust - Any DMZ - www.abc.com Web (grupo de servicios: HTTP, HTTPS) Permitir

Trust - Any DMZ - mail.abc.com correo electrónico (grupo de servicios: IMAP, Permitir
MAIL, POP3)
Trust - Any DMZ - www.abc.com Internet (grupo de servicios: FTP-Get, HTTP, Permitir
HTTPS)
Trust - sys-admins DMZ - Any Any Permitir

DMZ - mail.abc.com Untrust - Any MAIL Permitir
Nota: La directiva predeterminada es denegar todo.

WebUI
1. De Trust, a Untrust
Source Address:
Address Book Entry: (seleccione), Eng
Service: ANY
Action: Permit
Source Address:
Address Book Entry: (seleccione), Office
Service: Internet7
Action: Permit
Authentication: (seleccione)
WebAuth: (seleccione)
7. “Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y HTTPS.

Source Address:
8
Service: Com
Action: Reject
Nota: Para el tráfico de la zona Untrust a la zona Trust, la directiva de denegación predeterminada deniega
todo.
2. De Untrust, a DMZ
Source Address:
Address Book Entry: (seleccione), mail.abc.com
Service: MAIL
Action: Permit
8. “Com” es un grupo de servicios con los siguientes miembros: FTP-Put, MAIL, IMAP y POP3.

Source Address:
Address Book Entry: (seleccione), www.abc.com
9
Service: Web
Action: Permit
3. De Trust, a DMZ
Source Address:
Service: e-mail10
Action: Permit
9. “Web” es un grupo de servicios con los siguientes miembros: HTTP y HTTPS.

10. “e-mail” es un grupo de servicios con los siguientes miembros: MAIL, IMAP y POP3.

Source Address:
Address Book Entry: (seleccione), www.abc.com
Service: Internet
Action: Permit
Source Address:
Address Book Entry: (seleccione), sys-admins
Service: ANY
Action: Permit
4. De DMZ, a Untrust
Source Address:
Service: MAIL
Action: Permit

CLI
1. De Trust, a Untrust
set policy from trust to untrust eng any any permit
11
set policy from trust to untrust office any Internet permit webauth
12
set policy top from trust to untrust any any Com reject
2. De Untrust, a DMZ
set policy from untrust to dmz any mail.abc.com mail permit
13
set policy from untrust to dmz any www.abc.com Web permit
3. De Trust, a DMZ
14
set policy from trust to dmz any mail.abc.com e-mail permit
11
set policy from trust to dmz any www.abc.com Internet permit
set policy from trust to dmz sys-admins any any permit
4. De DMZ, a Untrust
set policy from dmz to untrust mail.abc.com any mail permit
save
11. “Internet” es un grupo de servicios con los siguientes miembros: FTP-Get, HTTP y HTTPS.
12. “Com” es un grupo de servicios con los siguientes miembros: FTP-Put, MAIL, IMAP y POP3.
13. “Web” es un grupo de servicios con los siguientes miembros: HTTP y HTTPS.
14. “e-mail” es un grupo de servicios con los siguientes miembros: MAIL, IMAP y POP3.

Ejemplo: Directivas intrazonales

En este ejemplo creará una directiva intrazonal para permitir a un grupo de contables acceder a un servidor
confidencial de la LAN corporativa en la zona Trust. Primero asociará ethernet1 a la zona Trust y le dará la dirección
IP 10.1.1.1/24. Después asociará ethernet2 a la zona Trust y le asignará la dirección IP 10.1.5.1/24. Habilitará el
bloqueo intrazonal en la zona Trust. A continuación, definirá dos direcciones, una para un servidor en el que la
empresa almacena sus registros financieros (10.1.1.100/32) y otra para la subred que contiene los hosts del
departamento de contabilidad (10.1.5.0/24). Seguidamente creará una directiva intrazonal para permitir el acceso al
servidor desde esos hosts.
WebUI
1. Zona Trust – Interfaces y bloqueo
Zone Name: Trust

Interface Mode: NAT
Zone Name: Trust

Interface Mode: NAT
Network > Zones > Edit (para Trust): Introduzca los siguientes datos y haga clic en OK :
Block Intra-Zone Traffic: (seleccione)

2. Direcciones
Address Name: Hamilton
Zone: Trust
Address Name: accounting
Zone: Trust
3. Directiva
Policies > (From: Trust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), accounting
Address Book Entry: (seleccione), Hamilton
Service: ANY
Action: Permit

CLI
1. Zona Trust – Interfaces y bloqueo

set zone trust block

2. Direcciones
set address trust Hamilton 10.1.1.100/32
set address trust accounting 10.1.5.0/24
3. Directiva
set policy from trust to trust accounting Hamilton any permit
save

Ejemplo: Directiva global

En este ejemplo creará una directiva global para que cada host de cada zona pueda acceder al sitio web de la
empresa, que es www.juniper.net15. La utilización de una directiva global es un método abreviado muy práctico para
entornos con muchas zonas de seguridad. En este ejemplo, una directiva global logrará lo mismo que n directivas
interzonales (donde n = número de zonas).
WebUI
1. Dirección global
Address Name: server1
Domain Name: (seleccione), www.juniper.net
Zone: Global
2. Directiva
Policies > (From: Global, To: Global) > New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), server1
Service: HTTP
Action: Permit
15. Para utilizar un nombre de dominio en lugar de una dirección IP, asegúrese de tener configurado el servicio DNS en el dispositivo NetScreen.

CLI
1. Dirección global
set address global server1 www.juniper.net
2. Directiva
set policy global any server1 http permit
save
Introducción del contexto de una directiva

Al configurar una directiva mediante CLI, puede introducir su contexto para agregar o modificar datos. Por ejemplo,
suponga que primero crea la directiva siguiente:
set policy id 1 from trust to untrust host1 server1 HTTP permit attack
HIGH:HTTP:SIGS action close
Si desea efectuar algunos cambios en una directiva, como la inclusión de otra dirección de origen o de destino, otro
servicio u otro grupo de ataque, puede introducirse en el contexto de la directiva 1 y luego ejecutar los comandos
pertinentes:
set policy id 1
ns(policy:1)-> set src-address host2
ns(policy:1)-> set dst-address server2
ns(policy:1)-> set service FTP
ns(policy:1)-> set attack CRITICAL:HTTP:SIGS
También puede eliminar varios elementos de un componente de directiva único, siempre que no elimine todos. Por
ejemplo, puede eliminar server2 de la configuración anterior, pero no server2 y server1 a la vez, porque no quedaría
ninguna dirección de destino:
Puede eliminar server2,

3 ns(policy:1)-> unset dst-address server2
o puede eliminar server1,
pero no puede eliminar ambos.

ns(policy:1)-> unset dst-address server1

Varios elementos por componente de directiva

ScreenOS permite agregar múltiples elementos a los siguientes componentes de una directiva:
• Dirección de origen
• Dirección de destino
• Servicio
• Grupo de ataque
En versiones anteriores a ScreenOS 5.0.0, la única manera de tener múltiples direcciones de origen y destino o
múltiples servicios era crear un grupo de direcciones o de servicios con múltiples miembros y luego hacer
referencia al mismo en una directiva. En las directivas de ScreenOS 5.0.0 todavía se pueden utilizar grupos de
direcciones y de servicios. Además, puede simplemente agregar elementos adicionales directamente a un
componente de la directiva.
Nota: Si la primera dirección o servicio al que se hace referencia en una directiva es “Any”, no se le podrá agregar
lógicamente nada más. NetScreen impide este tipo de errores de configuración mostrando un mensaje de error
cuando ocurren.
Para agregar múltiples elementos a un componente de directiva, ejecute cualquiera de los siguientes
procedimientos:
WebUI
Para agregar más direcciones y servicios, haga clic en el botón Multiple junto al componente al que desea
agregar más elementos. Para agregar más grupos de ataque, haga clic en el botón Attack Protection .
Seleccione un elemento en la columna “Available Members” y utilice la tecla << para moverlo a la columna
“Active Members”. Puede repetir esta acción con otros elementos. Cuando haya terminado, haga clic en
OK para regresar a la página de configuración de directivas.

CLI
Introduzca el contexto de la directiva con el comando siguiente:
set policy id number
Ahora utilice uno de los comandos siguientes según convenga:
ns(policy: number )-> set src-address string
ns(policy: number )-> set dst-address string
ns(policy: number )-> set service string
ns(policy: number )-> set attack string

Negación de direcciones
Puede configurar una directiva de modo que sea aplicable a todas las direcciones salvo a la especificada como
origen o destino. Por ejemplo, suponga que desea crear una directiva que permita el acceso a Internet a todos
salvo al grupo de direcciones “P-T_contractors”. Para lograrlo, puede utilizar la opción de negación de direcciones.
En WebUI, esta opción está disponible en la ventana emergente que aparece al hacer clic en el botón Multiple
junto a “Source Address” o a “Destination Address” en la página de configuración de directivas.
En CLI, inserte un signo de exclamación ( ! ) inmediatamente antes de la dirección de origen o de destino.
Nota: La negación de direcciones ocurre en el nivel de componentes de directivas, aplicándose a todos los
elementos del componente negado.
Ejemplo: Negación de la dirección de destino

En este ejemplo creará una directiva intrazonal que permitirá a todas las direcciones de la zona Trust acceder a
todos los servidores FTP salvo a un determinado servidor FTP llamado “vulcan”, que los miembros del
departamento de ingeniería utilizan para intercambiar especificaciones funcionales entre sí.
Sin embargo, antes de crear la directiva deberá diseñar el entorno en el cual desea aplicarlo. Primero habilitará el
bloqueo intrazonal para la zona Trust. El bloqueo intrazonal requiere efectuar una consulta de directivas antes de
que el dispositivo NetScreen pueda pasar tráfico entre dos interfaces asociadas a la misma zona.
En segundo lugar, asociará dos interfaces a la zona Trust y les asignará direcciones IP:
• Asociará ethernet1 a la zona Trust y le asignará la dirección IP 10.1.1.1/24.
• Asociará ethernet4 a la zona Trust y le asignará la dirección IP 10.1.2.1/24.
Tercero, creará una dirección (10.1.2.5/32) para el servidor FTP llamado “vulcan” en la zona Trust.
Después de completar estos dos pasos, podrá crear las directivas intrazonales.
Nota: No es necesario crear una directiva para que el departamento de ingeniería pueda alcanzar su servidor FTP,
ya que los ingenieros también se encuentran en la subred 10.1.2.0/24 y no necesitan traspasar el cortafuegos de
NetScreen para alcanzar su propio servidor.

ethernet1
10.1.1.1/24
ethernet4
10.1.2.1/24
Conmutadores internos
10.1.1.0/24 10.1.2.0/24
(Resto de corporate) (Ingeniería) servidor FTP
“vulcan”
10.1.2.5
Zona Trust
Bloqueo intrazonal
habilitado
WebUI
1. Bloqueo intrazonal
Network > Zones > Edit (para Trust): Introduzca los siguientes datos y haga clic en OK :
Block Intra-Zone Traffic: (seleccione)
2. Interfaces de la zona Trust

Zone Name: Trust

Interface Mode: NAT

Zone Name: Trust

Interface Mode: NAT
3. Dirección
Address Name: vulcan
Zone: Trust
4. Directiva
Policies > (From: Trust, To: Trust) New: Introduzca los siguientes datos y haga clic en OK :
Source Address:
Address Book Entry: (seleccione), vulcan
> Haga clic en Multiple , active la casilla de verificación Negate Following
y haga clic en OK para regresar a la página de configuración básica de
directivas.
Service: FTP
Action: Permit

CLI
1. Bloqueo intrazonal
set zone trust block
2. Interfaces de la zona Trust

3. Dirección
set address trust vulcan 10.1.2.5/32
4. Directiva
set policy from trust to trust any !vulcan ftp permit
save

Modificación y desactivación de directivas

Una vez creada una directiva, puede volver a ella en cualquier momento para efectuar modificaciones. En WebUI,
haga clic en el vínculo Edit de la columna “Configure” para elegir la directiva que desea cambiar. En la página de
configuración correspondiente a esa directiva, realice sus cambios y haga clic en OK . En CLI, ejecute el comando
set policy .
ScreenOS también proporciona un medio para habilitar e inhabilitar directivas. De forma predeterminada, las
directivas están habilitadas. Para desactivarlas, haga lo siguiente:
WebUI
Policies: Desactive la casilla de verificación Enable de la columna “Configure” para la directiva que desee
desactivar.
La fila de texto de una directiva inhabilitada aparece en color gris.
CLI
set policy id id_num disable
save
Nota: Para volver a habilitar la directiva, seleccione Enable en la columna “Configure” de la directiva que
desee habilitar (WebUI), o ejecute el comando unset policy id id_num disable (CLI).

Verificación de directivas
ScreenOS ofrece una herramienta para verificar si el orden de las directivas dentro de la lista de directivas es
válido. Una directiva puede eclipsar (“ocultar”) otra directiva. Considere el ejemplo siguiente:
set policy id 1 from trust to untrust any any HTTP permit
set policy id 2 from trust to untrust any dst-A HTTP deny
Como el dispositivo NetScreen consulta la lista de directivas comenzando por el principio, deja de buscar tan pronto
como encuentra una coincidencia de tráfico recibido. En el ejemplo antedicho, el dispositivo NetScreen nunca alcanza
la directiva 2 porque la dirección de destino “any” de la directiva 1 ya incluye la dirección “dst-A” más específica de la
directiva 2. Cuando un paquete HTTP llega al dispositivo NetScreen desde una dirección en la zona Trust asociada a
dst-A en la zona Untrust, el dispositivo NetScreen siempre encontrará una coincidencia en la directiva 1.
Para corregir el ejemplo antedicho, basta con invertir el orden de las directivas, poniendo la más específica en
primer lugar:
set policy id 2 from trust to untrust any dst-A HTTP deny
set policy id 1 from trust to untrust any any HTTP permit
Por supuesto, este ejemplo tan simple sólo pretende ilustrar el concepto básico. En casos donde hay docenas o
incluso centenares de directivas, la detección de directivas eclipsadas por otras directivas puede no resultar tan
sencilla. Para comprobar si hay alguna directiva oculta16 en su lista de directivas, ejecute el comando CLI siguiente:
exec policy verify
Este comando informa sobre las directivas ocultadas y sobre la ocultación en general. Es responsabilidad del
administrador corregir la situación.
La herramienta de verificación de directivas no puede detectar los casos en los que una combinación de directivas
oculta otra directiva. En el ejemplo siguiente, ninguna directiva oculta la directiva 3; sin embargo, las directivas 1 y 2
juntas sí la ocultan:
set group address trust grp1 add host1
set group address trust grp1 add host2
set policy id 1 from trust to untrust host1 server1 HTTP permit
set policy id 2 from trust to untrust host2 server1 HTTP permit
set policy id 3 from trust to untrust grp1 server1 HTTP deny
16. El concepto de “ocultación” de directivas se refiere al hecho de que una directiva situada más arriba en la lista de directivas siempre se encuentra antes
que una directiva situada más abajo. Debido a que la consulta de directivas utiliza siempre la primera directiva en la que detecta una coincidencia con el
registro de cinco elementos de las zonas de origen y de destino, con las direcciones de origen y destino y con el tipo de servicio, si hay otra directiva aplicable
al mismo registro (o a un subconjunto de registros), la consulta de directivas utilizará la primera directiva de la lista y nunca alcanzará la segunda.

Reordenamiento de directivas
El dispositivo NetScreen compara todos los intentos de atravesar el cortafuegos con las directivas, comenzando por
la primera que aparece en el conjunto de directivas de la lista correspondiente (consulte “Listas de conjuntos de
directivas” en la pàgina 311) y avanzando en la lista. Debido a que el dispositivo NetScreen aplica la acción
especificada en la directiva a la primera directiva que coincide en la lista, es necesario reordenar las directivas
desde la más específica a la más general. (Aunque una directiva específica no impide la aplicación de una directiva
más general situada más abajo en la lista, una directiva general situada más arriba en la lista que una específica sí
lo impide).
De forma predeterminada, una directiva recién creada aparece al final de la lista de conjuntos de directivas.
Existe una opción que permite colocar una directiva al principio de la lista. En la página de configuración de
directivas de WebUI, active la casilla de verificación Position at Top . En CLI, agregue la palabra clave top al
comando set policy : set policy top …
Para mover una directiva a otra posición dentro de la lista, ejecute cualquiera de los siguientes procedimientos:
WebUI
Hay dos maneras de reordenar directivas en WebUI: haciendo clic en las flechas circulares o haciendo clic
en la flecha única de la columna “Configure” correspondiente a la directiva que desee mover.
Si hace clic en las flechas circulares:
Aparecerá un cuadro de diálogo con un mensaje para el usuario.
Para mover la directiva al final de la lista, introduzca <-1>. Para moverla hacia arriba en la lista,
introduzca el número de identificación de la directiva que desea mover.
Haga clic en OK para ejecutar el movimiento.
Si hace clic en la flecha única:
Aparecerá la página “Policy Move” mostrando la directiva que desea mover y una tabla mostrando las
otras directivas.

En la tabla que muestra las otras directivas, la primera columna, “Move Location”, contiene flechas
señalando hacia las diversas ubicaciones a las que puede mover la directiva. Haga clic en la flecha
que apunte a la ubicación en la lista a la que desea mover la directiva.
La página “Policy List” reaparecerá con la directiva movida en su nueva ubicación.
CLI
set policy move id_num { before | after } number
save
Eliminación de una directiva

Además de modificar y cambiar la posición de una directiva, también puede eliminarla. En WebUI, haga clic en
Remove en la columna “Configure” correspondiente a la directiva que desea eliminar. Cuando el sistema le pida
confirmación para proceder con la eliminación, haga clic en Yes . En CLI, utilice el comando unset policy id_num .

Capítulo 7
Asignación de tráfico
7
Este capítulo presenta las múltiples formas de utilizar un dispositivo NetScreen para administrar el ancho de banda
limitado sin comprometer la calidad y disponibilidad de la red de cara a todos los usuarios.
Los temas tratados son:
• “Aplicación de la asignación de tráfico” en la pàgina 360
– “Administración del ancho de banda a nivel de directivas” en la pàgina 360
• “Establecimiento de las prioridades del servicio” en la pàgina 367

Capítulo 7 Asignación de tráfico Aplicación de la asignación de tráfico
APLICACIÓN DE LA ASIGNACIÓN DE TRÁFICO

Por asignación de tráfico se entiende la asignación de la porción apropiada del ancho de banda disponible en la red
a cada usuario y aplicación en una determinada interfaz. Por porción de ancho de banda apropiada se entiende la
combinación óptima entre capacidad de transmisión rentable y calidad de servicio (“Quality of Service” o “QoS”)
garantizada. Los dispositivos NetScreen permiten configurar el tráfico creando directivas y aplicando los controles
de tasa de transmisión apropiados a cada clase de tráfico que pasa por ellos.
Nota: Solamente se puede aplicar la asignación de tráfico a las directivas cuya zona de destino tenga asociada
una única interfaz física. NetScreen no puede realizar asignación de tráfico si la zona de destino contiene una o
más subinterfaces o más de una interfaz física.
Administración del ancho de banda a nivel de directivas

Para clasificar el tráfico, cree una directiva que especifique el ancho de banda garantizado, el ancho de banda
máximo y la prioridad de cada clase de tráfico. El ancho de banda físico de cada interfaz se asigna al parámetro de
ancho de banda garantizado para todas las directivas. Cualquier porción de ancho de banda sobrante es
compartible por cualquier otro tráfico. Es decir, cada directiva obtiene su ancho de banda garantizado y comparte la
porción sobrante (no utilizada) basándose en la prioridad (siendo el límite su ajuste de ancho de banda máximo).
La función de asignación de tráfico es aplicable al tráfico de todas las directivas. Si desactiva la asignación de
tráfico para una directiva específica, pero mantiene activada la asignación de tráfico para otras directivas, el
sistema aplica una directiva de asignación de tráfico predeterminada a esa directiva en particular, con los
parámetros siguientes:
• Ancho de banda garantizado 0
• Ancho de banda máximo ilimitado
• Prioridad de 7 (el ajuste de prioridad más bajo)1
Si no desea que el sistema aplique esta directiva predeterminada a las directivas para las que haya desactivado la
asignación de tráfico, desactive el sistema de asignación de tráfico ejecutando el comando CLI set traffic-shaping
mode off . Puede poner la asignación de tráfico en modo automático: set traffic-shaping mode auto . Esto permite
al sistema activar la asignación de tráfico cuando una directiva la requiera y desactivarla cuando no la requiera.
1. Puede habilitar una correspondencia de los niveles de prioridad de NetScreen al sistema DiffServ Codepoint Marking. Para obtener más información sobre
DS Codepoint Marking, consulte “Asignación de tráfico” en la pàgina 6-327.

Ejemplo: Asignar tráfico

En este ejemplo distribuirá 45 Mbps de ancho de banda de una interfaz T3 entre tres departamentos de la misma
subred. La interfaz ethernet1 está asociada a la zona Trust y ethernet3 a la zona Untrust.

T3–45 Mbps
Marketing: 10 Mbps de entrada, 10 Mbps de salida
Internet
Enrutador Enrutador
Sales: 5 Mbps de entrada, 10 Mbps de salida
DMZ para
servidores Zona DMZ
Support: 5 Mbps de entrada, 5 Mbps de salida
WebUI
1. Ancho de banda en interfaces
2
Traffic Bandwidth: 45000
2. Si no especifica los ajustes de ancho de banda de una interfaz, NetScreen utilizará el ancho de banda físico disponible.

2. Ancho de banda en directivas

Name: Marketing Traffic Shaping
Source Address:
Address Book Entry: (seleccione), Marketing
Service: Any
Action: Permit
3
VPN Tunnel: None
Traffic shaping: (seleccione)
Guaranteed Bandwidth: 10000
Maximum Bandwidth: 15000
Name: Sales Traffic Shaping Policy
Source Address:
Address Book Entry: (seleccione), Sales
Service: Any
3. También puede habilitar la asignación de tráfico en directivas que hagan referencia a túneles VPN.

Action: Permit
Traffic Shaping: (seleccione)
Name: Support Traffic Shaping Policy
Source Address:
Address Book Entry: (seleccione), Support
Service: Any
Action: Permit
Name: Allow Incoming Access to Marketing
Source Address:

Service: Any
Action: Permit
Name: Allow Incoming Access to Sales
Source Address:
Service: Any
Action: Permit

Name: Allow Incoming Access to Support
Source Address:
Service: Any
Action: Permit

CLI
Para habilitar la asignación de tráfico por cada directiva, haga lo siguiente:
4
set interface ethernet1 bandwidth 45000
set policy name “Marketing Traffic Shaping” from trust to untrust marketing any
any permit traffic gbw 10000 priority 0 mbw 15000
set policy name “Sales Traffic Shaping Policy” from trust to untrust sales any
any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Support Traffic Shaping Policy” from trust to untrust support
any any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Marketing” from untrust to trust any
marketing any permit traffic gbw 10000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Sales” from untrust to trust any
sales any permit traffic gbw 5000 priority 0 mbw 10000
set policy name “Allow Incoming Access to Support” from untrust to trust any
support any permit traffic gbw 5000 priority 0 mbw 5000
save
4. Si no especifica los ajustes de ancho de banda de una interfaz, NetScreen utilizará el ancho de banda físico disponible.

Capítulo 7 Asignación de tráfico Establecimiento de las prioridades del servicio
ESTABLECIMIENTO DE LAS PRIORIDADES DEL SERVICIO

La función de asignación de tráfico de los dispositivos NetScreen permite gestionar mediante colas de prioridades
el ancho de banda no asignado al ancho de banda garantizado (o al ancho de banda garantizado no utilizado). La
gestión mediante colas de prioridades es una característica que permite a todos los usuarios y aplicaciones tener
acceso al ancho de banda disponible cuando lo necesiten, asegurando al mismo tiempo que el tráfico importante
pueda transmitirse, incluso a expensas del tráfico menos importante, si fuese necesario. La gestión mediante colas
permite a NetScreen canalizar el tráfico por hasta ocho colas de prioridad. Estas ocho colas son:
• High priority (alta prioridad)
• 2nd priority (2ª prioridad)
• 3rd priority (3ª prioridad)
• 4th priority (4ª prioridad)
• Low priority (baja prioridad, predeterminada)
El ajuste de prioridad de una directiva significa que el ancho de banda aún no garantizado a otras directivas se
introduce en las colas dando preferencia a la alta prioridad y luego a la baja. Las directivas que tengan el mismo
ajuste de prioridad competirán por el ancho de banda según el método denominado “round robin” o “ronda
recíproca”. El dispositivo NetScreen procesa primero todo el tráfico de todas las directivas de alta prioridad, para
luego procesar el tráfico del ajuste de prioridad inmediatamente inferior, etcétera, hasta haber procesado todas las
peticiones de tráfico. Si las peticiones de tráfico superan el ancho de banda disponible, se descarta el tráfico de
menor prioridad.
Precaución: Tenga cuidado de no asignar un ancho de banda superior al admitido por la interfaz. El proceso de
configuración de directivas no impide crear configuraciones incompatibles de directivas. Podría llegar a perder
datos si el ancho de banda garantizado de directivas con la misma prioridad sobrepasa el ancho de banda
establecido en la interfaz.

Si no asigna ningún ancho de banda garantizado, puede utilizar la gestión de colas de prioridades para administrar
todo el tráfico de su red. Es decir, todo el tráfico de alta prioridad se envía antes que cualquier tráfico de 2ª
prioridad, etcétera. El dispositivo NetScreen procesa el tráfico de baja prioridad sólo después de haber procesado el
resto del tráfico.
Ejemplo: Gestionar colas de prioridades

En este ejemplo configurará el ancho de banda garantizado y máximo para tres departamentos: Support, Sales y
Marketing, como sigue:
Tráfico saliente Tráfico entrante Tráfico combinado Prioridad
garantizado garantizado garantizado
Support 5* 5 10 High
Sales 2.5 3.5 6 2
Marketing 2.5 1.5 4 3
Total 10 10 20
*
Megabits por segundo (Mbps)
Si los tres departamentos envían y reciben tráfico simultáneamente a través del cortafuegos de NetScreen, el
dispositivo NetScreen debe asignar 20 Mbps de ancho de banda para satisfacer los requisitos de directivas
garantizados. La interfaz ethernet1 está asociada a la zona Trust y ethernet3 a la zona Untrust.
Zona Trust
Zona Untrust
T3 (45 Mbps)
Support: 5 Mbps de salida, 5 Mbps de entrada, Prioridad alta
Internet
Enrutador Enrutador
Sales: 2,5 Mbps de salida, 3,5 Mbps de entrada, 2ª prioridad
DMZ para
servidores Zona DMZ
Marketing: 2,5 Mbps de salida, 1,5 Mbps de entrada, 3ª prioridad

WebUI
Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en OK :

Name: Sup-out
Source Address:
Service: Any
Action: Permit
Traffic Priority: High priority
DiffServ Codepoint Marking5: (seleccione)
5. “Differentiated Services” (“DS”) es un sistema para etiquetar (o “marcar”) tráfico en una posición dentro de una jerarquía de prioridades. DS Codepoint
Marking establece una correspondencia entre el nivel de prioridad de NetScreen en la directiva y los tres primeros bits de codepoint en el campo “DS” del
encabezado de paquetes IP. Para obtener más información sobre DS Codepoint Marking, consulte “Asignación de tráfico” en la pàgina 327.

Name: Sal-out
Source Address:
Service: Any
Action: Permit
Traffic Priority: 2nd priority
DiffServ Codepoint Marking: Enable
Name: Mar-out
Source Address:
Service: Any
Action: Permit

Traffic Priority: 3rd priority
DiffServ Codepoint Marking: (seleccione)
Name: Sup-in
Source Address:
Service: Any
Action: Permit
Traffic Shaping: (seleccione)
Traffic Priority: High priority

Name: Sal-in
Source Address:
Service: Any
Action: Permit
Traffic Priority: 2nd priority
Name: Mar-in
Source Address:
Service: Any
Action: Permit

Traffic Priority: 3rd priority
CLI
set policy name sup-out from trust to untrust support any any permit traffic
gbw 5000 priority 0 mbw 40000 dscp enable
set policy name sal-out from trust to untrust sales any any permit traffic gbw
2500 priority 2 mbw 40000 dscp enable
set policy name mar-out from trust to untrust marketing any any permit traffic
set policy name sup-in from untrust to trust any support any permit traffic gbw
set policy name sal-in from untrust to trust any sales any permit traffic gbw
set policy name mar-in from untrust to trust any marketing any permit traffic
save


Capítulo 8
Parámetros del sistema

8
Este capítulo se centra en los conceptos relativos a la configuración de los parámetros del sistema que afectan a
las siguientes áreas de un dispositivo de seguridad NetScreen:
• “Compatibilidad con DNS (sistema de nombres de dominio)” en la pàgina 377
– “Consulta DNS” en la pàgina 378
– “Tabla de estado de DNS” en la pàgina 379
– “DNS dinámico” en la pàgina 382
– “División de direcciones del DNS proxy” en la pàgina 385
• “DHCP: Protocolo de configuración dinámica de hosts” en la pàgina 388
– “Servidor DHCP” en la pàgina 390
– “Agente de retransmisión de DHCP” en la pàgina 400
– “Cliente DHCP” en la pàgina 406
– “Propagación de los ajustes TCP/IP” en la pàgina 408
• “PPPoE” en la pàgina 411
– “Múltiples sesiones PPPoE a través de una sola interfaz” en la pàgina 417
– “PPPoE y alta disponibilidad” en la pàgina 422
• “Actualización o degradación de firmware” en la pàgina 423
– “Requisitos para actualizar o degradar firmware del dispositivo” en la pàgina 424
– “Descarga de nuevo firmware” en la pàgina 426
– “Actualización de dispositivos NetScreen en una configuración NSRP” en la pàgina 434
– “Autenticar firmware y archivos DI” en la pàgina 445

Capítulo 8 Parámetros del sistema
• “Descarga y carga de configuraciones” en la pàgina 450

– “Almacenamiento e importación de ajustes” en la pàgina 450
– “Retroactivación (“rollback”) de una configuración” en la pàgina 452
– “Bloqueo del archivo de configuración” en la pàgina 455
• “Establecer Bulk-CLI de NetScreen-Security Manager” en la pàgina 458
• “Claves de licencia” en la pàgina 459
• “Registro y activación de los servicios de suscripción” en la pàgina 461
– “Servicio temporal” en la pàgina 461
– “Paquete de AV, filtrado de URLs y DI incluido con un dispositivo nuevo” en la pàgina 462
– “Actualización de AV, filtrado de URLs y DI en un dispositivo existente” en la pàgina 463
– “Sólo actualización de DI” en la pàgina 464
• “Reloj del sistema” en la pàgina 465
– “Fecha y hora” en la pàgina 465
– “Huso horario” en la pàgina 465
– “NTP” en la pàgina 466

Capítulo 8 Parámetros del sistema Compatibilidad con DNS (sistema de nombres de dominio)
COMPATIBILIDAD CON DNS (SISTEMA DE NOMBRES DE DOMINIO)

El dispositivo NetScreen es compatible con el sistema de nombres de dominio (“Domain Name System” o “DNS”),
que permite utilizar tanto nombres de dominios como direcciones IP para identificar las ubicaciones de una red. Un
servidor DNS mantiene una tabla de direcciones IP asociadas a los correspondientes nombres de dominio. DNS
permite referirse a una ubicación por medio de su nombre de dominio (como www.juniper.net), además de utilizar la
correspondiente dirección IP enrutable, que en el caso de www.juniper.net es 207.17.137.68. Todos los programas
siguientes pueden realizar traducción de DNS:
• Address Book (libreta de direcciones)
• Syslog
• E-mail (correo electrónico)
• WebTrends
• Websense
• LDAP
• SecurID
• RADIUS
• NetScreen-Security Manager
Antes de poder utilizar DNS para la resolución de nombres de dominio y direcciones, deben introducirse las
direcciones de los servidores DNS (principal y secundario) en el dispositivo NetScreen.
Nota: Para habilitar el dispositivo NetScreen como servidor del protocolo de configuración dinámica de hosts
(“Dynamic Host Configuration Protocol” o “DHCP”) (consulte “DHCP: Protocolo de configuración dinámica de
hosts” en la pàgina 388), también deberá introducir las direcciones IP de los servidores DNS en la página “DHCP”
de WebUI o mediante el comando CLI set interface interfaz dhcp.

Consulta DNS
El dispositivo NetScreen actualiza todas las entradas de su tabla DNS comprobándolas en un servidor DNS
especificado en los momentos siguientes:
• Al producirse una conmutación por fallo de HA (alta disponibilidad)
• A una hora determinada y a intervalos regulares programados a lo largo del día
• Cuando se ordena manualmente al dispositivo realizar una consulta DNS
– WebUI: Network > DNS: Haga clic en “Refresh DNS cache”.
– CLI: exec dns refresh
Además del método existente de establecer una hora para la actualización diaria y automática de la tabla DNS,
también puede definir un intervalo de tiempo entre 4 y 24 horas.
Nota: Cuando se agrega un nombre de dominio completo (“Fully-Qualified Domain Name” o “FQDN”), como una
dirección o una puerta de enlace IKE, mediante WebUI, el dispositivo NetScreen lo resuelve al hacer clic en Apply
o en OK. Cuando se escribe un comando CLI que hace referencia a un FQDN, el dispositivo NetScreen intenta
resolverlo en el momento de introducirlo.
Cuando el dispositivo NetScreen se conecta al servidor DNS para resolver una asignación de nombre de dominio o
dirección IP, almacena esa entrada en su tabla de estado de DNS. La lista siguiente contiene algunos de los
detalles implicados en una consulta DNS:
• Cuando una consulta DNS devuelve varias entradas, la libreta de direcciones acepta todas. Los otros
programas enumerados en la pàgina 377 solamente aceptan la primera.
• El dispositivo NetScreen reinstala todas las directivas si detecta cualquier cambio en la tabla de nombres
de dominios en el momento en que el usuario actualiza una consulta con el botón Refresh de WebUI o
ejecuta el comando CLI exec dns refresh.
• Cuando falla un servidor DNS, el dispositivo NetScreen vuelve a consultar la tabla entera.
• Cuando falla una consulta, el dispositivo NetScreen la elimina de la tabla caché.
• Si la consulta del nombre de dominio falla al agregar direcciones a la libreta de direcciones, el dispositivo
NetScreen muestra un mensaje de error indicando que la dirección fue agregada con éxito, pero la consulta
del nombre DNS falló.

El dispositivo NetScreen debe realizar una nueva consulta cada día, que se puede programar en el dispositivo
NetScreen para que la realice a una hora determinada:
WebUI
Network > DNS: Introduzca los siguientes datos y haga clic en Apply :
DNS refresh every day at: Seleccione la casilla de verificación e introduzca la
hora <hh:mm>
CLI
set dns host schedule time_str
save
Tabla de estado de DNS

La tabla de estado de DNS comunica todos los nombres de dominios consultados, sus correspondientes
direcciones IP, si la consulta se efectuó con éxito y cuándo se resolvió por última vez cada nombre de dominio o
dirección IP. El formato del informe se parece al ejemplo siguiente:
Name IP Address Status Last Lookup

www.yahoo.com 204.71.200.74 Success 8/13/2000 16:45:33
204.71.200.75
204.71.200.67
204.71.200.68
www.hotbot.com 209.185.151.28 Success 8/13/2000 16:45:38
209.185.151.210
216.32.228.18

Para visualizar la tabla de estado de DNS, ejecute cualquiera de los siguientes procedimientos:
WebUI
Network > DNS > Show DNS Table
CLI
get dns host report
Ejemplo: Servidor DNS y programación de actualizaciones

Para implementar la funcionalidad de DNS, se introducen en el dispositivo NetScreen las direcciones IP de los
servidores DNS en 24.1.64.38 y 24.0.0.3, protegiendo un host único de una oficina doméstica. El dispositivo
NetScreen se programa para actualizar los ajustes de DNS almacenados en su tabla de estado de DNS
diariamente a las 23:00 horas.
Servidor DNS secundario

24.1.64.38
Zona Trust Zona Untrust Servidor DNS principal
24.0.0.3
Internet
WebUI
Primary DNS Server: 24.0.0.3
Secondary DNS Server: 24.1.64.38
DNS Refresh: (seleccione)
Every Day at: 23:00

CLI
set dns host dns1 24.0.0.3
set dns host dns2 24.1.64.38
set dns host schedule 23:00
save
Ejemplo: Establecer un intervalo de actualización de DNS

En este ejemplo configurará el dispositivo NetScreen para actualizar su tabla DNS cada 4 horas, comenzando a las
00:01 de cada día.
WebUI
DNS Refresh: (seleccione)
Every Day at: 00:01
Interval: 4
CLI
set dns host schedule 00:01 interval 4
save

DNS dinámico
DNS dinámico (DDNS) es un mecanismo que permite a los clientes actualizar dinámicamente las direcciones IP
correspondientes a nombres de dominio registrados. Esta actualización es útil cuando un ISP utiliza PPP, DHCP o
XAuth para modificar dinámicamente la dirección IP de un enrutador CPE (como un dispositivo NetScreen) que
proteja un servidor web. Así, los clientes procedentes de Internet pueden acceder el servidor web usando un
nombre de dominio, aunque la dirección IP del enrutador CPE haya cambiado previamente. Este cambio es posible
gracias a un servidor DDNS como dyndns.org o ddo.jp, que contienen las direcciones cambiadas dinámicamente y
sus nombres de dominio asociados. El CPE actualiza los servidores DDNS con esta información, periódicamente o
en respuesta a cambios de direcciones IP.
Para utilizar DDNS, cree una cuenta (nombre de usuario y contraseña) en el servidor DDNS. El servidor utiliza esta
información de cuenta para configurar el dispositivo cliente.
Servidor web
Cliente www.my_host.com
(enrutador CPE)
Zona Trust
Internet
Servidor DDNS
ethernet7
dyndns.org or
ddo.jp
Nota: La zona Untrust no se muestra.
En el diagrama mostrado arriba, la dirección IP de la interfaz ethernet7 puede haber cambiado. Cuando se produce
algún cambio, el cliente todavía puede acceder al servidor web protegido indicando el nombre de host
(www.my_host.com), a través del servidor de dyndns.org o del servidor de ddo.jp. Cada uno de estos servidores
requiere configuraciones algo diferentes en el dispositivo NetScreen.

Ejemplo: Configuración de DDNS para el servidor dyndns

En el ejemplo siguiente configurará un dispositivo NetScreen para operar con DDNS. El dispositivo utiliza el
servidor dyndns.org para resolver direcciones que se han cambiado. Para este servidor, especificará el host
protegido utilizando el ajuste Host Name, asociado explícitamente a la interfaz DNS (ethernet7); por lo tanto,
cuando el dispositivo envía una actualización al servidor de ddo.jp, asocia Host Name a la dirección IP de la
interfaz.
WebUI
Network > DNS > DDNS > New: Introduzca los siguientes datos y haga clic en OK:
ID: 12
Server Settings:
Server Type: dyndns
Server Name: dyndns.org
Refresh Interval: 24
Minimum Update Interval: 151
Account Settings:
Username: swordfish
Password: ad93lvb
Bind to Interface: ethernet7
Host Name: www.my_host.com
1. Este ajuste especifica el intervalo mínimo de tiempo (expresado en minutos) entre sucesivas actualizaciones de DDNS. El valor predeterminado es de 10
minutos y el rango admisible es 1-1440. En algunos casos, el dispositivo puede no actualizar el intervalo porque primero el servidor DNS necesita esperar
a que el tiempo de espera de la entrada de DDNS caduque en su caché. Además, si establece el intervalo de acutalización mínimo a un valor muy bajo,
puede que el dispositivo NetScreen le bloquee el acceso; por lo tanto, recomendamos utilizar un valor de al menos 10 minutos.

CLI
set dns ddns
set dns ddns enable
set dns ddns id 12 server dyndns.org server-type dyndns refresh-interval 24
minimum-update-interval 15
set dns ddns id 12 src-interface ethernet7 host-name www.my_host.com
set dns ddns id 12 username swordfish password ad93lvb
save
Ejemplo: Configuración de DDNS para el servidor de ddo

En el ejemplo siguiente configurará un dispositivo NetScreen para DDNS. El dispositivo utiliza el servidor ddo.jp
para resolver direcciones. Para el servidor ddo.jp, especificará el FQDN del host protegido como nombre de usuario
para la entrada de DDNS, en lugar de especificar el host protegido usando el ajuste Host Name. El servicio
deducirá automáticamente el nombre de host del valor de Username. Por ejemplo, el servidor ddo.jp traduce un
nombre de usuario de my_host a my_host.ddo.jp. Cerciórese de que el nombre de dominio registrado en ddo.jp
coincida con el DNS deducido.
WebUI
Network > DNS > DDNS > New: Introduzca los siguientes datos y haga clic en OK:
ID: 25
Server Settings:
Server Type: ddo
Server Name: juniper.net
Refresh Interval: 24
Minimum Update Interval: 15
Account Settings:
Username: my_host
Password: ad93lvb
Bind to Interface: ethernet7

CLI
set dns ddns
set dns ddns enable
set dns ddns id 25 server ddo.jp server-type ddo refresh-interval 24
minimum-update-interval 15
set dns ddns id 25 src-interface ethernet7
set dns ddns id 25 username my_host password ad93lvb
save
División de direcciones del DNS proxy

La característica DNS proxy proporciona un mecanismo transparente que permite a los clientes dividir consultas
DNS. Con esta técnica, el proxy redirige selectivamente las consultas de DNS a servidores DNS específicos,
siguiendo nombres de dominio parciales o completos. Esto resulta útil cuando los túneles VPN o los enlaces
virtuales PPPoE proporcionan conectividad a múltiple redes y es necesario dirigir algunas consultas DNS a una red
y otras a otra red.
Las ventajas más importantes de un proxy de DNS son las siguientes.
• Las operaciones de búsqueda de dominios son generalmente más eficientes. Por ejemplo, las consultas de
DNS destinadas al dominio corporativo (como acme.com) podrían dirigirse al servidor DNS corporativo,
mientras que todas las demás irían al servidor DNS del ISP, reduciendo la carga en el servidor corporativo.
Esto también impediría la filtración de información del dominio corporativo a Internet.
• El proxy de DNS permite transmitir consultas DNS seleccionadas a través de una interfaz de túnel,
impidiendo así que usuarios malévolos puedan acceder a la configuración de la red interna. Por ejemplo,
las consultas de DNS dirigidas al servidor corporativo pueden atravesar una interfaz de túnel y utilizar
características de seguridad tales como la autenticación, codificación y “anti-replay” (anti-reprocesamiento).

Ejemplo: Dividir peticiones de DNS

Los comandos siguientes crean dos entradas DNS por proxy que reenvían selectivamente las consultas DNS a
diferentes servidores.
Servidores DNS del ISP
netscreen.com => 63.126.135.170 netscreen.com
Internet
1.1.1.23 63.126.135.170
acme.com => acme_eng.com =>

ethernet3 3.1.1.2 3.1.1.5
tunnel.1 Servidores DNS

de la empresa
2.1.1.21
acme.com
* 2.1.1.34
acme_eng.com
• Toda consulta de DNS con un FQDN que contenga el nombre de dominio acme.com saldrá a través de la
interfaz de túnel tunnel.1 al servidor DNS corporativo en la dirección IP 2.1.1.21.
Por ejemplo, si un host envía una consulta DNS para resolver www.acme.com, el dispositivo dirige
automáticamente la consulta a este servidor. (En este ejemplo, asuma que el servidor resuelve la consulta
devolviendo la dirección IP 3.1.1.2).
• Cualquier consulta DNS con un FQDN que contenga el nombre de dominio acme_engineering.com sale a
través de interfaz de túnel tunnel.1 al servidor DNS en la dirección IP 2.1.1.34.
Por ejemplo, si un host envía una consulta DNS para resolver intranet.acme_eng.com, el dispositivo dirige
la consulta a este servidor. (En este ejemplo, asuma que el servidor resuelve la consulta devolviendo la
dirección IP 3.1.1.5).
• Todas las demás consultas DNS (marcadas con un asterisco) evitan a los servidores corporativos y salen a
través de la interfaz ethernet3 al servidor DNS en la dirección IP 1.1.1.23.
Por ejemplo, si el host y el nombre de dominio son www.juniper.net, el dispositivo evita automáticamente
los servidores corporativos y dirige la consulta a este servidor, que resuelve la consulta obteniendo la
dirección IP 207.17.137.68.

WebUI
1. Network > DNS > Proxy: Introduzca los siguientes datos y haga clic en Apply :
Initialize DNS Proxy: Enable
Enable DNS Proxy: Enable
2. Network > DNS > Proxy > New: Introduzca los siguientes datos y haga clic en OK :
Domain Name: acme.com
Outgoing Interface: tunnel.1
Domain Name: acme_eng.com
Outgoing Interface: tunnel.1
Domain Name: *
Outgoing Interface: ethernet3
CLI
set dns proxy
set dns proxy enable
set interface ethernet3 proxy dns
set dns server-select domain acme.com outgoing-interface tunnel.1
primary-server 2.1.1.21
set dns server-select domain acme_eng.com outgoing-interface tunnel.1
primary-server 2.1.1.34
set dns server-select domain * outgoing-interface ethernet3 primary-server
1.1.1.23
save

Capítulo 8 Parámetros del sistema DHCP: Protocolo de configuración dinámica de hosts
DHCP: PROTOCOLO DE CONFIGURACIÓN DINÁMICA DE HOSTS

El protocolo de configuración dinámica de hosts (DHCP: “Dynamic Host Configuration Protocol”) fue diseñado para
aliviar el trabajo de los administradores de red asignando automáticamente ajustes TCP/IP a los hosts de una red.
En lugar de obligar a los administradores a asignar, configurar, supervisar y modificar (cuando sea necesario) todos
los ajustes TCP/IP de cada equipo de una red, DHCP hace todo automáticamente. Además, DHCP garantiza que
no se utilicen direcciones duplicadas, vuelve a asignar las direcciones que han dejado de utilizarse y asigna
automáticamente direcciones IP apropiadas para la subred a la que está conectado un host.
Diferentes dispositivos NetScreen asumen diferentes papeles DHCP:
• Cliente DHCP: Algunos dispositivos NetScreen pueden actuar como clientes de DHCP, recibiendo una
dirección IP asignada dinámicamente para cualquier interfaz física en cualquier zona.
• Servidor DHCP: Algunos dispositivos NetScreen también pueden actuar como servidores de DHCP,
asignando direcciones IP dinámicas a hosts (que actúan como clientes de DHCP) en cualquier interfaz
física o VLAN de cualquier zona.
Nota: Aunque utilice el módulo del servidor DHCP para asignar direcciones a hosts tales como las
estaciones de trabajo de una zona, también puede utilizar direcciones IP fijas para otros equipos, como
servidores de correo y servidores WINS.
• Agente de retransmisión de DHCP: Algunos dispositivos NetScreen también pueden actuar como
agentes de retransmisión de DHCP, recibiendo información de un servidor DHCP y retransmitiéndola a los
hosts de cualquier interfaz física o VLAN en cualquiera zona.
• Cliente/servidor/agente de retransmisión DHCP: Algunos dispositivos NetScreen pueden actuar
simultáneamente como cliente, servidor y agente de retransmisión de DHCP. Observe que en una sola
interfaz solamente se puede configurar un papel de DHCP. Por ejemplo, en la misma interfaz no se pueden
configurar el cliente y el servidor DHCP. Opcionalmente, se puede configurar el módulo de cliente DHCP
para que reenvíe los ajustes TCP/IP que recibe al módulo de servidor DHCP, que los utilizará para
proporcionar ajustes TCP a los hosts de la zona Trust que actúen como clientes DHCP.

DHCP consta de dos componentes: un protocolo para suministrar ajustes de configuración TCP/IP específicos de
cada host y un mecanismo para asignar direcciones IP. Cuando el dispositivo NetScreen actúa como servidor
DHCP, proporciona los siguientes ajustes TCP/IP a cada host cuando éste se inicia:
• Dirección IP y máscara de red predeterminadas de la puerta de enlace. Si deja estos ajustes como
0.0.0.0/0, el módulo del servidor DHCP utiliza automáticamente la dirección IP y la máscara de red de la
2
interfaz predeterminada de la zona Trust .
• Las direcciones IP de los servidores siguientes:
3
– Servidores WINS (2): Los servidores del servicio de nombres de Internet de Windows (“Windows
Internet Naming Service” o “WINS”) asignan un nombre NetBIOS utilizado en un entorno de red
Windows NT a una dirección IP utilizada en una red basada en IP.
– Servidores NetInfo (2): NetInfo es un servicio de red de Apple utilizado para la distribución de datos
administrativos dentro de una LAN.
– Etiqueta de NetInfo (1): La etiqueta identificativa utilizada por la base de datos de Apple NetInfo.
– Servidores DNS (3): Los servidores del sistema de nombres de dominio (“DNS”) asignan un
localizador de recurso uniforme (“Uniform Resource Locator” o “URL”) a una dirección IP.
– Servidor SMTP (1): Los servidores del protocolo simple de transferencia de correo (“Simple Mail
Transfer Protocol” o “SMTP”) entregan mensajes SMTP a un servidor de correo, por ejemplo un
servidor POP3, que almacena el correo entrante.
– Servidor POP3 (1): Los servidores del protocolo de oficina de correo, versión 3 (“Post Office Protocol”
o “POP3”) almacenan el correo entrante. Cada servidor POP3 debe trabajar conjuntamente con un
servidor SMTP.
– Servidor News (1): Los servidores de noticias reciben y almacenan avisos de los grupos de noticias.
Nota: Si un cliente DHCP al que el dispositivo NetScreen entrega los parámetros antedichos dispone de
una dirección IP especificada, ésta tiene preferencia sobre toda la información dinámica recibida del
servidor DHCP.
2. En los dispositivos que pueden tener varias interfaces asociadas a la zona Trust, la interfaz predeterminada es la primera interfaz asociada a esa zona a la
que se haya asignado una dirección IP.
3. El número en paréntesis indica el número de servidores admitidos.

Servidor DHCP
Un dispositivo NetScreen puede admitir hasta ocho servidores DHCP en cualquier interfaz física o VLAN de
cualquier zona. Cuando actúa como servidor DHCP, el dispositivo NetScreen asigna direcciones IP y máscaras de
subred de dos modos:
• En el modo dinámico, el dispositivo NetScreen, actuando como servidor DHCP, asigna (o “arrienda”) a un
4
cliente DHCP del host una dirección IP tomada de un conjunto de direcciones. La dirección IP se arrienda
por un tiempo determinado o hasta que el cliente renuncia a ella. (Para definir un periodo de arrendamiento
ilimitado, introduzca 0).
• En el modo reservado, el dispositivo NetScreen asigna una dirección IP tomada de un conjunto de
direcciones exclusivamente para un cliente específico cada vez que éste establece una conexión.
Nota: El dispositivo NetScreen guarda cada dirección IP asignada mediante DHCP en su memoria flash.
Por lo tanto, el reinicio del dispositivo NetScreen no afecta a las asignaciones de direcciones.
Ejemplo: Dispositivo NetScreen como servidor DHCP

Utilizando DHCP, se seccionará la red 172.16.10.0/24 de la zona Trust en tres conjuntos de direcciones IP.
• 172.16.10.10 a 172.16.10.19
• 172.16.10.120 a 172.16.10.129
• 172.16.10.210 a 172.16.10.219
El servidor DHCP asigna todas las direcciones IP dinámicamente, salvo a dos estaciones de trabajo con
direcciones IP reservadas y a cuatro servidores que tienen direcciones IP estáticas. La interfaz ethernet1 está
asociada a la zona Trust, tiene la dirección IP 172.16.10.1/24 y se encuentra en modo NAT. El nombre del dominio
es dynamic.com.
4. Un conjunto de direcciones es un rango de direcciones IP definido en la misma subred de la que el dispositivo NetScreen puede tomar direcciones DHCP
para asignar. Puede agrupar hasta 255 direcciones IP.

Servidores DNS
Direcciones IP fijas
Zona Trust 172.16.10.240
ethernet1
172.16.10.241
172.16.10.1/24 (NAT)
Conjunto de direcciones 172.16.10.0/24 Conjunto de direcciones

172-16.10.10 – LAN 172-16.10.210 –
172.16.10.19 172.16.10.219
Conjunto de
direcciones
IP reservada 172-16.10.120 –
172.16.10.11 172.16.10.129 Servidores SMTP y POP3
MAC: 12:34:ab:cd:56:78 Direcciones IP fijas
172.16.10.25 y 172.16.10.10
IP reservada
172.16.10.112
MAC: ab:cd:12:34:ef:gh
WebUI
1. Direcciones
Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK:
Address Name: DNS#1
Comment: Primary DNS Server
Zone: Trust

Address Name: DNS#2
Comment: Secondary DNS server
Zone: Trust
Address Name: SMTP
Comment: SMTP Server
Zone: Trust
Address Name: POP3
Comment: POP3 server
Zone: Trust

2. Servidor DHCP
Network > DHCP > Edit (para ethernet1) > DHCP Server: Introduzca los siguientes datos y haga clic en
5
Apply:
Lease: Unlimited (seleccione)
WINS#1: 0.0.0.0
DNS#1: 172.16.10.240
> Advanced Options: Escriba lo siguiente y haga clic en Return para
establecer las opciones avanzadas y regresar a la página de configuración
básica:
WINS#2: 0.0.0.0
DNS#2: 172.16.10.241
DNS#3: 0.0.0.0
SMTP: 172.16.10.25
POP3: 172.16.10.110
NEWS: 0.0.0.0
NetInfo Server # 1: 0.0.0.0
NetInfo Server # 2: 0.0.0.0
NetInfo Tag: (deje el campo vacío)
Domain Name: dynamic.com
> Addresses > New: Introduzca los siguientes datos y haga clic en OK :
Dynamic: (seleccione)
IP Address Start: 172.16.10.10
IP Address End: 172.16.10.19
5. Si deja los campos “Gateway” y “Netmask” como 0.0.0.0, el módulo de servidor DHCP envía la dirección IP y máscara de red establecida para ethernet1 a
sus clientes (172.16.10.1 y 255.255.255.0 en este ejemplo). Sin embargo, si habilita el módulo de cliente DHCP para que reenvíe ajustes de TCP/IP al
módulo del servidor DHCP (consulte “Propagación de los ajustes TCP/IP” en la pàgina 408), deberá introducir manualmente 172.16.10.1 y 255.255.255.0
en los campos “Gateway” y “Netmask”.

Reserved: (seleccione)
Dirección IP: 172.16.10.11
Ethernet Address: 1234 abcd 5678
Reserved: (seleccione)
Dirección IP: 172.16.10.112
Ethernet Address: abcd 1234 efgh

CLI
1. Direcciones
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
set address trust snmp 172.16.10.25/32 “snmp server”
set address trust pop3 172.16.10.110/32 “pop3 server”
2. Servidor DHCP
6
set interface ethernet1 dhcp server option domainname dynamic.com
set interface ethernet1 dhcp server option lease 0
set interface ethernet1 dhcp server option dns1 172.16.10.240
set interface ethernet1 dhcp server option smtp 172.16.10.25
set interface ethernet1 dhcp server option pop3 172.16.10.110
set interface ethernet1 dhcp server ip 172.16.10.10 to 172.16.10.19
set interface ethernet1 dhcp server ip 172.16.10.11 mac 1234abcd5678
set interface ethernet1 dhcp server ip 172.16.10.112 mac abcd1234efgh
set interface ethernet1 dhcp server service
save
6. Si no establece una dirección IP para la puerta de enlace o una máscara de red, el módulo del servidor DHCP envía a sus clientes la dirección IP y máscara
de red para ethernet1 (172.16.10.1 y 255.255.255.0 en este ejemplo). Sin embargo, si habilita el módulo de cliente DHCP para reenviar ajustes TCP/IP al
módulo del servidor DHCP (consulte “Propagación de los ajustes TCP/IP” en la pàgina 408), deberá establecer manualmente estas opciones: set interface
ethernet1 dhcp server option gateway 172.16.10.1 y set interface ethernet1 dhcp server option netmask 255.255.255.0 .

Opciones del servidor DHCP

Al especificar servidores DHCP para una interfaz, puede necesitar especificar ciertas opciones que identifiquen a
los servidores o proporcionen la información utilizada por éstos. Por ejemplo, puede especificar la dirección IP de
los servidores DNS primario y secundario, o bien establecer el tiempo de asignación (“lease time”) de la dirección
IP.
Los siguientes son servicios DHCP predefinidos, según se describe en RFC 2132, “DHCP Options and BOOTP
Vendor Extensions”.
Terminología Terminología de CLI de NetScreen Código de opción

Subnet Mask netmask 1
Router Option gateway 3
Domain Name Server dns1, dns2, dns3 6
Domain Name domainname 15
NetBIOS over TCP/IP wins1, wins2 44
Name Server Option
IP Address Lease Time lease 51
SMTP Server Option smtp 69
POP3 Server Option pop3 70
NNTP Server Option news 71
(N/D) nis1, nis2 112
(N/D) nistag 113
En situaciones en la que las opciones predefinidas del servidor no son suficientes, puede definir opciones de
servidor DHCP personalizadas. Por ejemplo, para ciertas configuraciones de VoIP (voz sobre IP), es necesario
enviar información adicional de configuración que no es reconocida por las opciones predefinidas del servidor. En
tales casos, debe definir opciones personalizadas apropiadas.

Ejemplo: Opciones de servidor DHCP personalizadas

En el ejemplo siguiente creará definiciones de servidor DHCP para teléfonos IP que actúan como clientes DHCP.
Los teléfonos utilizan las opciones personalizadas siguientes:
• Código de opción 444, conteniendo la cadena “Server 4”
• Código de opción 66, conteniendo la dirección IP 1.1.1.1
• Código de opción 160, conteniendo el número entero 2004
CLI
1. Direcciones
set address trust dns1 172.16.10.240/32 “primary dns server”
set address trust dns2 172.16.10.241/32 “secondary dns server”
2. Servidor DHCP
set interface ethernet1 dhcp server option domainname dynamic.com
set interface ethernet1 dhcp server option custom 444 string “Server 4”
set interface ethernet1 dhcp server option custom 66 ip 1.1.1.1
set interface ethernet1 dhcp server option custom 160 integer 2004
Servidor DHCP en un clúster de NSRP

Cuando la unidad maestra de un clúster NSRP redundante actúa como servidor DHCP, todos los miembros del
clúster mantienen todas las configuraciones DHCP y asignaciones de direcciones IP. En caso de una conmutación
por error, la nueva unidad maestra mantiene todas las asignaciones de DHCP. Sin embargo, la finalización de la
comunicación HA interrumpe la sincronización de las asignaciones DHCP existentes entre miembros del clúster.
Una vez restablecida la comunicación de HA, puede resincronizar las asignaciones de DHCP mediante el siguiente
comando CLI en ambas unidades del clúster: set nsrp rto-mirror sync .

Detección del servidor DHCP

Cuando se inicia un servidor DHCP de un dispositivo NetScreen, el sistema puede comprobar primero si la interfaz
ya tiene un servidor DHCP. ScreenOS impide automáticamente que se inicie el proceso del servidor DHCP local si
detecta la presencia de otro servidor DHCP en la red. Para detectar otro servidor DHCP, el dispositivo envía
peticiones de arranque DHCP en intervalos de 2 segundos. Si el dispositivo no recibe ninguna respuesta a sus
peticiones de arranque, inicia su proceso local de servidor DHCP.
Si el dispositivo NetScreen recibe una respuesta de otro servidor DHCP, el sistema genera un mensaje indicando
que el servicio DHCP está habilitado en el dispositivo NetScreen, pero no se ha iniciado porque hay otro servidor
DHCP presente en la red. El mensaje del registro incluye la dirección IP del servidor DHCP existente.
Para detectar la presencia de un servidor DHCP en una interfaz, puede utilizarse uno de los tres modos de
7
funcionamiento siguientes: “Auto”, “Enable” o “Disable” . En el modo “Auto”, el dispositivo NetScreen comprueba si
hay algún servidor DHCP presente siempre que arranca. Puede configurar el dispositivo para que no intente
detectar otro servidor DHCP en una interfaz activando el modo “Enable” o “Disable” del servidor DHCP de
NetScreen. En el modo “Enable”, el servidor DHCP está siempre encendido y el dispositivo no comprueba si hay
algún servidor DHCP en la red. En el modo “Disable”, el servidor DHCP está siempre apagado.
7. “Auto” es el modo predeterminado de detección de servidores DHCP en dispositivos NetScreen-5XP y NetScreen-5XT. En otros dispositivos NetScreen
que admitan el servidor DHCP, el modo “Enable” es el modo predeterminado de detección de servidores DHCP.

Ejemplo: Activar la detección de servidores DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet1 para que, antes de iniciarse, compruebe si
hay algún servidor DHCP en la interfaz.
WebUI
OK :
Server Mode: Auto (seleccione)
CLI
set interface ethernet1 dhcp server auto
save
Ejemplo: Desactivar la detección de servidores DHCP

En este ejemplo configurará el servidor DHCP de la interfaz ethernet1 para que se inicie sin comprobar si hay algún
servidor DHCP existente en la red.
WebUI
OK :
Server Mode: Enable (seleccione)
CLI
set interface ethernet1 dhcp server enable
save
Nota: El servidor DHCP se puede activar ejecutando el comando CLI set interface interface dhcp server
service . Si el modo de detección del servidor DHCP establecido para la interfaz es “Auto”, el servidor DHCP del
dispositivo NetScreen solamente se inicia si no encuentra un servidor existente en la red. Con el comando unset
interface interface dhcp server service se inhabilita el servidor DHCP en el dispositivo NetScreen y también se
elimina cualquier configuración DHCP.

Agente de retransmisión de DHCP

Cuando actúa como agente de retransmisión de DHCP, el dispositivo NetScreen reenvía peticiones y asignaciones
DHCP entre los hosts de una zona y el servidor DHCP de otra zona. Los mensajes DHCP entre el dispositivo
NetScreen y el servidor DHCP se pueden transmitir en abierto o a través de un túnel VPN.
Puede configurar un agente de retransmisión de DHCP en una o más interfaces físicas o VLAN de un dispositivo
NetScreen, aunque no puede configurar un agente de retransmisión de DHCP y funciones de servidor o cliente
DHCP en la misma interfaz. Cuando el dispositivo NetScreen funciona como agente de retransmisión de DHCP,
sus interfaces deben estar en el modo de ruta (“Route”) o transparente (“Transparent”). Para las interfaces en el
modo de ruta es necesario configurar una directiva interzonal para el servicio predefinido DHCP-Relay. Para las
interfaces en el modo transparente, el cliente DHCP debe residir en la zona V1-Trust, mientras que el servidor
DHCP puede residir en la zona V1-Untrust o V1-DMZ. Para las interfaces en modo transparente no se requiere
ninguna directiva.
Se pueden configurar hasta tres servidores DHCP para cada agente de retransmisión de DHCP. El agente de
retransmisión envía una petición de dirección procedente de un cliente DHCP a todos los servidores DHCP
configurados. El agente de retransmisión reenvía al cliente la primera respuesta recibida de un servidor.
Nota: Cuando un dispositivo NetScreen actúa como agente de retransmisión de DHCP, no genera informes
sobre el estado de asignación de DHCP porque el servidor DHCP remoto controla todas las asignaciones de
direcciones IP.
La siguiente ilustración simplificada presenta el proceso de utilización de un dispositivo NetScreen como agente de
retransmisión de DHCP. Observe que, para garantizar la seguridad, los mensajes DHCP atraviesan un túnel VPN a
su paso por la red no fiable.

Host Zona Agente de Túnel VPN en la Servidor

Trust retransmisión zona Untrust DHCP
1
Petición Petición
2 Asignación Asignación
3 Liberación Liberación
Ejemplo: Dispositivo NetScreen como agente de retransmisión de DHCP

En este ejemplo, un dispositivo NetScreen recibe su información DHCP de un servidor DHCP en 194.2.9.10 y la
retransmite a los hosts en la zona Trust. Los hosts reciben direcciones IP de un conjunto de direcciones IP definido
en el servidor DHCP. El rango de direcciones es 180.10.10.2—180.10.10.254. Los mensajes DHCP pasan a través
de un túnel VPN entre el dispositivo NetScreen local y el servidor DHCP, situado detrás de un dispositivo NetScreen
remoto cuya dirección IP en la interfaz de la zona Untrust es 2.2.2.2/24. La interfaz ethernet1 está asociada a la
zona Trust, tiene la dirección IP 180.10.10.1/24 y está en modo de ruta. La interfaz ethernet3 está asociada a la
zona Untrust y tiene la dirección IP 1.1.1.1/24. Todas las zonas de seguridad se encuentran en el dominio de
enrutamiento trust-vr.


ethernet1 ethernet3 DHCP
180.10.10.1/24 1.1.1.1/24 Servidor
194.2.9.10
Internet Dispositivo
Dispositivo NetScreen local NetScreen remoto
Túnel VPN
Agente de Enrutador
retransmisión de DHCP 1.1.1.250
Conjunto de
direcciones IP
180.10.10.2 –
180.10.10.254
WebUI
1. Interfaces
Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply :
Zone: Trust

Zone: Untrust

2. Dirección
Address Name: DHCP Server
Zone: Untrust
3. VPN
VPNs > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK :
Gateway Name: dhcp server
Security Level: Custom
Remote Gateway Type:
Static IP: (seleccione), Address/Hostname: 2.2.2.2
Outgoing Interface: ethernet3
Security Level:
User Defined: Custom (seleccione)
Phase1 Proposal: rsa-g2-3des-sha
Mode (Initiator): Main (ID Protection)
VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK :
VPN Name: to_dhcp
Security Level: Compatible
Remote Gateway:
Predefined: (seleccione), to_dhcp
Bind to: None

4. Agente de retransmisión de DHCP

Network > DHCP > Edit (para ethernet1) > DHCP Relay Agent: Introduzca los siguientes datos y haga clic
en Apply :
Relay Agent Server IP or Domain Name: 194.2.9.10
Use Trust Zone Interface as Source IP for VPN: (seleccione)
5. Ruta
6. Directivas
Source Address:
Address Book Entry: (seleccione), DHCP Server
Service: DHCP-Relay
Action: Tunnel
Tunnel VPN: to_dhcp
Modify matching outgoing VPN policy: (seleccione)
8. Establecer una ruta al enrutador externo designado como puerta de enlace predeterminada es esencial tanto para el tráfico VPN saliente como para el de
red. En este ejemplo, el dispositivo NetScreen envía tráfico VPN encapsulado a este enrutador como primer salto a lo largo de su ruta al dispositivo
NetScreen remoto. En la ilustración de este ejemplo, el concepto aparece representando como túnel atravesando el enrutador.

CLI
1. Interfaces
2. Dirección
set address untrust dhcp_server 194.2.9.10/32
3. VPN
set ike gateway “dhcp server” ip 2.2.2.2 main outgoing-interface ethernet3
proposal rsa-g2-3des-sha
set vpn to_dhcp gateway “dhcp server” proposal g2-esp-3des-sha
4. Agente de retransmisión de DHCP
set interface ethernet1 dhcp relay server-name 194.2.9.10
set interface ethernet1 dhcp relay vpn
5. Ruta
6. Directivas
set policy from trust to untrust any dhcp_server dhcp-relay tunnel vpn to_dhcp
set policy from untrust to trust dhcp_server any dhcp-relay tunnel vpn to_dhcp
save

Cliente DHCP
Cuando actúa como cliente DHCP, el dispositivo NetScreen recibe una dirección IP dinámicamente de un servidor
DHCP para cualquier interfaz física en cualquier zona de seguridad. Si hay varias interfaces asociadas a una sola
zona de seguridad, puede configurar un cliente DHCP para cada interfaz, siempre que ninguna de ellas esté
conectada al mismo segmento de red. Si configura un cliente DHCP para dos interfaces conectadas al mismo
segmento de red, se utilizará la primera dirección asignada por un servidor DHCP. (Si el cliente DHCP recibe una
actualización de dirección para la misma dirección IP, IKE no se reencripta).
Nota: Aunque algunos dispositivos NetScreen pueden actuar como servidor DHCP, agente de retransmisión
de DHCP o cliente DHCP al mismo tiempo, en una misma interfaz no se puede configurar más de un papel
de DHCP.
Ejemplo: Dispositivo NetScreen como cliente DHCP

En este ejemplo, la interfaz asociada a la zona Untrust tiene una dirección IP asignada dinámicamente. Cuando el
dispositivo NetScreen solicita una dirección IP al proveedor de servicios de Internet, recibe su dirección IP, la
máscara de subred, la dirección IP de la puerta de enlace y el periodo de vigencia de la dirección arrendada. La
dirección IP del servidor DHCP es 2.2.2.5.
Zona Trust
LAN interna
1. Dirección IP solicitada para

ethernet3 (zona Untrust)
2. Dirección IP asignada
ISP
(servidor
DHCP)
2.2.2.5
Internet
Zona Untrust

Nota: Antes de poder configurar un sitio para el servicio DHCP, debe disponer de los siguientes medios:
• Línea de abonado digital (DSL) y el módem correspondiente
• Cuenta con un ISP
WebUI
9
Network > Interfaces > Edit (para ethernet3): Seleccione Obtain IP using DHCP y haga clic en OK .
CLI
set interface ethernet3 dhcp client
set interface ethernet3 dhcp settings server 2.2.2.5
save
9. La dirección IP del servidor DHCP no se puede especificar mediante WebUI; no obstante, sí se puede especificar mediante comandos CLI.

Propagación de los ajustes TCP/IP

Algunos dispositivos NetScreen pueden actuar como cliente del protocolo de control dinámico de hosts (“Dynamic
Host Control Protocol” o “DHCP”), recibiendo de un servidor DHCP externo sus ajustes TCP/IP y dirección IP para
cualquier interfaz física en cualquier zona de seguridad. Algunos dispositivos NetScreen pueden actuar como
servidores DHCP, proporcionando ajustes TCP/IP y direcciones IP a los clientes en cualquier zona. Cuando un
dispositivo NetScreen actúa simultáneamente como cliente DHCP y como servidor DHCP, puede transferir a su
módulo predeterminado de servidor DHCP los ajustes TCP/IP obtenidos de su módulo de cliente DHCP10. Los
ajustes TCP/IP incluyen la dirección IP de la puerta de enlace predeterminada y una máscara de subred, así como
las direcciones IP para cualquiera o todos los servidores siguientes:
• DNS (3) • SMTP (1)
• WINS (2) • POP3 (1)
• NetInfo (2) • News (1)
Zona Untrust
ISP
Ajustes TCP/IP y dirección IP Servidor DHCP
de la interfaz de la zona Untrust
El dispositivo NetScreen es a la vez un cliente Interfaz de la zona Untrust: Cliente DHCP

del servidor DHCP en la zona Untrust y un
servidor DHCP para los clientes de la zona Trust. Recibe direcciones IP dinámicamente del ISP.
Interfaz de la zona Trust: Servidor DHCP
Toma los ajustes TCP/IP que recibe como cliente 10.1.1.1/0
DHCP y los reenvía como servidor DHCP a los
clientes en la zona Trust. Ajustes TCP/IP Rango de DHCP:
10.1.1.50 - 10.1.1.200
Clientes de DHCP
Zona Trust
10. Si bien es posible configurar hasta ocho servidores DHCP en cualquier interfaz física o interfaz VLAN, el servidor DHCP predeterminado del dispositivo
reside en una interfaz específica en cada plataforma. En el dispositivo NetScreen-5XP, el servidor DHCP predeterminado reside en la interfaz de la zona
Trust. En el dispositivo NetScreen-5XT, el servidor DHCP predeterminado reside en la interfaz de la zona Trust para el modo de puerto “Trust-Untrust”, en
la interfaz ethernet1 para el modo de puerto “Dual-Untrust” y en la interfaz ethernet2 para los modos de puerto “Home-Work” y “Combined”. Para otros
dispositivos, el servidor DHCP predeterminado reside en la interfaz ethernet1.

Para propagar todos los ajustes TCP/IP que reciba del módulo de cliente DHCP, puede configurar el módulo del
servidor DHCP ejecutando el comando set interface interface dhcp-client settings update-dhcpserver . También
puede dar preferencia a cualquier ajuste sobre otro.
Ejemplo: Reenviar ajustes TCP/IP

En este ejemplo configurará el dispositivo NetScreen para actuar a la vez como cliente DHCP en la interfaz
ethernet3 y como servidor DHCP en la interfaz ethernet1. (El servidor DHCP predeterminado se encuentra en la
interfaz ethernet1).
Como cliente DHCP, el dispositivo NetScreen recibe una dirección IP para la interfaz ethernet3 y sus ajustes
TCP/IP de un servidor DHCP externo con la dirección 211.3.1.6. Habilitará el módulo de cliente DHCP en el
dispositivo NetScreen para transferir al módulo de servidor DHCP los ajustes TCP/IP que reciba.
Configurará el módulo de servidor DHCP NetScreen para hacer lo siguiente con los ajustes TCP/IP que reciba del
módulo de cliente DHCP:
• Reenviar las direcciones IP de DNS a sus clientes DHCP en la zona Trust.
• Ignorar las direcciones IP de la puerta de enlace predeterminada11, la máscara de red y los servidores
SMTP y POP3, dando preferencia a las siguientes:
– 10.1.1.1 (dirección IP de la interfaz ethernet1)
– 255.255.255.0 (máscara de red para la interfaz ethernet1)
– SMTP: 211.1.8.150
– POP3: 211.1.8.172
También configurará el módulo de servidor DHCP para que proporcione los siguientes ajustes TCP/IP que no
recibe del módulo de cliente DHCP:
• Servidor WINS principal: 10.1.2.42
• Servidor WINS secundario: 10.1.5.90
Finalmente, configurará el módulo de servidor DHCP de modo que asigne direcciones IP del siguiente conjunto de
direcciones IP a los hosts que actúen como clientes DHCP en la zona Trust: 10.1.1.50 – 10.1.1.200.
11. Si el servidor DHCP ya está habilitado en la interfaz de la zona Trust y dispone de un conjunto definido de direcciones IP (lo cual es el comportamiento
predeterminado en algunos dispositivos NetScreen), antes de poder cambiar la puerta de enlace predeterminada y la máscara de red debe eliminarse el
conjunto de direcciones IP.

WebUI
Nota: Esta característica solamente se puede establecer mediante CLI.
CLI
1. Cliente DHCP
set interface ethernet3 dhcp-client settings server 211.3.1.6
set interface ethernet3 dhcp-client settings update-dhcpserver
set interface ethernet3 dhcp-client settings autoconfig
set interface ethernet3 dhcp-client enable
2. Servidor DHCP
set interface ethernet1 dhcp server option gateway 10.1.1.1
set interface ethernet1 dhcp server option netmask 255.255.255.0
set interface ethernet1 dhcp server option wins1 10.1.2.42
set interface ethernet1 dhcp server option wins2 10.1.5.90
set interface ethernet1 dhcp server option pop3 211.1.8.172
set interface ethernet1 dhcp server option smtp 211.1.8.150
save

Capítulo 8 Parámetros del sistema PPPoE
PPPOE
El protocolo PPP a través de Ethernet (“PPP-over-Ethernet” o “PPPoE”) combina el protocolo punto a punto
(“Point-to-Point Protocol” o “PPP”), utilizado generalmente para conexiones de acceso telefónico, con el protocolo
Ethernet, que permite conectar varios usuarios de un sitio a los mismos equipos de las instalaciones del cliente.
Aunque muchos usuarios pueden compartir la misma conexión física, el control de accesos, la facturación y el tipo
de servicio se gestionan independientemente para cada usuario. Algunos dispositivos NetScreen admiten un cliente
PPPoE, permitiéndoles funcionar de modo compatible con DSL, Ethernet Direct y redes de cable gestionadas por
ISPs, que utilizan el protocolo PPPoE para el acceso a Internet de sus clientes.
En dispositivos que admiten PPPoE se puede configurar una instancia de cliente PPPoE en cualquier interfaz o en
todas ellas. Configurará una instancia PPPoE específica con un nombre de usuario y una contraseña, así como con
otros parámetros, y asociará la instancia a una interfaz. Cuando hay dos interfaces de Ethernet (una principal y una
de respaldo) asociadas a la zona Untrust, puede configurar una de ellas o ambas para PPPoE. Por ejemplo, en el
modo de puerto “Dual Untrust”12, puede configurar la interfaz principal (ethernet3) para DHCP y la interfaz de
respaldo (ethernet2) para PPPoE. O bien, puede configurar PPPoE tanto para la interfaz principal como para la de
respaldo.
Ejemplo: Configurar PPPoE

El ejemplo siguiente ilustra cómo definir la interfaz no fiable de un dispositivo NetScreen para conexiones PPPoE, y
cómo iniciar el servicio PPPoE.
En este ejemplo, el dispositivo NetScreen recibe del ISP una dirección IP asignada dinámicamente para su interfaz
de la zona Untrust (ethernet3), al tiempo que el dispositivo NetScreen asigna dinámicamente direcciones IP para
los tres hosts de su zona Trust. En este caso, el dispositivo NetScreen actúa como cliente PPPoE y como servidor
DHCP. La interfaz de la zona Trust debe estar en modo NAT o Route. En este ejemplo se encuentra en modo NAT.
12. Algunos dispositivos NetScreen, como el NetScreen-5XT, admiten los modos de puerto.

Untrust (ethernet3): modo DHCP Interfaz de Trust: 172.16.30.10/24
Dispositivo Módem
NetScreen DSL
ISP
DSLAM
CA Internet
Línea
DSL
Concentrador
(hub)
Servidor DNS principal
Rango de DHCP: Zona Trust Zona Untrust
172.16.30.2 - 172.16.30.5 Servidor DNS secundario
Antes de configurar el sitio de este ejemplo para el servicio PPPoE, debe disponer de los siguientes medios:
• Línea de abonado digital (DSL) y el módem correspondiente
• Cuenta con un ISP
• Nombre de usuario y contraseña (obtenida del ISP)
WebUI
1. Interfaces y PPPoE
Zone: Trust

Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK:
Zone: Untrust
Obtain IP using PPPoE: (seleccione)
User Name/Password: <nombre>/<contraseña>
Network > Interfaces > Edit (para ethernet3): Para verificar su conexión PPPoE, haga clic en Connect .
Nota: Cuando se inicia una conexión PPPoE, el proveedor de servicios de Internet (ISP) proporciona
automáticamente las direcciones IP para la interfaz de la zona Untrust y las direcciones IP para los
servidores del servicio DNS (“Domain Name Service” o “DNS”). Cuando el dispositivo NetScreen recibe
direcciones DNS a través de PPPoE, los nuevos ajustes de DNS sobrescriben de forma predeterminada
los ajustes locales. Si no desea que los nuevos ajustes de DNS reemplacen los ajustes locales, puede
utilizar el comando CLI unset pppoe dhcp-updateserver para desactivar este comportamiento.
Si utiliza una dirección IP estática para la interfaz de la zona Untrust, debe obtener las direcciones IP de
los servidores DNS e introducirlos manualmente en el dispositivo NetScreen y en los hosts de la zona
Trust.
2. Servidor DHCP
Network > Interfaces > Edit (para ethernet1) > DHCP: Seleccione DHCP Server y haga clic en Apply .
Network > Interfaces > Edit (para ethernet1) > DHCP: Introduzca los siguientes datos y haga clic en Apply :
Lease: 1 hour
Gateway: 0.0.0.0
Netmask: 0.0.0.0
DNS#1: 0.0.0.0
> Advanced: Introduzca los siguientes datos y haga clic en Return:
DNS#2: 0.0.0.0
Domain Name: (dejar en blanco)

Network > Interfaces > DHCP (para ethernet1) > New Address: Introduzca los siguientes datos y haga clic
en OK :
3. Activación de PPPoE en el dispositivo NetScreen

Apague el módem DSL, el dispositivo NetScreen y las tres estaciones de trabajo.
Encienda el módem DSL.
Encienda el dispositivo NetScreen.
El dispositivo NetScreen establecerá una conexión PPPoE con el ISP y obtendrá de éste las direcciones IP
para los servidores DNS.
4. Activación de DHCP en la red interna

Encienda las estaciones de trabajo.
Las estaciones de trabajo recibirán automáticamente las direcciones IP para los servidores DNS.
Obtendrán una dirección IP para sí mismas cuando intenten establecer una conexión TCP/IP.
Nota: Cuando se utiliza DHCP para asignar direcciones IP a los hosts de la zona Trust, el dispositivo
NetScreen reenvía automáticamente las direcciones IP de los servidores DNS que recibe del ISP a los
hosts.
Si las direcciones IP para los hosts no se asignan dinámicamente mediante DHCP, deberá introducir
manualmente las direcciones IP de los servidores DNS en cada host.
Cada conexión TCP/IP que establece un host de la zona Trust hacia la zona Untrust pasa automáticamente
por el proceso de encapsulado PPPoE.

CLI
1. Interfaces y PPPoE
set pppoe interface ethernet3
set pppoe username name_str password pswd_str
Para comprobar su conexión PPPoE:
exec pppoe connect
get pppoe
2. Servidor DHCP
save
3. Activación de PPPoE en el dispositivo NetScreen
Apague el módem DSL, el dispositivo NetScreen y las tres estaciones de trabajo.
Encienda el módem DSL.
Encienda el dispositivo NetScreen.
4. Activación de DHCP en la red interna

Encienda las estaciones de trabajo.
Las estaciones de trabajo recibirán automáticamente las direcciones IP para los servidores DNS.
Obtendrán una dirección IP para sí mismas cuando intenten establecer una conexión TCP/IP.
Cada conexión TCP/IP que establece un host de la zona Trust hacia la zona Untrust pasa automáticamente
por el proceso de encapsulado PPPoE.

Ejemplo: Configurar PPPoE en las interfaces principal y de respaldo de la

zona Untrust
En este ejemplo, el dispositivo NetScreen-5XT se encuentra en el modo “Dual Untrust”. En el ejemplo siguiente
configurará PPPoE para las interfaces principal (ethernet3) y de respaldo (ethernet2) hacia la zona Untrust.
WebUI
Configuración de PPPoE para la interfaz ethernet3
Network > PPPoE > New: Introduzca los siguientes datos y haga clic en OK :
PPPoE instance: eth3-pppoe
Bound to interface: ethernet3 (seleccione)
Username: user1
Password: 123456
Authentication: Any (seleccione)
Access Concentrator: ac-11
Configuración de PPPoE para la interfaz ethernet2
Network > PPPoE > New: Introduzca los siguientes datos y haga clic en OK :
PPPoE instance: eth2-pppoe
Bound to interface: ethernet2 (seleccione)
Username: user2
Password: 654321
Authentication: Any (seleccione)
Access Concentrator: ac-22

CLI
1. Configuración de PPPoE para la interfaz ethernet3
set pppoe name eth3-pppoe username user1 password 123456
set pppoe name eth3-pppoe ac ac-11
set pppoe name eth3-pppoe authentication any
set pppoe name eth3-pppoe interface ethernet3
2. Configuración de PPPoE para la interfaz ethernet2
set pppoe name eth2-pppoe username user2 password 654321
set pppoe name eth2-pppoe ac ac-22
set pppoe name eth2-pppoe authentication any
set pppoe name eth2-pppoe interface ethernet2
save
Múltiples sesiones PPPoE a través de una sola interfaz

Algunos dispositivos NetScreen admiten la creación de múltiples subinterfaces PPPoE (cada una con la misma
dirección MAC) para una interfaz física dada. Esto permite establecer una conexión de red privada con un ISP y
conectarse a Internet a través de otro ISP utilizando la misma interfaz física. Puede establecer estas conexiones
usando otro nombre de usuario o nombres de dominio o conectarse simultáneamente a otros ISPs.
El número máximo de sesiones PPPoE simultáneas en una interfaz física está limitado solamente por el número de
subinterfaces permitidas por el dispositivo. No hay restricción en cuanto al número de interfaces físicas que pueden
admitir múltiples sesiones. Puede especificar los parámetros username, static-ip, idle-timeout, auto-connect y otros
por separado para cada instancia o sesión PPPoE.

Interfaces no etiquetadas
Para admitir una sesión PPPoE, la subinterfaz no debe estar etiquetada. Una interfaz no etiquetada no utiliza una
etiqueta de LAN virtual para identificar la VLAN correspondiente a una subinterfaz. En lugar de ello, utiliza una
característica denominada “encap”, que asocia la subinterfaz a la encapsulación PPPoE. De este modo, al
hospedar múltiples subinterfaces, una sola interfaz física puede hospedar múltiples instancias PPPoE. Puede
configurar cada instancia de modo que acceda al concentrador de accesos especificado (CA), permitiendo que
entidades independientes tales como ISPs administren sesiones PPPoE a través de una sola interfaz. Para obtener
más información sobre VLANs y etiquetas VLAN, consulte el Volumen 9, “Sistemas virtuales”.
Múltiples subinterfaces Interfaz física única (p. ej. ethernet7)
isp_1 e7 isp_1ac
Tres instancias PPPoE isp_2 isp_2ac Tres sesiones PPPoE
e7.1
isp_3 e7.2 isp_3ac
isp_1ac
isp_2ac
isp_3ac
ethernet7 Concentradores de accesos

Ejemplo: Múltiples instancias PPPoE

En el ejemplo siguiente definirá tres instancias PPPoE, especificará un concentrador de accesos (CA) para cada
una y luego iniciará cada instancia.
• Instancia isp_1, nombre de usuario “user1@domain1”, contraseña “swordfish”, asociada a la interfaz
ethernet7. El CA se llama “isp_1ac”.
• Instancia isp_2, nombre de usuario “user2@domain2”, contraseña “marlin”, asociada a la subinterfaz
ethernet7.1. El CA se llama “isp_2ac”.
• Instancia isp_3, nombre de usuario “user3@domain3”, contraseña “trout”, asociada a la subinterfaz
ethernet7.2. El CA se llama “isp_3ac”.
WebUI
Interfaz y subinterfaces
1. Network > Interfaces > Edit (para ethernet7): Introduzca los siguientes datos y haga clic en OK:
Zone Name: Untrust
2. Network > Interfaces > New (Sub-IF): Introduzca los siguientes datos y haga clic en OK:
Interface Name: ethernet7.1
Zone Name: Untrust
3. Network > Interfaces > New (Sub-IF): Introduzca los siguientes datos y haga clic en OK:
Interface Name: ethernet7.2
Zone Name: Untrust

Instancias PPPoE y CA
4. Network > PPPoE > New: Introduzca los siguientes datos y haga clic en OK:
PPPoE Instance: isp_1
Enable: Enable
Bound to Interface: ethernet7
Username: user1@domain1
Access Concentrator: isp_1ac
Enable: Enable
Bound to Interface: ethernet7.1
Enable: Enable
Bound to Interface: ethernet7.2
Iniciación del protocolo PPPoE
7. Network > PPPoE > Connect (para isp_1)

CLI
1. Interfaz y subinterfaces
set interface ethernet7.1 encap pppoe zone untrust
set interface ethernet7.2 encap pppoe zone untrust
2. Instancias PPPoE y CAs
set pppoe name isp_1 username user1@domain1 password swordfish
set pppoe name isp_1 interface ethernet7
set pppoe name isp_1 ac isp_1ac
set pppoe name isp_2 username user2@domain2 password marlin
set pppoe name isp_2 interface ethernet7.1
set pppoe name isp_3 username user3@domain3 password trout
set pppoe name isp_3 interface ethernet7.2
save
3. Iniciación del protocolo PPPoE
exec pppoe name isp_1 connect

PPPoE y alta disponibilidad

Dos dispositivos NetScreen que admitan PPPoE en modo activo/pasivo pueden asumir el fallo de una conexión
PPPoE. En el momento de iniciar la conexión, el dispositivo maestro sincroniza su estado PPPoE con el dispositivo
de respaldo. Dado que el dispositivo pasivo utiliza la misma dirección IP que el dispositivo maestro, no tiene que
establecer una nueva conexión PPPoE al convertirse en el maestro. Por lo tanto, puede mantener la comunicación
con el concentrador de accesos después del fallo del maestro. Esto es necesario cuando la interfaz PPPoE está
soportando conexiones de VPN que deben mantenerse con la misma IP de interfaz después del fallo. Para obtener
más información sobre configuraciones de alta disponibilidad, consulte el Volumen 10, “Alta disponibilidad”.

Capítulo 8 Parámetros del sistema Actualización o degradación de firmware
ACTUALIZACIÓN O DEGRADACIÓN DE FIRMWARE

Esta sección describe tres métodos para actualizar un dispositivo NetScreen:
• Interfaz de usuario basada en web (WebUI)
• Interfaz de línea de comandos (CLI )
• Cargador de arranque o cargador de ScreenOS
Los procedimientos varían dependiendo de si está descargando el firmware en un solo dispositivo o en dispositivos
configurados para alta disponibilidad.
Nota: Si tiene una versión anterior a la 5.0.0 (por ejemplo, la 4.0.X), deberá actualizar a la 5.0.0 antes de poder
actualizar su NetScreen con el firmware de ScreenOS 5.1.0.
La sección contiene los siguientes apartados:

• “Requisitos para actualizar o degradar firmware del dispositivo” en la pàgina 424
– “Conexión del servidor de NetScreen-Security Manager” en la pàgina 425
• “Descarga de nuevo firmware” en la pàgina 426
– “Carga de nuevo firmware” en la pàgina 429
– “Mediante el cargador de arranque o del sistema operativo” en la pàgina 431
• “Actualización de dispositivos NetScreen en una configuración NSRP” en la pàgina 434
– “Actualización de dispositivos en una configuración NSRP activa/pasiva” en la pàgina 434
– “Actualizar dispositivos en una configuración NSRP activa/activa” en la pàgina 439
• “Autenticar firmware y archivos DI” en la pàgina 445
– “Obtención del certificado de autenticación” en la pàgina 445
– “Carga del certificado de autenticación” en la pàgina 447
– “Autenticación de firmware de ScreenOS” en la pàgina 448
– “Autenticación de un archivo de base de datos de objetos de ataques DI” en la pàgina 448
Importante: Antes de comenzar el proceso de actualizar un dispositivo NetScreen, guarde el archivo de configuración
existente y cerciórese de que dispone de un firmware 5.0.0 de ScreenOS por si necesita restablecerlo.

Requisitos para actualizar o degradar firmware del dispositivo

Esta sección detalla los requisitos para realizar la actualización del firmware del dispositivo NetScreen o restablecer
una versión antigua. Puede utilizar uno de los tres siguientes métodos para actualizar un dispositivo NetScreen o
degradarlo de la versión ScreenOS 5.1.0 a la ScreenOS 5.0.0: WebUI, CLI o a través del cargador de arranque o
del cargador de ScreenOS.
Nota: Puede actualizar o degradar un dispositivo NetScreen localmente o remotamente, pero Juniper Networks
recomienda realizar la actualización o el restablecimiento de una versión anterior en el mismo dispositivo
NetScreen.
Para utilizar WebUI, debe disponer de:

• Privilegios raíz (root) o de lectura-escritura en el dispositivo NetScreen
• Acceso por red al dispositivo NetScreen desde su equipo
• Un navegador de Internet instalado en su equipo
• El nuevo firmware de ScreenOS (descargado desde el sitio web de Juniper Networks y guardado
localmente en su equipo)
Para utilizar la interfaz de línea de comandos (CLI), debe disponer de:
• Una conexión de consola o un acceso Telnet al dispositivo NetScreen desde su equipo
• Un servidor TFTP instalado en su equipo
• El nuevo firmware de ScreenOS (descargado desde el sitio web de Juniper Networks y guardado en el
directorio del servidor TFTP en su equipo)

Para actualizar o degradar a través del cargador de arranque, debe disponer de:
• Un servidor TFTP instalado en su equipo o en su red local
• Una conexión Ethernet desde su equipo al dispositivo NetScreen (para transferir datos desde el servidor
TFTP en su equipo)
• Una conexión de consola desde su equipo al dispositivo NetScreen (para administrar el dispositivo
NetScreen)
• El nuevo firmware de ScreenOS guardado en el directorio del servidor TFTP en su equipo
Para actualizar o degradar un dispositivo NetScreen, consulte los procedimientos paso a paso en las secciones
siguientes: “Carga de nuevo firmware” en la pàgina 429 o bien “Actualización de dispositivos NetScreen en una
configuración NSRP” en la pàgina 434.
Conexión del servidor de NetScreen-Security Manager

Si el dispositivo NetScreen que desea degradar está conectado a un servidor NetScreen-Security Manager 2004,
antes de degradar el dispositivo deberá ejecutar los siguientes comandos CLI:
unset nsm enable
unset nsm init otp
unset nsm init id
unset nsm server primary
delete nsm keys
save
Si no ejecuta estos comandos antes de degradar el dispositivo, éste no podrá conectarse al servidor de
NetScreen-Security Manager la próxima vez que lo actualice a la versión más reciente de ScreenOS.

Descarga de nuevo firmware

Antes de comenzar la actualización de los dispositivos NetScreen, debe tener el firmware más reciente de
ScreenOS. Puede obtener el firmware desde el sitio web de Juniper Networks. Para acceder a descargas de
firmware, debe ser un cliente registrado con una ID de usuario y contraseña activas. Si todavía no ha registrado su
producto NetScreen, deberá hacerlo antes de proceder. Puede registrar su producto en el sitio web de Juniper
Networks.
Nota: Si degrada a la versión ScreenOS 5.0.0, se perderán todas las claves de ScreenOS 5.1.0 que haya cargado
en el dispositivo. Sin embargo, las claves cargadas en el dispositivo antes de actualizar a ScreenOS 5.1.0
permanecerán intactas.

Para obtener el firmware de ScreenOS más reciente, visite el sitio web http://www.juniper.net/support. Haga clic en
“Support > Customer Support Center” y siga estos pasos:
1. Inicie una sesión introduciendo su ID de usuario y contraseña y haciendo clic en LOGIN.
2. Bajo “My Technical Assistance Center”, haga clic en Download Software.
Juniper mantiene una lista de las descargas disponibles.
3. Haga clic en Continue.
Aparecerá la página “File Download”.
Página “File Download”
Vínculos de productos

4. Haga clic en el vínculo del producto cuyo firmware desea descargar.

Aparecerá la página “Upgrades”.
5. Haga clic en el vínculo correspondiente a la versión de ScreenOS que desea descargar.

Aparecerá la página “Upgrades”.
6. Haga clic en el vínculo “Upgrade”.
Aparecerá el cuadro de diálogo de descarga de archivos “Download File”.
7. Haga clic en Save y navegue a la ubicación donde desee guardar el archivo de firmware comprimido en
formato ZIP.
Debe guardar el firmware en el equipo desde el que desee realizar la actualización.
– Si desea actualizar el dispositivo NetScreen usando WebUI, guarde el firmware en cualquier directorio.
– Si desea actualizar los dispositivos NetScreen usando CLI, guarde el firmware en el directorio raíz del
servidor TFTP en el equipo. Si no tiene ningún servidor TFTP instalado en su equipo, puede
descargar uno desde Internet. Si no hay ningún servidor TFTP disponible, debe utilizar WebUI para
cargar el nuevo firmware en el dispositivo NetScreen.

Carga de nuevo firmware

A continuación se incluyen los procedimientos para actualizar un solo dispositivo NetScreen y para degradar un
sistema de ScreenOS 5.1.0 a ScreenOS 5.0.0. Estos procedimientos son independientes del modo de
funcionamiento del dispositivo NetScreen.
Nota: Si está actualizando un dispositivo NetScreen desde una versión de firmware anterior a ScreenOS 5.0.0,
debe actualizar el firmware a ScreenOS 5.0.0 antes de actualizarlo a ScreenOS 5.1.0. Asegúrese de guardar la
configuración existente para evitar la pérdida de datos al actualizar.
Mediante WebUI
Realice los pasos siguientes para cargar firmware con WebUI:
1. Cerciórese de que dispone del nuevo firmware de ScreenOS. Para obtener información sobre la obtención
del nuevo firmware, consulte “Descarga de nuevo firmware” en la pàgina 426.
2. Inicie una sesión en el dispositivo NetScreen con el explorador web e introduzca la dirección IP de
administración en el campo “Address”. Inicie una sesión como administrador raíz (“root admin”) o como
administrador con privilegios de lectura-escritura.
3. Guarde la configuración existente:
a. Elija Configuration > Update > Config File y haga clic en Save to File.
b. En el cuadro de diálogo “File Download”, haga clic en Save.
c. Navegue a la ubicación donde desea guardar el archivo de configuración (cfg.txt) y haga clic en Save.
4. Configuration > Update > ScreenOS/Keys > Select Firmware Update.
5. Haga clic en Browse para navegar a la ubicación del nuevo firmware de ScreenOS o escriba la ruta donde
se encuentra en el campo “Load File”.
6. Haga clic en Apply.
Aparecerá un cuadro de mensaje con información sobre el tiempo de actualización.
7. Haga clic en OK para continuar.
El dispositivo NetScreen se reiniciará automáticamente. La actualización o degradación estará completa
cuando el dispositivo muestre la página de inicio de sesión en el explorador.
8. Inicie una sesión en el dispositivo NetScreen. Puede verificar la versión de firmware de ScreenOS del
dispositivo NetScreen en la sección de información del dispositivo “Device Information” de la página
principal de WebUI.

Mediante CLI
Realice los pasos siguientes para cargar firmware con CLI:
1. Cerciórese de que dispone del nuevo firmware de ScreenOS. Para obtener información sobre la obtención
del nuevo firmware, consulte “Descarga de nuevo firmware” en la pàgina 426.
2. Inicie una sesión en el dispositivo NetScreen usando una aplicación como Telnet, Secure Shell (SSH) o
Hyperterminal si está conectado directamente a través del puerto de la consola. Inicie una sesión como
administrador raíz (“root admin”) o como administrador con privilegios de lectura-escritura.
3. Guarde la configuración existente ejecutando el comando save config to { flash | slot1 | tftp }.
4. Ejecute el servidor TFTP en su equipo haciendo doble clic en la aplicación del servidor TFTP.
5. En el dispositivo NetScreen, introduzca save soft from tftp ip_addr filename to flash, donde la dirección
IP es la de su equipo y el nombre de archivo es el del firmware de ScreenOS.
6. Cuando la actualización o degradación se haya completado, deberá restablecer el dispositivo NetScreen.
Ejecute el comando reset y teclee y cuando se le pida para restablecer el dispositivo.
7. Espere unos minutos y vuelva a iniciar una sesión en el dispositivo NetScreen.
8. Utilice el comando get system para verificar la versión de firmware de ScreenOS del dispositivo
NetScreen.
9. Cargue el archivo de configuración que guardó en el paso 3 con el comando
save config to { flash | slot1 | tftp }.

Mediante el cargador de arranque o del sistema operativo

El cargador de arranque/SO pone en marcha el sistema de hardware, realiza configuraciones de hardware básicas,
y a veces vitales, y carga el software del sistema utilizado para operar un dispositivo NetScreen.
Nota: En el NetScreen-500, este proceso no se puede utilizar para guardar el firmware de ScreenOS 5.1.0 en la
memoria flash. Utilice WebUI o CLI para guardar el firmware de ScreenOS 5.1.0 en la memoria flash.
Realice los pasos siguientes para cargar firmware mediante el cargador de arranque/SO:
1. Conecte su equipo al dispositivo NetScreen:
a. Con un cable serie, conecte el puerto serie de su equipo al puerto de consola del dispositivo NetScreen.
Esta conexión, conjuntamente con una aplicación terminal, permite administrar el dispositivo NetScreen.
b. Mediante un cable Ethernet, conecte el puerto de red de su equipo al puerto 1 o al puerto de
administración del dispositivo NetScreen13. Esta conexión permite la transferencia de datos entre el
equipo, el servidor TFTP y el dispositivo NetScreen.
2. Asegúrese de que dispone del nuevo firmware de ScreenOS guardado en el directorio del servidor TFTP de
su equipo. Para obtener información sobre la obtención del nuevo firmware, consulte “Descarga de nuevo
firmware” en la pàgina 426.
3. Ejecute el servidor TFTP en su equipo haciendo doble clic en la aplicación del servidor TFTP. Puede
minimizar su ventana, pero debe permanecer activa en segundo plano.
4. Inicie una sesión en el dispositivo NetScreen usando un emulador de terminal, como HyperTerminal. Inicie
una sesión como administrador raíz (“root admin”) o como administrador con privilegios de
lectura-escritura.
5. Reinicie el dispositivo NetScreen.
6. Cuando aparezcan los mensajes “Hit any key to run loader” o “Hit any key to load new firmware” en la
pantalla de la consola, presione cualquier tecla en su equipo para interrumpir el proceso de arranque.
Nota: Si no interrumpe el dispositivo NetScreen a tiempo, éste cargará el firmware guardado en la

memoria flash.
13. El puerto utilizado para la conexión depende del modelo de dispositivo NetScreen.

7. En el mensaje “Boot File Name”, escriba el nombre del archivo del firmware de ScreenOS que desea
cargar.
Si escribe slot1: antes del nombre de archivo especificado, el cargador leerá el archivo especificado de la
Compact Flash o tarjeta de memoria externa. Si no escribe slot1: antes del nombre de archivo, el archivo
será descargado del servidor TFTP. Si el dispositivo NetScreen no admite tarjetas Compact Flash,
aparecerá un mensaje de error y la consola le pedirá escribir de nuevo el nombre de archivo.
8. En el mensaje “Self IP Address”, escriba una dirección IP perteneciente a la misma subred que la del
servidor TFTP.
9. Cuando aparezca el mensaje “TFTP IP Address”, escriba la dirección IP del servidor TFTP.
Nota: Las direcciones “Self IP” y “TFTP IP” deben estar en la misma subred; de lo contrario, el cargador de
TFTP rechaza la dirección “Self IP” y pide que se vuelva a introducir.
Una indicación de que el firmware se está cargando correctamente es la visualización de una serie de
“rtatatatatatata…” en la pantalla del emulador de terminal y una serie de símbolos moviéndose en la
ventana del servidor TFTP. Cuando la instalación del firmware se haya completado, un mensaje le
informará de la instalación correcta.
Guardar múltiples imágenes del firmware con el cargador de arranque

Una vez descargado correctamente el firmware, la consola visualiza la pregunta siguiente:
Save to on-board flash disk? (y/[n]/m)
Responda y (sí) para guardar el archivo como firmware predeterminado. Esta imagen se ejecuta automáticamente
si usted no interrumpe el proceso de arranque.
Responda m (múltiple) para guardar el archivo como firmware múltiple. Debe seleccionar un nombre de archivo
cuando aparezca el aviso siguiente:
Please input multiple firmware file name [BIMINITE.D]: test.d

El nombre entre corchetes es el nombre recomendado, generado automáticamente a partir del nombre introducido
en el servidor TFTP. Si no introduce ningún nombre, se utiliza el nombre recomendado.
Nota: Debe introducir un nombre compatible con la nomenclatura de archivos DOS 8.3. La longitud máxima del
nombre del archivo de arranque utilizado por el cargador no puede exceder de 63 caracteres. Sólo las series
NetScreen-5GT, NetScreen-ISG200 y NetScreen-5000 admiten firmware múltiple. En el NetScreen-5GT, puede
asignar un máximo de tres archivos de firmware al disco flash integrado. Las series NetScreen-ISG2000 y
NetScreen-5000 no tienen límite para guardar archivos de firmware en el disco flash integrado.

Actualización de dispositivos NetScreen en una configuración NSRP

Para dispositivos NetScreen en una configuración del protocolo de redundancia NetScreen (“NetScreen
Redundancy Protocol” o “NSRP”), debe actualizar cada dispositivo individualmente. Esta sección describe dos
procedimientos distintos de actualización para dos configuraciones NSRP diferentes: NSRP activa/pasiva y NSRP
activa/activa.
Nota: Si está actualizando un dispositivo NetScreen desde una versión anterior a ScreenOS 5.0.0, debe actualizar
el dispositivo a ScreenOS 5.0.0 antes de actualizarlo a ScreenOS 5.1.0. Los procedimientos de esta sección
describen cómo actualizar un dispositivo NetScreen desde ScreenOS 5.0.0 a ScreenOS 5.1.0.
Actualización de dispositivos en una configuración NSRP activa/pasiva

El ejemplo siguiente ilustra una configuración NSRP básica activa/pasiva en la que el dispositivo A es el maestro y el
dispositivo B es el respaldo.
NSRP Activa/Pasiva
Grupo VSD 0
Dispositivo A (maestro) Dispositivo B (respaldo)
Vínculo HA
Antes de comenzar, lea los requisitos para realizar una actualización (“Requisitos para actualizar o degradar
firmware del dispositivo” en la pàgina 424). Asegúrese también de descargar el firmware de ScreenOS al que está
actualizando cada dispositivo.
Aviso: No apague su dispositivo NetScreen mientras se está actualizando con el nuevo firmware. Hacerlo podría
dañar permanentemente el dispositivo.

Procedimiento de actualización
Para actualizar dos dispositivos en una configuración NSRP activa/pasiva, siga estos pasos (tenga en cuenta que
algunos de estos pasos sólo se pueden ejecutar con la interfaz de línea de comandos CLI):
A. Actualizar el dispositivo B a ScreenOS 5.1.0
B. Conmutar el dispositivo A al dispositivo B (sólo CLI)
C. Actualizar dispositivo A a ScreenOS 5.1.0
D. Sincronizar el dispositivo A (sólo CLI)
E. Conmutar el dispositivo B al dispositivo A (sólo CLI)
A. Actualizar el dispositivo B a ScreenOS 5.1.0
WebUI
1. Cerciórese de que dispone del firmware de ScreenOS 5.1.0. Para más información sobre la obtención
del firmware, consulte “Descarga de nuevo firmware” en la pàgina 426.
2. Inicie una sesión en el dispositivo B con el explorador web (por ejemplo, Internet Explorer o Netscape) e
introduzca la dirección IP de administración en el campo “Address”. Inicie una sesión como
c. Navegue a la ubicación donde desea guardar el archivo de configuración (cfg.txt) y haga clic en
Save.
4. Elija Configuration > Update > ScreenOS/Keys y seleccione Firmware Update.
5. Haga clic en Browse para navegar a la ubicación del firmware ScreenOS 5.1.0 o escriba la ruta donde


El dispositivo NetScreen se reiniciará automáticamente. La actualización estará completa cuando el
dispositivo muestre la página de inicio de sesión en el explorador.
principal de WebUI.
CLI
2. Inicie una sesión en el dispositivo B usando una aplicación como Telnet, Secure Shell (SSH) o
5. En el dispositivo NetScreen, introduzca save soft from tftp ip_addr filename to flash. Donde la
dirección IP es la de su equipo y el nombre de archivo es el del firmware de ScreenOS 5.1.0.
6. Cuando la actualización se haya completado, deberá restablecer el dispositivo NetScreen. Ejecute el
comando reset y teclee y cuando se le pida para restablecer el dispositivo.
8. Utilice el comando get system para verificar la versión de firmware de ScreenOS del dispositivo
NetScreen.

B. Conmutar el dispositivo A al dispositivo B (sólo CLI)

Conmute manualmente el dispositivo maestro al dispositivo de respaldo.
1. Inicie una sesión en el dispositivo maestro.
2. Ejecute uno de los comandos siguientes de CLI. El comando que debe ejecutar depende de si la opción
“preempt”14 está activada en el dispositivo maestro.
– Si la característica “preempt” está activada: exec nsrp vsd-group 0 mode ineligible
– Si la opción “preempt no” está activada: exec nsrp vsd-group 0 mode backup
Cualquiera de ambos comandos fuerza al dispositivo maestro a retirarse y al dispositivo de respaldo a
asumir inmediatamente su función.
C. Actualizar dispositivo A a ScreenOS 5.1.0
WebUI
2. Inicie una sesión en el dispositivo NetScreen A.
Save.
14. Para obtener más información sobre la opción de asignación de prioridad “preempt” y NSRP en general, consulte el Volumen 8 de NetScreen conceptos y
ejemplos: manual de referencia de ScreenOS..


principal de WebUI.
CLI
2. Inicie sesión en el dispositivo A de NetScreen.
4. Ejecute el servidor TFTP en su computadora haciendo doble clic en la aplicación del servidor TFTP.
5. En el dispositivo NetScreen, introduzca save soft from tftp ip_addr filename to flash. Donde la
8. Puede verificar la versión del firmware de ScreenOS del dispositivo NetScreen con el comando get
system.
D. Sincronizar el dispositivo A (sólo CLI)
Después de completar la actualización del dispositivo A a ScreenOS 5.1.0, sincronice manualmente ambos
dispositivos. En el dispositivo A (de respaldo), ejecute el comando CLI exec nsrp sync rto all from peer
para sincronizar los RTOs desde el dispositivo B (maestro).
E. Conmutar el dispositivo B al dispositivo A (sólo CLI)
Después de sincronizar los dispositivos, conmute manualmente el dispositivo maestro al dispositivo de
respaldo. Siga los mismos pasos que en “B. Conmutar el dispositivo A al dispositivo B (sólo CLI)” en la
pàgina 437 salvo que iniciando una sesión en el dispositivo B y conmutando al dispositivo B en lugar de
hacerlo al dispositivo A.

Actualizar dispositivos en una configuración NSRP activa/activa

Esta sección de actualización es aplicable a una configuración NSRP en la que se emparejaron dos dispositivos
NetScreen en dos grupos de dispositivos de seguridad virtuales (“Virtual Security Devices” o VSD), siendo cada
dispositivo físico el maestro en un grupo y el dispositivo de respaldo en el otro. Para actualizar, primero tiene que
conmutar uno de los dispositivos de modo que solamente un dispositivo físico sea maestro de ambos grupos VSD.
A continuación, actualice el dispositivo de respaldo primero y el dispositivo maestro en segundo lugar.
A continuación se ilustra una configuración NSRP activa/activa típica, en la que el dispositivo A es maestro del VSD
0 y respaldo del VSD 1, y el dispositivo B es maestro del VSD 1 y respaldo del VSD 0.
NSRP activo/activo
Grupo VSD: 0 Grupo VSD: 1
(maestro) (respaldo) Dispositivo A
Vínculo HA
(respaldo) (maestro) Dispositivo B
Antes de comenzar, lea los requisitos para realizar una actualización (“Requisitos para actualizar o degradar
firmware del dispositivo” en la pàgina 424). Asegúrese también de descargar el firmware de ScreenOS 5.1.0.
Aviso: No apague su dispositivo NetScreen mientras se está actualizando con el nuevo firmware. Hacerlo podría
dañar permanentemente el dispositivo.

Procedimiento de actualización
Para actualizar dos dispositivos en una configuración NSRP activa/activa, siga estos pasos (tenga en cuenta que
algunos de estos pasos sólo se pueden ejecutar con la interfaz de línea de comandos CLI):
A. Conmutar el dispositivo B en VSD 1 al dispositivo A en VSD 1 (sólo CLI)
B. Actualizar el dispositivo B a ScreenOS 5.1.0
C. Conmutar el dispositivo A al dispositivo B (sólo CLI)
D. Actualizar dispositivo A a ScreenOS 5.1.0
E. Sincronizar el dispositivo A (sólo CLI)
F. Conmutar el dispositivo B en VSD 0 al dispositivo A en VSD 0 (sólo CLI)
A. Conmutar el dispositivo B en VSD 1 al dispositivo A en VSD 1 (sólo CLI)

Conmute manualmente el dispositivo maestro B del grupo VSD 1 al dispositivo de respaldo A del grupo
VSD 1.
1. Inicie una sesión en el dispositivo B usando una aplicación como Telnet, Secure Shell (SSH) o
2. Ejecute uno de los comandos siguientes de CLI. El comando que debe ejecutar depende de si la opción
15
“preempt” está activada en el dispositivo maestro.
– Si la característica “preempt” está activada: exec nsrp vsd-group 1 mode ineligible
– Si la opción “preempt” no está activada: exec nsrp vsd-group 1 mode backup
Cualquiera de ambos comandos fuerza al dispositivo B a retirarse y al dispositivo A a asumir
inmediatamente la función de maestro del VSD 1. En este momento, el dispositivo A es maestro de VSD 0
y 1 y el dispositivo B es respaldo de VSD 0 y 1.
15. Para obtener más información sobre la opción de asignación de prioridad “preempt” y NSRP en general, consulte el Volumen 8 de NetScreen Conceptos
y ejemplos: manual de referencia de ScreenOS..

B. Actualizar el dispositivo B a ScreenOS 5.1.0
WebUI
2. Inicie una sesión en el dispositivo B NetScreen con el explorador web (por ejemplo, Internet Explorer o
Netscape) e introduzca la dirección IP de administración en el campo “Address”. Inicie una sesión como
Save.
principal de WebUI.

CLI
2. Inicie una sesión en el dispositivo B.
5. En el dispositivo NetScreen, introduzca save soft from tftp ip _addr filename to flash. Donde la
system.
C. Conmutar el dispositivo A al dispositivo B (sólo CLI)

Conmute manual y totalmente el dispositivo A al dispositivo B.
1. Inicie una sesión en el dispositivo A.
2. Conmute el dispositivo maestro A en el VSD 0 al dispositivo de respaldo B en el VSD 0 ejecutando uno
de los siguientes comandos CLI. El comando que debe ejecutar depende de si la opción preempt está
activada en el dispositivo maestro.
– Si la característica preempt está activada: exec nsrp vsd-group 0 mode ineligible
– Si la opción preempt no está activada: exec nsrp vsd-group 0 mode backup
3. Conmute el dispositivo maestro A en el VSD 1 al dispositivo de respaldo B en el VSD 1 ejecutando uno
En este momento, el dispositivo B es maestro de ambos VSD 0 y 1 y el dispositivo A es respaldo de ambos
VSD 0 y 1.

D. Actualizar dispositivo A a ScreenOS 5.1.0
WebUI
2. Inicie una sesión en el dispositivo NetScreen A.
Save.
principal de WebUI.

CLI
5. En el dispositivo NetScreen, introduzca save soft from tftp ip _addr filename to flash. Donde la
system.
E. Sincronizar el dispositivo A (sólo CLI)
Después de completar la actualización del dispositivo A a ScreenOS 5.1.0, sincronice manualmente ambos
dispositivos. En el dispositivo A, ejecute el comando CLI exec nsrp sync rto all from peer para sincronizar
los RTOs desde el dispositivo B.
F. Conmutar el dispositivo B en VSD 0 al dispositivo A en VSD 0 (sólo CLI)
Como paso final, vuelva a generar instancias de ambos dispositivos NetScreen en una configuración NSRP
activa/activa.
2. Conmute el dispositivo maestro B en el VSD 0 al dispositivo de respaldo A en el VSD 0 ejecutando uno
En este momento, el dispositivo A es maestro del VSD 0 y respaldo del VSD 1, y el dispositivo B es maestro
del VSD 1 y respaldo del VSD 0.

Autenticar firmware y archivos DI

Desde la versión ScreenOS 2.6.1r1, se ha incorporado una firma de autenticación de imágenes en cada
compilación de ScreenOS. Si carga el certificado de autenticación (imagekey.cer) en un dispositivo NetScreen
cortafuegos/VPN de Juniper Networks, puede autenticar firmware de ScreenOS al intentar guardarlo en el
dispositivo o autenticar archivos de la base de datos de objetos de ataques de Deep Inspection (DI) al intentar
descargarlos al dispositivo.
Autenticar una imagen y una base de datos de objeto de ataques DI proporciona seguridad y estabilidad. Si intenta
guardar una imagen o base de datos de ScreenOS modificada o dañada, el dispositivo la rechaza antes de
guardarla en la memoria flash.
Obtención del certificado de autenticación

Puede conseguir el archivo ZIP del certificado de autenticación en las dos fuentes siguientes:
• El CD de documentación suministrado con su dispositivo NetScreen:
1. Inserte el CD de documentación en la unidad de CD.
Debe ejecutarse automáticamente. (Para usuarios de Macintosh y usuarios de PC que no tengan
activada la opción de autoarranque en sus sistemas, haga doble clic en index.htm para ejecutar el
CD.)
2. Haga clic en Explore CD-ROM Contents .
3. Abra la carpeta extra .
El archivo image_key.zip se encuentra en esta carpeta.
• El área “Customer Support” del sitio web de Juniper Networks16:
1. Abra su explorador web y escriba la siguiente URL en el campo de dirección “Address”:
http://www.juniper.net/support/.
2. En la sección “Login to Support Center”, introduzca su ID de cliente y su contraseña y haga clic en
LOGIN .
3. En la sección “Download Software”, haga clic en ScreenOS Software .
16. Debe ser un cliente registrado para acceder al área de soporte al cliente. Si aún no tiene una cuenta de cliente, puede crearla en línea visitando
http://www.juniper.net/support/, haciendo clic en Login Assistance y siguiendo las instrucciones de registro en línea.

4. En el parte superior de la página hay una sección titulada Image Authentication. Haga clic con el botón
derecho en Download the Authentication Certificate , seleccione Save Target As , y guarde el
archivo image_key.zip en un directorio local.
Una vez que haya obtenido el archivo ZIP del certificado, haga lo siguiente:
1. Utilice un programa de compresión de datos, como WinZip, para extraer los dos archivos siguientes de
image_key.zip : imagekey.cer y image_key_readme.pdf 17.
2. Guarde imagekey.cer en cualquiera de las siguientes ubicaciones, dependiendo de si desea cargarlo
en el dispositivo NetScreen usando WebUI o CLI:
– WebUI: guárdelo en un directorio local
– CLI: guárdelo en el directorio raíz de un servidor TFTP
17. El archivo “readme” contiene esencialmente la misma información que esta sección.

Carga del certificado de autenticación

Antes de cargar el certificado de autenticación en el dispositivo NetScreen, puede confirmar su integridad
calculando una suma de comprobación criptográfica, o resumen del mensaje, y comparándola con el siguiente
resumen del mensaje MD5:
AC359646EDD723F541AA0E52E015E8F0
Una utilidad MD5 gratuita para Windows es FastSum, disponible en www.fastsum.com. Bajo UNIX/Linux, puede
utilizar un programa como md5sum para calcular el resumen del mensaje.
Cuando se carga el certificado de autenticación, el firmware se verifica con el certificado de autenticación antes de
ejecutarlo o guardarlo. Si el firmware no supera la autenticación, es rechazado y no se carga en el dispositivo
NetScreen.
Cuando tenga certeza sobre la integridad del certificado de autenticación, cargue el certificado en el dispositivo
NetScreen mediante cualquiera de estos métodos:
WebUI
1. Establezca una conexión HTTP al dispositivo NetScreen e inicie una sesión.
2. Configuration > Update > ScreenOS/Keys: Introduzca los siguientes datos y haga clic en Apply :
Image Key Update (See Online Help): (seleccione)
Load File: Indique la ubicación de imagekey.cer o haga clic en Browse para
navegar a la ubicación del archivo, seleccione imagekey.cer y haga clic en
Open .
CLI
1. Si fuese necesario, inicie el servidor TFTP.
2. Establezca una conexión de consola, Telnet o SSH al dispositivo NetScreen e inicie una sesión.
3. Ejecute el siguiente comando CLI:
save image-key tftp ip_addr imagekey.cer
donde ip_addr es la dirección del servidor TFTP.

Autenticación de firmware de ScreenOS

La descarga del dispositivo NetScreen utiliza el certificado de autenticación para comprobar la firma de ScreenOS
incrustada en el archivo. En la consola aparecerá uno de los dos resultados siguientes:
• El dispositivo NetScreen puede autenticar con éxito el firmware, por lo que el cargador de arranque/SO
muestra el mensaje siguiente:
Loaded Successfully! . . .
Image authenticated!
• Si el dispositivo NetScreen no puede autenticar el firmware de ScreenOS, lo rechaza y o bien le pide cargar
otro firmware, o se reinicia automáticamente:
********Invalid DSA signature
*******Bogus Image - not authenticated.
Nota: Si el certificado de autenticación no se carga, el dispositivo NetScreen no intenta autenticar un

firmware de ScreenOS ni base de datos de objetos de ataques DI. Para eliminar el certificado, ejecute el
comando delete crypto auth-key .
Autenticación de un archivo de base de datos de objetos de ataques DI

La próxima vez que intente descargar una base de datos de objetos de ataques para Deep Inspection (DI), el
dispositivo NetScreen utilizará el certificado de autenticación para comprobar la firma incrustada en el archivo. El
proceso de autenticación produce uno de los dos resultados siguientes:
• El dispositivo NetScreen autentica con éxito la base de datos de objetos de ataques descargada y efectúa
la siguiente entrada en el registro de eventos:
Attack database version <number> has been authenticated and saved to flash.
• La autenticación falla y el dispositivo NetScreen efectúa la entrada siguiente en el registro de eventos:
Attack database was rejected because the authentication check failed.

Además, si intenta descargar la base de datos manualmente a través de WebUI y la autenticación falla,
aparecerá el siguiente mensaje emergente:
Rejected DI attack database because the authentication check was unable to verify its integrity.
Nota: Si el certificado de autenticación no se carga, el dispositivo NetScreen no intenta autenticar una

imagen de ScreenOS ni base de datos de objetos de ataques DI. Para eliminar el certificado, ejecute el
comando delete crypto auth-key .
Para obtener información sobre mensajes del registro de eventos, consulte el manual NetScreen Message
Log Reference Guide.

Capítulo 8 Parámetros del sistema Descarga y carga de configuraciones
DESCARGA Y CARGA DE CONFIGURACIONES

Cada vez que se modifique la configuración, conviene realizar una copia de seguridad de los ajustes. WebUI
permite descargar la configuración a cualquier directorio local como precaución de respaldo. Con algunos
dispositivos NetScreen, puede utilizar CLI para descargar la configuración a una tarjeta flash o servidor TFTP. Si
necesita restablecer la configuración de respaldo guardada, puede cargarla en el dispositivo NetScreen.
La sección contiene los siguientes apartados:
• “Almacenamiento e importación de ajustes” en la pàgina 450
• “Retroactivación (“rollback”) de una configuración” en la pàgina 452
– “Última configuración correcta conocida” en la pàgina 452
– “Retroactivación automática y manual de una configuración” en la pàgina 453
– “Carga de un nuevo archivo de configuración” en la pàgina 454
• “Bloqueo del archivo de configuración” en la pàgina 455
– “Inclusión de comentarios en un archivo de configuración” en la pàgina 456
Almacenamiento e importación de ajustes

La capacidad de guardar e importar ajustes de configuración proporciona los medios para la distribución masiva de
plantillas de configuración.
Para guardar una configuración:
WebUI
1. Configuration > Update > Config File: Haga clic en Save to File .
Un mensaje del sistema le pedirá que abra el archivo o lo guarde en su equipo.
2. Haga clic en Save .
3. Navegue a la ubicación donde desea guardar el archivo de configuración y haga clic en Save .

CLI
save config from flash to { tftp dir_ip | slot } filename [ from interface ]
Nota: En algunos dispositivos NetScreen, debe especificar slot1 o slot2.
Para importar una configuración:
WebUI
Configuration > Update > Config File: Introduzca los siguientes datos y haga clic en Apply :
Seleccione Merge to Current Configuration si desea combinar las
configuraciones nuevas con las actuales, o Replace Current
Configuration si desea que la nueva configuración sobrescriba la
configuración actual.
> New Configuration File: Introduzca la ubicación del archivo de configuración o haga
clic en Browse para navegar a la ubicación del archivo, seleccione el archivo y
haga clic en Open .
CLI
save config from { tftp ip_addr | slot } filename to flash [ merge [ from
interface ] ]
Nota: En algunos dispositivos NetScreen, debe especificar slot1 o slot2.

Retroactivación (“rollback”) de una configuración

En caso de haber cargado un archivo de configuración que cause problemas, como fallos del dispositivo NetScreen
o denegación de las funciones de administración a usuarios remotos, puede realizar una retroactivación de la
configuración para recuperar el archivo con la última (“Last-Known-Good” o “LKG”) configuración correcta conocida,
guardada en la memoria flash.
Nota: No todos los dispositivos NetScreen permiten la retroactivación de configuraciones. Para consultar si su
dispositivo NetScreen admite esta función, consulte la hoja de datos correspondiente a su plataforma.
Última configuración correcta conocida

Antes de retroactivar (“rollback”) una configuración, asegúrese de disponer de un archivo de configuración de LKG
guardado en la memoria flash, para que el dispositivo NetScreen lo pueda restablecer en caso de error. Para
comprobar la existencia del archivo LKG, abra CLI de NetScreen y escriba el comando get config rollback . El
nombre de archivo de una configuración LKG es $lkg$.cfg. Si no ve este archivo, significa que no existe y que debe
crearlo.
Para guardar un archivo de configuración en la memoria flash como última configuración correcta conocida (LKG):
1. Asegúrese de que la configuración actual del dispositivo NetScreen sea correcta.
2. Guarde la configuración actual en la memoria flash ejecutando el comando CLI save config to
last-known-good . Este comando sobrescribe la configuración de LKG existente en la memoria flash con el
archivo de configuración actual.
Nota: Guardar periódicamente la configuración del dispositivo NetScreen como archivo de configuración LKG es
una buena manera de salvaguardar los cambios más recientes realizados y mantener una copia actualizada de la
configuración.

Retroactivación automática y manual de una configuración

Puede habilitar que el dispositivo NetScreen restablezca automáticamente la última configuración correcta conocida
(LKG), o bien puede realizar una retroactivación manual. La función de retroactivación automática de la
configuración permite al dispositivo NetScreen recuperar la configuración LKG en caso de producirse algún
problema con una configuración recién cargada.
La función de retroactivación automática está desactivada de forma predeterminada. Incluso se desactiva después
de cada arranque, sin importar si estaba habilitada o no antes de iniciar el dispositivo. Para habilitar la
retroactivación automática de la configuración, utilice el comando exec config rollback enable . Para desactivar la
función, utilice el comando exec config rollback disable .
Para realizar una retroactivación manual de la configuración, utilice el comando exec config rollback .
Nota: WebUI no admite la función de retroactivación de la configuración.
Una vez habilitada la función de retroactivación de la configuración, el mensaje del comando cambia para indicar
este estado:
ns-> exec config rollback enable
ns(rollback enabled)->
Al desactivar la función de retroactivación de la configuración, el mensaje de línea de comandos simplemente
devuelve el nombre de host del dispositivo:
ns(rollback enabled)-> exec config rollback disable
ns->
Para comprobar si la función de retroactivación automática de la configuración está habilitada, utilice el comando
get config rollback . Si está habilitada, la primera línea de mensajes del comando get config rollback es:
config rollback is enabled
De lo contrario, la primera línea de la salida es:
config rollback is disabled

Si existe un archivo de configuración LKG, la segunda línea de mensaje del comando get config rollback es:
Last-known-good config file flash:/$lkg$.cfg exists in the flash.
Si no existe ningún archivo de configuración LKG, la segunda (y última) línea de mensajes es:
Last-known-good config file flash:/$lkg$.cfg does not exist.
Si la función de retroactivación de la configuración está habilitada, puede desencadenar la operación de
retroactivación mediante cualquiera de las acciones siguientes:
• Reiniciar el dispositivo NetScreen (apagándolo y encendiéndolo de nuevo)
• Restablecer el dispositivo NetScreen (ejecutando el comando reset )
• Ejecutar el comando exec config rollback
Carga de un nuevo archivo de configuración

A continuación se describe cómo cargar un nuevo archivo de configuración, habilitar la función de retroactivación y
qué hacer si el nuevo archivo de configuración causa problemas.
1. Utilizando la interfaz CLI, guarde la configuración actual como configuración LKG (última correcta conocida)
ejecutando el comando save config to last-known-good.
2. Habilite la retroactivación automática de configuración en el dispositivo NetScreen ejecutando el comando
CLI exec config rollback enable. Al habilitar esta función se bloquea simultáneamente el archivo LKG
para evitar que otros usuarios lo puedan sobrescribir y de este modo interrumpir una retroactivación en
curso.
3. Cargue el nuevo archivo de configuración usando WebUI o CLI. Para obtener más información, consulte
“Actualización o degradación de firmware” en la pàgina 423.
4. Pruebe el nuevo archivo de configuración ejecutando algunos comandos. Pueden producirse varias
situaciones diferentes:
– La nueva configuración funciona correctamente.
– La nueva configuración es defectuosa y, consecuentemente, impide alcanzar y administrar el
dispositivo NetScreen. En este caso, deberá apagar el dispositivo. Al encenderlo, el dispositivo
NetScreen lee el archivo de la memoria flash, lo cual indica que la función de retroactivación de
configuración está habilitada. Esa información induce al dispositivo NetScreen a cargar
automáticamente el archivo LKG.

– Surgen problemas o errores relacionados con el nuevo archivo de configuración. En este caso es
necesario restablecer el dispositivo NetScreen ejecutando el comando CLI reset. Cuando el
dispositivo se reinicia, lee el archivo de la memoria flash, lo cual indica que la función de
retroactivación de configuración está habilitada. Esa información induce al dispositivo NetScreen a
cargar automáticamente el archivo LKG.
– La nueva configuración es defectuosa e impide que el dispositivo NetScreen funcione correctamente.
En este caso, el dispositivo NetScreen se reinicia automáticamente. Cuando el dispositivo se reinicia,
lee el archivo de la memoria flash, lo cual indica que la función de retroactivación de configuración
está habilitada. Esa información induce al dispositivo NetScreen a cargar automáticamente el archivo
LKG.
Nota: NetScreen Redundancy Protocol (NSRP): En una configuración activa/activa, si la carga de un

nuevo archivo de configuración falla, ambos dispositivos NetScreen revierten a la configuración LKG. En
una configuración activa/pasiva, si falla la carga de un nuevo archivo de configuración, sólo la unidad
maestra revierte a la configuración LKG. La unidad maestra sólo sincroniza la unidad de respaldo después
de que la configuración se haya guardado en un archivo.
Bloqueo del archivo de configuración

Puede bloquear un archivo de configuración en la memoria flash para evitar que sea sobrescrito por otros
administradores, o antes de importar un nuevo archivo de configuración. En el momento de bloquear el archivo de
configuración, el dispositivo inicia un temporizador de bloqueo. Si el dispositivo no recibe un comando CLI en un
plazo previamente especificado, se reinicia automáticamente y vuelve a utilizar la configuración que fue bloqueada
en la memoria flash. Conviene bloquear la configuración actual del dispositivo antes de iniciar la importación de un
archivo de configuración. Esta acción evita que el dispositivo se “congele” por tiempo indefinido si se produce algún
fallo en el proceso de importación.
Una vez bloqueado el archivo de configuración, ni usted ni ningún otro administrador conectado al dispositivo (por
ejemplo, a través de Telnet o de WebUI) podrán guardar el archivo. Antes deberá desbloquear la configuración y
guardar los nuevos comandos de configuración con el comando save .
Nota: El archivo de configuración sólo se puede bloquear y desbloquear mediante la interfaz de línea de comandos
(“CLI”). Esta característica no está disponible en WebUI.

CLI
Para bloquear el archivo de configuración:
exec config lock start
Para desbloquear el archivo:
exec config lock end
Para cancelar el bloqueo y reiniciar inmediatamente el dispositivo con la configuración previamente
bloqueada en la memoria flash:
exec config lock abort
Para cambiar el tiempo de bloqueo predeterminado (5 minutos):
set config lock timeout <number>
Inclusión de comentarios en un archivo de configuración

Puede agregar comentarios a un archivo de configuración externo. Los comentarios pueden ocupar su propia línea
de texto o incluirse al final de una línea. El comentario debe comenzar con el signo # (almohadilla) seguido de un
espacio. Cuando el comentario se encuentra al final de una línea, también debe incluirse un espacio delante de la
almohadilla. En el momento de guardar el archivo en un dispositivo NetScreen (ya sea combinando la nueva
configuración con la existente o reemplazando íntegramente la configuración existente por la nueva), el dispositivo
analiza la configuración buscando las líneas que comiencen con el símbolo de almohadilla y elimina todos los
comentarios.
Nota: Si el símbolo de almohadilla aparece entrecomillado, el dispositivo NetScreen no lo trata como marcador
especial, sino como parte de un nombre de objeto y no lo elimina. Por ejemplo, el dispositivo NetScreen no elimina
“#5 server” en el comando set address trust “#5 server” 10.1.1.5/32 porque aparece entrecomillado.
El dispositivo NetScreen no guarda ningún comentario introducido con el símbolo de almohadilla en la memoria
RAM ni en la memoria flash. Por ejemplo, si un archivo de configuración externo contiene las líneas siguientes:
set interface ethernet3 ip 1.1.1.1/24 # change IP address

# agregar direcciones IP
set interface ethernet3 mip 1.1.1.10 host 10.1.1.10 netmask 255.255.255.255
# la opción predeterminada es que todas las MIP usen el dominio de rutas
trust-vr
Al visualizar la configuración después de cargar el archivo, verá lo siguiente (los comentarios habrán
desaparecido):
Asimismo, si pega un bloque de comandos que contenga comentarios en una sesión de consola o de Telnet, el
dispositivo NetScreen descartará todos los comentarios tan pronto como se ejecuten los comandos.

Capítulo 8 Parámetros del sistema Establecer Bulk-CLI de NetScreen-Security Manager
ESTABLECER BULK-CLI DE NETSCREEN-SECURITY MANAGER

Estableciendo bulk-CLI se determina cómo y cuándo el dispositivo realiza la retroactivación cuando la conexión de
NetScreen-Security Manager se interrumpe durante una sesión de actualización. Cuando esto sucede, el agente
recorre una vez todos los servidores NetScreen-Security Manager configurados para averiguar si puede establecer
otra conexión. En caso negativo, el agente espera durante el período especificado antes de reiniciar el dispositivo
para retroactivar la configuración. El rango de valores del tiempo de espera para el reinicio es de 60 a 86400
segundos. El valor predeterminado del tiempo de espera para el reinicio es de 60 segundos.
El agente comprueba el estado de la conexión del NetScreen-Security Manager bajo dos condiciones:
• Que todos los comandos CLI se ejecuten y envíen un mensaje de éxito o fallo al NetScreen-Security
Manager.
• Que se produzca un error, que debe ser comunicado al NetScreen-Security Manager.
Si se produce un error durante la ejecución de CLI, el agente envía un mensaje con un informe del error al
NetScreen-Security Manager y permanece a la espera de instrucciones. Existen tres posibilidades para las
instrucciones de error:
• Si se ordena al agente detenerse, éste deja de ejecutar los restantes comandos CLI y reinicia.
• Si se ordena al agente que continúe, seguirá ejecutando los restantes comandos CLI.
• Si el agente no recibe ninguna instrucción dentro del tiempo de espera especificado para el reinicio, el
agente comprueba si el tiempo de espera para el reinicio de bulk-CLI está activado o desactivado.
– Si está activado, se produce inmediatamente un reinicio.
– Si está desactivado, el agente no reinicia el dispositivo. El dispositivo continúa ejecutando los
restantes comandos CLI.
Para establecer el valor del tiempo de espera para el reinicio, utilice el comando siguiente:
set nsmgmt bulkcli reboot_timeout number
donde el valor unitario de number son los segundos.
Para desactivar el tiempo de espera para el reinicio, utilice el comando siguiente:

set nsmgmt bulkcli reboot_timeout disable

Capítulo 8 Parámetros del sistema Claves de licencia
CLAVES DE LICENCIA
La característica de la clave de licencia permite ampliar las prestaciones del dispositivo NetScreen sin tener que
actualizar a otro dispositivo o imagen del sistema. Puede comprar una clave que desbloquee las características
especificadas ya cargadas en el firmware, como:
• Capacidad de usuarios
• Sistemas virtuales, zonas y enrutadores virtuales
• HA
Cada dispositivo NetScreen se suministra con un conjunto estándar de características habilitadas y puede admitir la
activación de características opcionales o aumentar la capacidad de las existentes. Para obtener más información
sobre qué características pueden actualizarse en este momento, consulte la documentación comercial más reciente
de Juniper Networks.
El procedimiento para obtener y aplicar una clave de licencia es el siguiente:
1. Póngase en contacto con el distribuidor de valor añadido (VAR) que le vendió el dispositivo NetScreen o
directamente con Juniper Networks.
2. Proporcione el número de serie de su dispositivo e indique qué opción de qué característica desea.
Se generará su clave de licencia, que recibirá por correo electrónico.
3. Introduzca la clave con WebUI o CLI. (Consulte el ejemplo siguiente).

Capítulo 8 Parámetros del sistema Claves de licencia
Ejemplo: Ampliar la capacidad de usuarios

Una pequeña empresa que sólo utiliza un dispositivo NetScreen con una licencia para 10 usuarios ha crecido hasta
el punto de necesitar una licencia sin limitación de usuarios. El administrador de NetScreen amplía las capacidades
del dispositivo obteniendo una clave de firmware para un número ilimitado de usuarios. El número de la clave de
licencia es 6a48e726ca050192 y se encuentra en un archivo de texto llamado “A2010002.txt”, guardado en
“C:\netscreen\keys”.
WebUI
Configuration > Update > ScreenOS/Keys: Haga lo siguiente y luego clic en Apply :
License Key Update: (seleccione)
Load File: C:\netscreen\keys\A2010002.txt
o bien
Haga clic en Browse y navegue hasta C:\netscreen\keys, seleccione
A2010002.txt y haga clic en Open .
CLI
exec license-key capacity 6a48e726ca050192
reset

Capítulo 8 Parámetros del sistema Registro y activación de los servicios de suscripción
REGISTRO Y ACTIVACIÓN DE LOS SERVICIOS DE SUSCRIPCIÓN

Para que su dispositivo NetScreen de Juniper Networks pueda recibir un servicio regular de suscripción para
patrones AV (antivirus), firmas DI (Deep Inspection) o filtros de URLs, debe adquirir una suscripción al servicio,
registrarse en él y descargar la clave de suscripción. En el momento de descargar la suscripción, sus servicios se
activan en el dispositivo. El proceso de activación de servicios se comporta de una forma u otra dependiendo de los
servicios adquiridos y del método de compra.
Servicio temporal
Para darle tiempo a probar los servicios AV o DI, el dispositivo NetScreen otorga un periodo de gracia temporal.
Durante este tiempo, el dispositivo puede obtener servicios temporalmente.
• Ningún dispositivo NetScreen se suministra con DI habilitado. Para obtener el servicio DI temporalmente,
debe iniciar una sesión de WebUI y hacer clic en Retrieve Subscriptions Now en la página Configuration
> Update > ScreenOS/Keys. De este modo obtendrá una clave DI única, válida para un solo día.
• Si su dispositivo se suministra con el servicio AV incluido en el momento de la compra, tendrá preinstalado
un servicio temporal. Este servicio temporal dura hasta 60 días.
• Ningún dispositivo NetScreen se suministra con el filtrado de URL activado. Esta característica no tiene un
servicio temporal.
Aviso! Para evitar la interrupción del servicio, debe registrarse lo antes posible después de adquirir su
suscripción. El registro asegura la continuidad de la suscripción.

Paquete de AV, filtrado de URLs y DI incluido con un dispositivo nuevo

Si ha comprado un nuevo dispositivo NetScreen con los servicios AV, filtrado de URLs y DI ya incorporados, realice
los pasos siguientes para activarlos.
1. Configure el dispositivo para que pueda conectarse a Internet. (Para obtener instrucciones, consulte la guía
Getting Started Guide y el manual de usuario de su dispositivo NetScreen).
2. Registre el dispositivo en el sitio siguiente:
www.juniper.net/support
Los dispositivos con servicios AV incluidos se suministran con una suscripción temporal preinstalada, lo
que permite utilizar el servicio inmediatamente. Sin embargo, para recibir su suscripción completa debe
registrar el dispositivo.
3. Descargue la clave de suscripción en el dispositivo. Puede hacerlo de dos maneras:
– En WebUI, haga clic en el botón Retrieve Subscriptions Now desde la página Configuration >
Update > ScreenOS/Keys.
– Con la interfaz de línea de comandos (CLI), ejecute el comando siguiente:
exec license-key update
4. Debe restablecer (“reset”) el dispositivo después de cargar la clave.
Ahora puede configurar el dispositivo para que realice la descarga de los servicios de firma de forma automática o
manual. Para obtener instrucciones sobre la configuración de su dispositivo NetScreen para estos servicios,
consulte “Análisis antivirus” en la pàgina 4 -86, “Filtrado de URL” en la pàgina 4 -111 y “Deep Inspection” en la
pàgina 4 -135.

Actualización de AV, filtrado de URLs y DI en un dispositivo existente

Si adquiere los servicios AV, filtrado de URLs y DI por separado para instalarlos en su dispositivo NetScreen,
realice los pasos siguientes para activarlos.
1. Después de solicitar los servicios, recibirá un certificado de soporte por correo electrónico, directamente de
Juniper Networks o de uno de sus distribuidores NetScreen autorizados. Este certificado es un documento
legible que contiene la información que necesita para registrar su dispositivo.
2. Cerciórese de que el dispositivo esté registrado. Si aún no está registrado, vaya al sitio siguiente:
3. Registre el certificado de soporte para el dispositivo.
4. Si solamente se está suscribiendo y registrando para el servicio DI o de filtrado de URLs, prosiga con el
paso 5.
Si se está suscribiendo y registrando para el servicio AV, deberá esperar hasta cuatro horas para que el
sistema procese su registro antes de proseguir con el paso 5.
5. Confirme que su dispositivo puede conectarse a Internet.
6. Descargue la clave de suscripción al dispositivo. Puede hacerlo de dos maneras:
Ahora puede configurar el dispositivo para que realice la descarga de los servicios de firma de forma automática o
manual. Para obtener instrucciones sobre la configuración de su dispositivo NetScreen para estos servicios,
consulte “Análisis antivirus” en la pàgina 4 -86, “Filtrado de URL” en la pàgina 4 -111 y “Deep Inspection” en la
pàgina 4 -135.

Sólo actualización de DI
Si solamente adquirió servicios DI y compró su dispositivo NetScreen por separado de este servicio, realice los
pasos siguientes para activar el servicio.
1. Después de solicitar el servicio, recibirá un certificado de soporte por correo electrónico, directamente de
Juniper Networks o de uno de sus distribuidores NetScreen autorizados. Este certificado es un documento
legible que contiene la información que necesita para registrar su dispositivo.
2. Cerciórese de que el dispositivo esté registrado. Si aún no está registrado, vaya al sitio siguiente:
3. Registre el certificado de soporte para el dispositivo.
4. Confirme que su dispositivo puede conectarse a Internet.
5. Descargue la clave de suscripción en el dispositivo. Puede hacerlo de dos maneras:
Ahora puede configurar el dispositivo para que realice la descarga de los servicios de firma DI de forma automática
o manual. Para obtener instrucciones sobre la configuración de su dispositivo NetScreen para este servicio,
consulte “Deep Inspection” en la pàgina 4 -135.

Capítulo 8 Parámetros del sistema Reloj del sistema
RELOJ DEL SISTEMA

Es importante que su dispositivo NetScreen siempre tenga la hora exacta. Entre otras cosas, la hora de su
dispositivo NetScreen afecta a la configuración de los túneles VPN y a la sincronización de programaciones. Hay
muchas maneras de asegurarse de que el dispositivo NetScreen siempre esté en hora. Primero, debe poner el reloj
del sistema en hora. A continuación, puede habilitar la opción del horario de verano (“daylight saving time”) y
configurar hasta tres servidores NTP (uno principal y dos de respaldo) que el dispositivo NetScreen utilizará para
actualizar periódicamente su reloj del sistema.
Fecha y hora
Para poner el reloj en hora con la fecha y hora actuales, puede utilizar WebUI o CLI. A través de WebUI, esta
operación se efectúa sincronizando el reloj del sistema con el reloj de su computadora:
1. Configuration > Date/Time: Haga clic en el botón Sync Clock with Client .
Aparecerá un mensaje preguntándole si tiene habilitada la opción del horario de verano en el reloj de su
computadora.
2. Haga clic en Yes para sincronizar el reloj del sistema y ajustarlo según el horario de verano o invierno, o
bien en No para sincronizarlo sin el ajuste de horario de verano.
Con CLI, el reloj se pone en hora manualmente introduciendo la fecha y hora mediante el comando “set clock
mm/dd/yyyy hh:mm:ss”.
Huso horario
El huso horario se establece especificando el número de horas de adelanto o de retraso de la hora local del
dispositivo NetScreen con respecto a GMT (“Greenwich Mean Time”, hora media de Greenwich). Por ejemplo, si el
huso horario local del dispositivo NetScreen es la hora estándar del Pacífico (“Pacific Standard Time” o “PST”),
tendrá un retraso de 8 horas con respecto a GMT. Por lo tanto, deberá poner el reloj en -8.
Para establecer el huso horario mediante WebUI:
Configuration > Date/Time > Set Time Zone_hours_minutes from GMT

Para establecer el huso horario mediante CLI:

ns -> set clock timezone number (número entre -12 y 12)
o bien
ns -> set ntp timezone number (número entre -12 y 12)
NTP
Para asegurarse de que el dispositivo NetScreen siempre tenga la hora correcta, puede utilizar el protocolo de hora
de red (“Network Time Protocol” o “NTP”) para sincronizar el reloj del sistema con el de un servidor NTP a través de
Internet. Puede hacer esto manualmente o configurar el dispositivo NetScreen para que realice esta sincronización
automáticamente a intervalos determinados.
Múltiples servidores NTP

Puede configurar hasta tres servidores NTP en un dispositivo NetScreen: un servidor principal y dos servidores de
respaldo. Cuando se configura el dispositivo NetScreen para sincronizar el reloj del sistema de forma automática,
efectúa una consulta en cada servidor NTP configurado, consultando los tres uno tras otro. El dispositivo siempre
consulta primero al servidor NTP principal. Si la consulta no obtiene respuesta, el dispositivo consulta
seguidamente al primer servidor NTP de respaldo, etc., hasta obtener una respuesta válida de alguno de los
servidores NTP configurados en el dispositivo NetScreen. Antes de finalizar la actualización y registrar el fallo, el
dispositivo realiza cuatro intentos en cada servidor NTP.
La sincronización manual del reloj del sistema solamente se puede hacer mediante CLI, pudiendo especificarse un
servidor NTP determinado o ninguno. Si especifica un servidor NTP, el dispositivo NetScreen solamente consultará
a ese servidor. Si no especifica ningún servidor NTP, el dispositivo NetScreen consultará, uno por uno, a cada
servidor NTP configurado en el dispositivo NetScreen. Puede especificar un servidor NTP utilizando su dirección IP
o su nombre de dominio.

Desfase temporal máximo

Para la sincronización automática se puede especificar un valor máximo de desfase (en segundos). El valor
máximo de desfase es la máxima diferencia horaria admisible entre el reloj del sistema del dispositivo NetScreen y
la hora recibida de un servidor NTP. El dispositivo NetScreen solamente ajusta su reloj con la hora del servidor NTP
si la diferencia horaria entre su reloj y el servidor NTP es inferior al valor máximo de desfase establecido. Por
ejemplo, si el valor máximo de desfase horario es de 3 segundos, la hora en el reloj del sistema del dispositivo son
las 4:00:00 y el servidor NTP envía 4:00:02 como hora actual, la diferencia entre ambos es aceptable y el
dispositivo NetScreen puede actualizar su reloj. Si el desfase es superior al máximo establecido, el dispositivo
NetScreen no sincroniza su reloj y procede a intentar consultar al primer servidor NTP de respaldo configurado en
el dispositivo NetScreen. Si el dispositivo NetScreen no recibe una contestación válida después de intentar
consultar a todos los servidores NTP configurados, genera un mensaje de error en el registro de eventos. El valor
predeterminado de esta característica son 3 segundos y el rango de valores permitidos es de 0 (sin límite) a 3600
(una hora).
Al sincronizar manualmente el reloj del sistema, lo cual solamente es posible mediante CLI, el dispositivo
NetScreen no comprueba el desfase horario máximo. En lugar de ello, si recibe una respuesta válida, el dispositivo
NetScreen muestra un mensaje informando sobre el servidor NTP alcanzado, el desfase horario existente con él y
el método de autenticación utilizado. El mensaje también pide que se confirme o se cancele la actualización del
reloj del sistema.
Si el dispositivo NetScreen no recibe una respuesta, genera un mensaje de vencimiento de tiempo de espera. Este
mensaje aparece solamente después de que el dispositivo haya intentado sin éxito alcanzar a todos los servidores
NTP configurados en el dispositivo NetScreen.
Nota: Al enviar consultas mediante CLI, puede cancelar la petición actual presionando Ctrl-C en el teclado.

Protocolos NTP y NSRP

El protocolo de redundancia de NetScreen (“NetScreen Redundancy Protocol” o “NSRP”) contiene un mecanismo
para sincronizar el reloj del sistema de los miembros de un clúster NSRP. Aunque la unidad de resolución de
sincronización es el segundo, NTP ofrece una resolución inferior al segundo. Dado que diferentes miembros de un
clúster pueden tener horas distintas con variaciones de unos pocos segundos debido al retraso ocasionado por el
procesamiento, Juniper Networks recomienda desactivar la sincronización horaria de NSRP cuando NTP esté
habilitado en dos miembros del clúster, para que ambos puedan actualizar su reloj del sistema desde un servidor
NTP. Para desactivar la función de sincronización horaria NSRP, introduzca el siguiente comando:
set ntp no-ha-sync
Ejemplo: Configurar servidores NTP y un valor de desfase horario máximo

En el ejemplo siguiente configurará el dispositivo NetScreen para actualizar su reloj a intervalos de cinco minutos
consultando los servidores NTP de las direcciones IP 1.1.1.1, 1.1.1.2 y 1.1.1.3. También establecerá un valor
máximo de desfase horario de 2 segundos.
WebUI
Configuration > Date/Time: Introduzca los siguientes datos y haga clic en Apply :
Automatically synchronize with an Internet Time Server (NTP): (seleccione)
Update system clock every minutes: 5
Maximum time adjustment seconds: 2
Primary Server IP/Name: 1.1.1.1
Backup Server1 IP/Name: 1.1.1.2
Backup Server2 IP/Name: 1.1.1.3
CLI
set clock ntp
set ntp server 1.1.1.1

set ntp server backup1 1.1.1.2

set ntp server backup2 1.1.1.3
set ntp interval 5
set ntp max-adjustment 2
save
Servidores NTP seguros

Puede asegurar el tráfico NTP aplicando la suma de comprobación basada en MD5 para autenticar los paquetes
NTP. No es necesario crear un túnel IPSec. Este tipo de autenticación asegura la integridad del tráfico NTP. No
impide a los interlocutores externos ver los datos, pero evita que cualquier usuario pueda manipularlos.
Para habilitar la autenticación del tráfico NTP, debe asignar una identificación de clave y una clave previamente
compartida únicas a cada servidor NTP que configure en un dispositivo NetScreen. La identificación de clave y la
clave previamente compartida sirven para generar una suma de comprobación con la que el dispositivo NetScreen
y el servidor NTP pueden autenticar los datos.
Tipos de autenticación
Existen dos tipos de autenticación para el tráfico NTP: la requerida y la preferida (“required” y “preferred”).
Cuando se selecciona la autenticación Required , el dispositivo NetScreen debe incluir la información de
autenticación (identificación de clave y suma de comprobación) en cada paquete que envía a un servidor
NTP y debe autenticar todos los paquetes NTP que recibe de un servidor NTP. Para poder establecer la
autenticación entre un dispositivo NetScreen y un servidor NTP, los administradores del dispositivo
NetScreen y del servidor NTP deben intercambiar primero una identificación de clave y una clave
previamente compartida. Tienen que intercambiarlas manualmente, para lo que disponen de varios
métodos, por ejemplo, correo electrónico o teléfono.
Al seleccionar la autenticación Preferred , el dispositivo NetScreen primero debe funcionar como si
estuviese en el modo “Required”, intentando autenticar todo el tráfico NTP. Si todos los intentos de
autenticación fallan, el dispositivo NetScreen pasa a funcionar como si no se hubiese seleccionado ninguna
autenticación. Envía paquetes a un servidor NTP sin incluir identificación de clave ni suma de
comprobación. Esencialmente, aunque existe cierta preferencia por la autenticación, si ésta falla el
dispositivo NetScreen sigue permitiendo el tráfico NTP.


Índice
Índice
A C definición
zonas 37
alarmas certificado de autenticación 445–449 DHCP 132, 138, 411
umbrales 326 resumen del mensaje MD5 447 agente de retransmisión 388
ALG 206 certificado de soporte 463, 464 client 388
MS RPC 163 claves de licencia 459–460 HA 397
para servicios personalizados 318 CLI servidor 388
RTSP 169 convenciones x DI, servicio 463, 464
SIP 200 delete crypto auth-key 449 DiffServ 327
set arp always-on-dest 99, 104 véase DS Codepoint Marking
SIP NAT 215
configuración DIP 136, 278–282
Sun RPC 160
bloquear 455 conjuntos 321
alta disponibilidad grupos 297–300
carga 454
véase HA descargar y cargar 450 modificar un conjunto de DIP 281
ancho de banda 327 guardar 450 PAT 279
administrar 360 guardar e importar 450 puerto fijo 280
colas de prioridades 367 inclusión de comentarios 456 direcciones
especificación máxima 360 LKG 452 definición 315
garantizado 327, 360, 368 retroactivación 452–454, 455 en directivas 315
máximo 327, 368 salvaguardar 450 entradas en la libreta de direcciones 144
máximo ilimitado 360 configuración LKG 452 privadas 69
niveles de prioridad 368 conjuntos de caracteres compatibles con públicas 68
ScreenOS xiv direcciones IP
prioridad predeterminada 367
Conjuntos de direcciones IP definir por cada puerto 144
aplicación en directivas 318 identificación de la red 68
ARP 112 véase Conjuntos de DIP
identificación del host 68
dirección IP de entrada 115 Conjuntos de direcciones IP dinámicas
privadas 67
asignación de tráfico 359–373 véase Conjuntos de DIP
públicas 67
convenciones
automática 360 rangos de direcciones privadas 69
CLI x secundarias 75
prioridades del servicio 367
ilustración xiii seguimiento en interfaces 84
requisito de la interfaz 360
nombres xiv zonas de seguridad L3 67–69
autenticación WebUI xi
Allow Any 324 direcciones IP secundarias 75
crear direcciones privadas 69
directivas 321 grupos de direcciones 148 direcciones públicas 68
usuarios 321 grupos de servicios 275 direcciones, negación 351
autenticación en tiempo de ejecución 323 zonas 37 directivas 3
AV, servicio 463 acciones 317
D administración 329
B Deep Inspection
administrar ancho de banda 360
alarmas 326
bulk-CLI 458 autenticación de descargas 445–449 aplicación 318
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-I

Índice
asignación de tráfico 327

autenticación 321
sistemas virtuales 312 G
tareas programadas 326
cambiar 355 gatekeeper (equipos selectores) 181
tipos 308–310
colocar al principio 320, 357 gestión de colas de prioridades 367
túnel 317 gráficos de historial 325
contexto de una directiva 348 túneles L2TP 319
copia de seguridad de la sesión HA 324 grupos de direcciones 146, 315
ubicación 331 crear 148
Deep Inspection 320
verificación de directivas 356 editar 149
denegar 317
VPNs 319 eliminar entradas 150
desactivar 355
VPNs bidireccionales 319, 330 opciones 147
direcciones 315
zonas de seguridad 315 grupos de servicios 274–277
direcciones en 315
directivas de acceso crear 275
elementos requeridos 307
véase directivas eliminar 277
eliminar 358
modificar 276
funciones de 305 directivas ocultadas 356
global 310, 331, 347 DNS 377
grupos de DIP 298 consulta 378 H
grupos de direcciones 315 consultas de dominios 385 HA
grupos de servicios 274 división de direcciones 386 DHCP 397
grupos de usuarios de acceso telefónico a división de direcciones DNS del proxy 385 interfaz de HA virtual 58
VPN 315 DNS dinámico 382 véase también NSRP
habilitar 355 historial, gráficos 325
encapsulamiento a servidores 385
iconos 329 huso horario 465
servidor 413
ID 315
interzonales 308, 331, 332, 337 tabla de estado 379
intrazonales 309, 331, 344 DS Codepoint Marking 360, 369, 370 I
L2TP 319 DSL 407, 412
dyndns.org y ddo.jp 382 iconos
libro de servicios 151 definición 329
límite máximo 147 directiva 329
listas de conjuntos de directivas 311
múltiples elementos por componente 349 E ilustración
convenciones xiii
NAT-dst 321 editar interfaces
NAT-src 321 directivas 355 activas físicamente 81
negación de direcciones 351 grupos de direcciones 149 activas lógicamente 81
nombre 318 zonas 38 agregadas 56
ocultación 356 enrutadores virtuales asociar a zonas 66
orden 357 véase VRs cambios de estado 81–106
permit 317 desasociar de una zona 70
enrutamiento
rechazo 317 DIP 278
recuento 325 entre direcciones IP secundarias 75
dirección IP secundaria 75
registro de tráfico 325 direccionamiento 67
reglas internas 312
reordenar 357
F físicas 3
HA 57
secuencia de consulta 311 filtrado de URL 325 HA virtual 58
servicios 316 firmware inactivas físicamente 81
servicios en 151, 316 autenticación 445–448 inactivas lógicamente 81
sistema raíz 312 flujo de paquetes 12–15 loopback 77
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-II

Índice
MGT 57
modificar 71
M VSIs 56
NTP 466–469
máscaras de red 315
predeterminadas 69 configuración del servidor 468
aplicaciones 68
redundantes 56 desfase horario máximo 467
MGT, interfaz 57
Seguimiento de IP (Véase seguimiento de IP) múltiples servidores 466
MIP 14
supervisión de la conexión 83 servidores 466
a una zona con NAT basada en interfaces 129
túnel 35, 58, 58–63 servidores seguros 469
modo de ruta 135–140
visualizar tabla de interfaces 64 sincronización NSRP 468
ajustes de interfaz 136
VSI 56 tipos de autenticación 469
modo NAT 127–134
zonas de seguridad L3 67
ajustes de interfaz 130
interfaces agregadas 56
interfaces de túnel 58
tráfico a la zona Untrust 107, 129 O
modo transparente 108–126
definición 58 ojos de aguja 208
ARP/trace-route 113
NAT basada en directivas 58 opciones “unicast” desconocidas 112–118
bloquear tráfico que no es ARP 110
interfaces de zonas de función 57 ARP 115–118
bloquear tráfico que no es IP 110
interfaz de administración 57 inundación 113–114
inundación 113
interfaz de HA 57 trace-route 115, 118
opciones unicast 113
interfaces loopback 77
rutas 111
interfaces no etiquetadas 418
interfaz de administración
tráfico broadcast 110 P
modos de puertos 41–52
véase interfaz MGT PAT 279
MS RPC ALG
interfaz HA virtual 58 PPPoE 411–422
definición 163
ISP - proveedor de servicios de Internet 385 alta disponibilidad 422
grupos de servicios 167
servicios 164 configuración 411, 416
L múltiples instancias 419
múltiples sesiones por interfaz 417
L2TP N
directivas 319
libreta de direcciones
NAT basada en directivas
interfaces de túnel 58 Q
agregar direcciones 144 NAT-src QoS (calidad del servicio) 360
editar entradas de grupos 149 modo de ruta
eliminar direcciones 150
entradas 144
NAT-src 135
negación de direcciones 351 R
grupos 146 NetInfo 389 recuento 325
modificar direcciones 145 nombres red, ancho de banda 360
véase también direcciones convenciones xiv registro 325
libro de servicios NSM reglas, derivadas de directivas 312
agregar servicio 154 bulk-CLI 458 reloj del sistema 465–469
eliminar entradas (CLI) 155 tiempo de espera para el reinicio 458 fecha y hora 465
grupos de servicios (WebUI) 274 NSRP huso horario 465
modificar entradas (CLI) 155 copia de seguridad de la sesión HA 324 sincronización con cliente 465
modificar entradas (WebUI) 276 DHCP 397 retroactivación 458
servicio personalizado 151 grupos de DIP 297–300 retroactivación, configuración 452–454
servicio personalizado (CLI) 154 interfaces redundantes 56 RFCs
servicios preconfigurados 151 retroactivación de la configuración 455 1349, “Type of Service in the Internet Protocol
LKG (última correcta conocida) 452 sincronización NTP 468 Suite” 327
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-III

Índice
1918, “Address Allocation for Private interfaces compartidas 85 sesiones multimedia 200
Internets” 69 interfaces compatibles 85 tiempo de espera por inactividad de la
2132, “DHCP Options and BOOTP Vendor opción “dynamic” 86 sesión 211
Extensions” 396 peso 86 tiempo de espera por inactividad de
2326, “Real Time Streaming Protocol redireccionamiento de tráfico 84–106 medios 211, 213
(RTSP)” 169, 174 umbral de fallos de la IP supervisada 86 tiempo de espera por inactividad de
2474, “Definition of the “Differentiated umbral de fallos del objeto 86 señalización 211, 213
Services” Field (DS Field) in the IPv4 and vsys 85 tipos de métodos de petición 201
IPv6 Headers” 327 Servicio AV 462 SIP NAT
792, “Internet Control Message Protocol” 158 con VPN de malla completa 263
Servicio de DI 462
RSH ALG 160 configuración de llamadas 215, 223
servicios 151
RTSP ALG definición 215
ALGs personalizados 318
códigos de estado 173 entrante, con MIP 232, 236
definición 316 proxy en DMZ 247
definición 169 direcciones 146 proxy en zona privada 239
métodos de petición 171 en directivas 316 proxy en zona pública 243
servidor en dominio privado 175 ICMP 158 trust intrazonal 259
servidor en dominio público 178 lista desplegable 151 untrust intrazonal 253
modificar el tiempo de espera 157 utilizar DIP de interfaz 228
S personalizado en vsys 153
personalizados 153–155
utilizar DIP entrante 226
utilizar un conjunto de DIP 232
SCREEN servicios 274 Sistema de nombres de dominio
zona MGT 34 umbral del tiempo de espera 156 véase DNS
ScreenOS servicios ICMP 158 sistema virtual 11
actualizar 423 código de mensaje 158 sistema, parámetros 375–469
directivas 3 tipo de mensaje 158 sistema, reloj 465–469
flujo de paquetes 12–15 servicios personalizados 153–155 véase también reloj del sistema
interfaces de la zona de seguridad 3 en root y vsys 153 software
interfaces físicas 3 Servidor de filtrado de URLs 462 actualizar 423
modos de puertos 41 sesiones multimedia, SIP 200 subinterfaces 4
sistemas virtuales 11 SIP 200–213 crear (sistema raíz) 73
subinterfaces 4 ALG 206, 211 eliminar 74
vista general 1–30 Sun RPC ALG
anuncios de medios 208
zona de seguridad global 2 definición 160
caducidad por inactividad 211
servicios 161
zona global 34 códigos de respuesta 204
supuestos de llamadas 160
zona Home-Work 49 definición 200 supervisión de interfaces
zonas 31–40 información de la conexión 207 bucles 92
zonas de función 40 mensajes 200 interfaces 91–98
zonas de seguridad 2, 34 Métodos de petición 201 zonas de seguridad 98
zonas de seguridad predefinidas 2 ojos de aguja 206 suscripciones
zonas de túnel 35 respuestas 204 activación del servicio 463, 464
SDP 206–208 RTCP 208 descarga de claves 463
seguimiento de IP RTP 208 registro y activación 461–464
fallo en la interfaz de entrada 103–106 SDP 206–208 servicio temporal 461
fallo en la interfaz de salida 100–102 señalización 206 servicios incluidos 462
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-IV

Índice
T V WebUI
valor del tiempo de espera para el reinicio 458 convenciones xi
tareas programadas 301, 326
tiempo 458 VIP 14
trace-route 115, 118
VLAN1
a una zona con NAT basada en interfaces 129
Z
traducción de direcciones de puertos
Interfaz 109, 119 zona Home 49
véase PAT Zonas 109 zona VLAN 109
tráfico VLANs zona Work 49
asignación 360 etiquetas 4 zonas 31–40
prioridad 327 voz sobre IP
recuento 325 función 40
administración del ancho de banda 271
registro 325 global 34
definición 181
VPNs Layer 2 109
seguridad 34
U a una zona con NAT basada en interfaces 129
directivas 319 túnel 35
última configuración correcta conocida zonas de túnel 35 VLAN 40, 109
véase configuración LKG VRs zonas de seguridad 2
URL, servicio de filtrado 463 introducción 5 determinación de la zona de destino 14
usuarios de autenticación reenviar tráfico entre dos 5 determinación de la zona de origen 13
autenticación en tiempo de ejecución 323 global 2
autenticación previa a la directiva 323 W interfaces 3, 55
proceso de autenticación en tiempo de WebAuth interfaces físicas 55
ejecución 323 proceso de autenticación previo a predefinidas 2
WebAuth 323 directivas 323 subinterfaces 55
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-V

Índice
Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos IX-VI

CE v2 SP

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CE v2 SP

Enviado por

Direitos autorais:

Formatos disponíveis

NetScreen conceptos y ejemplos

Manual de referencia de ScreenOS

FCC Statement Disclaimer

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos i

Interfaces de zonas de seguridad..............................55 Ejemplo: Eliminar una interfaz de la zona

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos ii

Reenvío de tráfico ....................................................110 Tiempos de espera de servicios............................... 156

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos iii

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos iv

Definición de directivas..........................................312 Ejemplo: Conjunto de directivas interzonales.... 337

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos v

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos vi

Establecer Bulk-CLI de NetScreen-Security Reloj del sistema ....................................................465

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos vii

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos viii

El Volumen 2, “Fundamentos” describe la arquitectura de ScreenOS y sus elementos, incluyendo ejemplos de

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos ix

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

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos x

Convenciones de la interfaz gráfica (WebUI)

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

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xi

Nota: En este ejemplo, no hay

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xii

Convenciones para las ilustraciones

Red de área local (LAN) con

Dominio de enrutamiento virtual Internet

Rango de direcciones IP dinámicas

Dispositivo de red genérico

Icono de conmutador (switch)

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xiii

Convenciones de nomenclatura y conjuntos de caracteres

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xiv

DOCUMENTACIÓN DE NETSCREEN DE JUNIPER NETWORKS

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xv

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos xvi

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 1

Una red configurada con 5 zonas de

El tráfico (indicado por las líneas

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 2

INTERFACES DE ZONAS DE SEGURIDAD

Asignaciones de las interfaces físicas

1/1 1/2 3/1 3/2

2/1 2/2 4/1 4/2

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 3

1/1 1/2 3/1 3/2

2/1 2/2 4/1 4/2

2/1.1 2/2.1 4/1.1 4/2.1

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 4

Dominio de enrutamiento trust-vr Dominio de enrutamiento untrust-vr

Eng DMZ Nota: El icono del castillo representa

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 5

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 6

Dominio de enrutamiento trust-vr Dominio de enrutamiento untrust-vr

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 7

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 8

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 9

Zona de origen Motor de Interfaz Túnel VPN Zona de destino

Dominio de enrutamiento untrust-vr

Para llegar a Utilice

Dominio de enrutamiento trust-vr Túnel VPN

Juniper Networks NetScreen conceptos y ejemplos – Volumen 2: Fundamentos 10