Sei sulla pagina 1di 170

NetScreen JNCIS-FWV Study Guide

The controlled master of this document is held in electronic form.


If this is in printed form it is an uncontrolled copy.


Copyright 2005 Jason Ha. All rights reserved.

No part of this publication may be reproduced, stored in, or introduced into a retrieval system, or
transmitted, in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), without prior written permission of the Author, Jason Ha.



Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 2


DOCUMENT CONTROL

Preparation

Action Name Date
Prepared by: Jason Ha 3-MAR-2005
Reviewed by:

Release

Change Doc
Version
Date
Released
Change By Description
0 1.1 15-JAN-2005 Jason Ha Initial Draft
1 1.2 7-FEB-2005 Jason Ha Condensed Content
2 1.3 3-MAR-2005 Jason Ha Final version


Distribution List

Name Organisation Title
MSS VSA
MSS VSI






Document Properties
Document Name: Number of pages: Last Updated:
NetScreen JNCIS-FWV Study Guide v1.3.doc 170 30/03/2005 14:03:00


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 3
CONTENTS
1. Introduction .................................................................................................................................................................... 6
1.1. Exam Information......................................................................................................................................................... 6
1.2. Exam Content............................................................................................................................................................... 7
2. Basic Firewall/VPN Operations ................................................................................................................................. 9
2.1. NetScreen Firewall Systems...................................................................................................................................... 9
2.1.1. NS500 9
2.1.2. NS5000.....................................................................................................................................................................11
2.2. Interfaces.....................................................................................................................................................................14
2.2.1. Security Interfaces ..................................................................................................................................................16
2.2.2. Functional Interfaces ..............................................................................................................................................16
2.2.3. Tunnel Interfaces ....................................................................................................................................................17
2.3. Advanced Interfaces ..................................................................................................................................................17
2.3.1. Subinterfaces ...........................................................................................................................................................17
2.3.2. Aggregate Interfaces ..............................................................................................................................................18
2.3.3. Redundant Interfaces.............................................................................................................................................18
2.3.4. Virtual Security Interfaces......................................................................................................................................19
2.4. Zones 19
2.4.1. Security Zones.........................................................................................................................................................21
2.4.2. Function Zones........................................................................................................................................................22
2.5. Virtual Routers ............................................................................................................................................................23
2.5.1. Static Routes............................................................................................................................................................23
2.6. Security Policies .........................................................................................................................................................27
2.6.1. Interzone Policies....................................................................................................................................................28
2.6.2. Intrazone Policies....................................................................................................................................................29
2.6.3. Global Policies .........................................................................................................................................................29
2.6.4. Policy Configuration Order....................................................................................................................................30
2.7. Network Address Translation...................................................................................................................................30
2.7.1. Interface NAT...........................................................................................................................................................31
2.7.2. Policy NAT-src.........................................................................................................................................................31
2.7.3. DIPs 32
2.7.4. Policy NAT-dst.........................................................................................................................................................33
2.7.5. MIPs 34
2.7.6. VIPs 35
2.8. Packet Flows...............................................................................................................................................................36
2.9. Review Questions ......................................................................................................................................................38
2.9.1. Review Answers......................................................................................................................................................41
3. VPNs ...............................................................................................................................................................................43
3.1. PKI 43
3.1.1. Digital Certificates ...................................................................................................................................................43
3.1.2. Certificate Authorities .............................................................................................................................................43
3.1.3. Certificate Revocation............................................................................................................................................44
3.1.4. Configuring Digital Certificates on a NetScreen.................................................................................................44
3.2. IKE 45
3.2.1. Modes 46
3.2.2. Proposals..................................................................................................................................................................47
3.3. IPSec 47
3.3.1. Protocols...................................................................................................................................................................47
3.3.2. Encapsulation..........................................................................................................................................................48
3.3.3. Perfect Forward Secrecy.......................................................................................................................................48
3.3.4. Proposals..................................................................................................................................................................48
3.3.5. Proxy-IDs..................................................................................................................................................................48
3.4. Policy-Based VPNs....................................................................................................................................................49
3.5. Route-Based VPNs....................................................................................................................................................49
3.6. IPSec Packet Flow.....................................................................................................................................................51
3.7. Dynamic Peers ...........................................................................................................................................................54
3.8. Hub and Spoke VPNs ...............................................................................................................................................55
3.8.1. Back-to-Back VPNs ................................................................................................................................................58
3.8.2. VPNs using the NHTB............................................................................................................................................60
3.9. Overlapping VPN Networks......................................................................................................................................64

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 4
3.10. VPN Monitoring..........................................................................................................................................................66
3.10.1. Rekey 67
3.10.2. Optimisation.............................................................................................................................................................67
3.11. VPN Groups................................................................................................................................................................67
3.11.1. Priorities....................................................................................................................................................................68
3.12. VPN Troubleshooting................................................................................................................................................69
3.12.1. IKE 69
3.12.2. Security Associations .............................................................................................................................................72
3.12.3. Common VPN Errors..............................................................................................................................................73
3.13. Review Questions ......................................................................................................................................................78
3.13.1. Review Answers......................................................................................................................................................83
4. Network Management................................................................................................................................................88
4.1. Local Management....................................................................................................................................................88
4.2. Remote Management................................................................................................................................................88
4.3. Manage/r IPs...............................................................................................................................................................88
4.3.1. Manage IPs..............................................................................................................................................................88
4.3.2. Manager IPs.............................................................................................................................................................90
4.4. Management Methods...............................................................................................................................................90
4.4.1. CLI 91
4.4.2. WebUI 92
4.4.3. NSM 93
4.5. User Privileges ...........................................................................................................................................................93
4.5.1. Root User.................................................................................................................................................................93
4.5.2. Root System Write/Read Users............................................................................................................................94
4.5.3. Root System Read Only Users .............................................................................................................................94
4.5.4. Virtual System Write/Read Users .........................................................................................................................94
4.5.5. Virtual System Read Only Users ..........................................................................................................................94
4.6. Firewall Logs...............................................................................................................................................................94
4.6.1. Self Log.....................................................................................................................................................................95
4.6.2. Event Log .................................................................................................................................................................95
4.6.3. Traffic Log ................................................................................................................................................................98
4.7. Counters ......................................................................................................................................................................98
4.7.1. Flow Counters..........................................................................................................................................................98
4.7.2. Screen Counters .....................................................................................................................................................99
4.7.3. Hardware Counters...............................................................................................................................................100
4.7.4. Policy Counters .....................................................................................................................................................101
4.8. SYSLOG....................................................................................................................................................................101
4.9. SNMP 102
4.10. Traffic Alarms............................................................................................................................................................104
4.11. Review Questions ....................................................................................................................................................105
4.11.1. Review Answers....................................................................................................................................................108
5. Troubleshooting Traffic Flows..............................................................................................................................110
5.1. Debugging.................................................................................................................................................................110
5.1.1. The Debug Buffer..................................................................................................................................................110
5.2. Snoop 111
5.2.1. Activating Snoop...................................................................................................................................................111
5.2.2. Filtering with Snoop ..............................................................................................................................................111
5.2.3. Snoop Output.........................................................................................................................................................113
5.3. Flow Filters ................................................................................................................................................................114
5.3.1. Using Flow Filters..................................................................................................................................................115
5.3.2. Flow Filter Output..................................................................................................................................................117
5.4. Session Information.................................................................................................................................................121
5.5. Review Questions ....................................................................................................................................................122
5.5.1. Review Answers....................................................................................................................................................128
6. Traffic Management..................................................................................................................................................132
6.1. Interface Bandwidth.................................................................................................................................................132
6.2. Policies and Bandwidth Management ..................................................................................................................132
6.2.1. Priority Queuing.....................................................................................................................................................133
6.2.2. Guaranteed Bandwidth ........................................................................................................................................134
6.2.3. Maximum Bandwidth............................................................................................................................................134
6.2.4. DSCP 135

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 5
6.3. Review Questions ....................................................................................................................................................135
6.3.1. Review Answers....................................................................................................................................................138
7. Virtual Systems..........................................................................................................................................................140
7.1. Creating Virtual Systems ........................................................................................................................................140
7.1.1. Administration........................................................................................................................................................141
7.1.2. Sharing....................................................................................................................................................................142
7.1.3. Exporting and Importing.......................................................................................................................................143
7.2. Traffic Sorting ...........................................................................................................................................................144
7.2.1. Self Traffic ..............................................................................................................................................................144
7.2.2. Through Traffic......................................................................................................................................................144
7.2.3. VLAN-based Classification..................................................................................................................................146
7.2.4. IP-based Classification.........................................................................................................................................147
7.3. InterVSYS Communication.....................................................................................................................................148
7.3.1. Routing....................................................................................................................................................................148
7.3.2. Policies....................................................................................................................................................................148
7.4. Review Questions ....................................................................................................................................................148
7.4.1. Review Answers....................................................................................................................................................150
8. NSRP.............................................................................................................................................................................152
8.1. Clustering..................................................................................................................................................................152
8.2. VSD Groups..............................................................................................................................................................153
8.2.1. VSIs 153
8.2.2. Prioritities................................................................................................................................................................153
8.2.3. Preempt Option.....................................................................................................................................................154
8.2.4. States 154
8.2.5. Heartbeat Messages ............................................................................................................................................155
8.3. Active/Passive ..........................................................................................................................................................156
8.4. Synchronisation........................................................................................................................................................157
8.4.1. Synchronising Configurations .............................................................................................................................157
8.4.2. Synchronising Files...............................................................................................................................................158
8.4.3. Run-Time Objects.................................................................................................................................................158
8.4.4. Synchronising Time..............................................................................................................................................159
8.5. HA Interfaces ............................................................................................................................................................160
8.5.1. Control Messages .................................................................................................................................................160
8.5.2. Data Messages......................................................................................................................................................160
8.5.3. Link Probes ............................................................................................................................................................160
8.6. Active/Active .............................................................................................................................................................161
8.7. Failover 164
8.7.1. Failover Monitoring...............................................................................................................................................164
8.8. Review Questions ....................................................................................................................................................166
8.8.1. Review Answers....................................................................................................................................................169


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 6
1. Introduction
Juniper Networks Certified Internet Specialist in Firewall and VPN (JNCIS-FWV) is a new
stream of certification as part of Juniper Networks Technical Certification Program (JNTCP).
The exam is derived from the previous NCSP (NetScreen Certified Security Professional)
certification and focuses on advanced configuration and troubleshooting of NetScreen
firewall Appliances and Systems.
This study guide will attempt to get you familiar with advanced NetScreen configuration and
administration and provide you with the necessary theoretical and practical training in order
to obtain your JNCIS-FWV certification.
!
Disclaimer: While this study guide was written to assist you in preparing for
the JNCIS-FWV exam, it does not guarantee that you wi ll pass it. The author
has tried their darndest to ensure it includes all the relevant content that is
covered by the exam; you will have to study rigorously in order to understand
and remember it all (and there is plenty to remember).

1.1. Exam Information
The exam is structured around:
75 multiple choice questions
90 minutes completion time
A pass grade of 70 out of a possible 100
!
Some questions only require one answer, but others will require multiple
answers (i.e. select the best 3 answers). However, not all questions will
specify how many answers you need to select! If you only select 2 answers
when the question requires 3 (no, it doesnt warn you that you havent
selected enough silly I know), you will get that question wrong. Make sure
you check at t he bottom left hand corner of the screen. That is where it will
list how many answers you need to select.

The exam is regarded as difficult and it is recommended that candidates have at least 1
year of experience with NetScreen firewall products.
All questions relating to configuration examples and command syntax are based around the
Command Line Interface (CLI). There are no questions, or multiple choice answers based on
the Web User Interface (WebUI).
The exam is generally based on the ScreenOS version 5.0.x firmware.
Although this study guide and accompaniments are self-contained (and hopefully all you
need to pass the exam), additional resources are available to assist in your studies:
Junipers NetScreen Concepts and Examples ScreenOS Reference Guide v5.0.0:
http://www.juniper.net/techpubs/software/screenos/screenos5x/

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 7
Juniper ScreenOS Knowledgebase:
https://www.juniper.net/customers/support/NetScreen_kb/
And worst case, if you need references on standards or a certain technology in general,
remember: Google is your best friend (www.google.com). This guide will not attempt to
cover the detailed theories of the diverse range of technologies that the product taps into. It
is assumed that you understand those technologies, or can quickly pick them up if need be.
1.2. Exam Content
JNCIS-FWV focuses on 7 specific areas of the NetScreen Firewall products:
1. Basic Firewall/VPN Operations:
NetScreen firewall Systems specifications (NS500 and NS5000 series), virtual router
configuration, advanced routing (static routing only), security zones, interfaces (sub,
aggregate, tunnel and redundant), security policies, packet flows and network
address translation.
2. VPNs:
PKI, IKE, IPSec, Policy-based and Route-based VPNs, dynamic peers, NHTB, Hub
and Spoke VPNs, VPN groups and advanced VPN troubleshooting.
3. Network Management:
Local and remote administration configuration, securing administration traffic, user
privileges, management IP addresses, logging (self, event and traffic), counters,
SYSLOG and SNMP.
4. Troubleshooting with Debug/Snoop:
Configuring, using and understanding debug output from Flow Filters and Snoop.
5. Traffic Management:
Interface bandwidth, policy guaranteed bandwidth and maximum bandwidth, priority
queues and DSCP.
6. Virtual Systems:
Virtual System creation, administration, sharing of virtual routers and zones,
importing and exporting interfaces, intraVSYS routing and policies and traffic sorting
(IP Classification and VLANs).
7. NSRP
VSD Groups, clusters, NSRP modes (active/passive and active/active),
synchronisation, HA interfaces and failover.
As a potential JNCIS-FWV candidate, Juniper expects you to have an intimate
understanding of basic level administration and configuration (covered by the JNCIA-FWV
Juniper Networks Certified Internet Associate). Though it is not a pre-requisite to be JNCIA-
FWV certified to obtain the JNCIS-FWV, the content covered here will be easier to
understand if you are.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 8
!
One final note before we dive in. When studying for these types of exams, it
is common to read and understand the overall concepts but gloss over the
specifics (like which bit in a packet should be set to what and when). Like I
mentioned before, the aim of this study guide is to do its darndest to help you
pass, so if it is in here, it is in here for a reason. Please take note of even the
finest details (and I will do my best to note them out in this fashion where
possible) as YOU WILL be tested on them.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 9
2. Basic Firewall/VPN Operations
Despite their simplicity, NetScreen firewalls provide a wealth of functionality. It is your job as
a JNCIS-FWV candidate to understand how to best configure and utilise the firewalls
functionality in order to provide the best enterprise solutions.
2.1. NetScreen Firewall Systems
NetScreen firewalls come in two main types: Appliances (aimed at home, small business and
medium enterprise) and Systems (aimed at large enterprise and telecommunication service
providers). The table below provides a quick snapshot of the differences.
Table 1: NetScreen
Firewall Appliances
and Systems
Appliances Systems
Features
Models 5, 25, 50, 200 series 500, 5000 series
Modular No Yes
Gigabit Ethernet Support No Yes
Aggregate Interface Support No Yes
Virtual Systems Support No Yes

One of the main differences between the Appliances and the Systems is that the Systems
are modular. That is, it is possible to customise a NetScreen System with interfaces most
suitable for a given configuration (Fast Ethernet, Gigabit Ethernet etc). An Appliance comes
with a set type and number of interfaces with which the physical configuration cannot be
changed (though, as we will see later, the function of them can be).
As a JNCIS-FWV, Juniper expects you to understand the ins-and-outs of the NetScreen
Systems as they are the products you will most likely work with (or so Juniper hopes).
!
Though, as of writing this study guide, there are newer models of the
NetScreen Systems available (namely, the ISG2000), the exam only covers
the NS500 and NS5000 series.
2.1.1. NS500
The NS500 is the entry level NetScreen firewall System.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 10

Below are the main specifications for the NS500.
Table 2: NS500 Specifications
Value
Feature

Maximum Performance and Capacity
Firewall performance 700Mbps
3DES performance 250Mbps
Concurrent sessions 250,000
New sessions/second 18,000
Policies 20,000
Interfaces 8 10/100 or mini-GBIC (SX/LX), 4 GBIC (SX/LX)
Virtual IP 4
Mapped IP 4,096
VPN
Site-to-Site VPN Tunnels 5,000
Remote Access VPN Tunnels 10,000
Tunnel Interfaces Up to 1,024
Virtualisation
Maximum number of Virtual Systems 0 default, upgradeable to 25
Maximum number of Security Zones 8 default, upgradeable to 58
Maximum number of Virtual Routers 3 default, upgradeable to 28
Maximum number of VLANs 100 per port
Routing
Maximum number of Static Routes 8,192


!
I know its boring and tedious remembering hardware and performance
specs, but trust me, YOU WILL BE tested on them and they are the easier
questions you will encounter. Dont lose out on any gimme points because
you forgot to memorise the above speeds and feeds.

Apart from the onboard management and dual High Availability interfaces, the NS500
includes 4 modular bays for different interface configurations. 2 of the module bays are
required to be filled for the firewall to function. There are 3 different interface modules
available:
Dual Fast Ethernet Module

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 11

Gigabit Ethernet GBIC Module

Dual Gigabit Ethernet mini-GBIC Module

All NS500 modules are not hot-swappable.
Depending on the combination of modules, the maximum number of usable interfaces
(besides the management and HA interfaces) is 8 (all or a combination of the dual Fast
Ethernets and dual mini -GBICs).
!
Unlike an Appliance which is made up of the CPU, RAM and a general ASIC,
Systems include ASICs on each of the interface modules to further increase
packet processing speeds. When a packet first arrives at a NetScreen
System, the packet is processed through the CPU, but every subsequent
packet that matches the session is processed through the interfaces ASIC.

2.1.2. NS5000
The NS5000 series is the top line of NetScreen firewalls and comes in two flavours, the 5200
and the 5400, aptly named as one has 2 modular bays and the other 4.
NS5200

NS5400

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 12

The tables below list the main specifications for the 5000 series:
Table 3: NS5200 Specifications
Value
Feature

Maximum Performance and Capacity
Firewall performance 4Gbps
3DES performance 2Gbps
Concurrent sessions 1,000,000
New sessions/second 31,000 (M2)/26,000 (M)
Policies 40,000
Interfaces 8 mini-GBIC (SX/LX) or 2 mini-GBIC (SX/LX) + 24 10/100
Virtual IP 8/32 per VSYS
Mapped IP 10,000

Table 4: NS5400 Specifications
Value
Feature

Maximum Performance and Capacity
Firewall performance 12Gbps
3DES performance 6Gbps
Concurrent sessions 1,000,000
New sessions/second 31,000 (M2)/24,000 (M)
Policies 40,000
Interfaces 24 mini-GBIC (SX/LX) or 6 mini-GBIC (SX/LX) + 72 10/100
Virtual IP 8/32 per VSYS
Mapped IP 10,000

Table 5: NS5200/5400 Specifications
Value
Feature

VPN
Site-to-Site VPN Tunnels Up to 16,000
Remote Access VPN Tunnels Up to 25,000
Tunnel Interfaces Up to 4,095
Virtualisation
Maximum number of Virtual Systems 0 default, upgradeable to 500
Maximum number of Security Zones 16 default, upgradeable to 1016
Maximum number of Virtual Routers 3 default, upgradeable to 503

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 13
Maximum number of VLANs (8G SPM) 4000 max: 500 per port
Maximum number of VLANs (2G24FE SPM)
1,254 max: 500 per GigE port, 254 shared among 24 10/100
ports
Routing
Maximum number of Static Routes 30,000

The 5000 series does not include onboard management and HA ports like the 500 series.
Instead, there are two different management modules available, the 5000-M and the 5000-
M2. The management module must be inserted in the first (top) modular bay.
5000-M/M2 management module (yes, they do look the same)

The management module provides overall management and control over the NetScreen
System and other modules and assists primarily with non-flow related tasks (tasks not
dedicated to processing packets). Both modules include a dedicated management interface,
a console port, a modem port, dual dedicated HA interfaces and a compact flash slot. The
difference between the two lies in the processor speed. The 5000-M includes an onboard
600 MHz PowerPC CPU while the 5000-M2 unleashes a dual 1GHz PowerPC CPU
configuration.
The interface modules available for the 5000 series are named Secure Port Modules
(SPMs). There are only two available, an 8 port modular hot-swappable mini -GBIC module
(8G) or a 2 non-modul ar mini -GBIC port and 24 10/100 BaseTX ports module (2G24FE). It is
possible to obtain different mini-GBIC transceivers (SX or LX) for the 8G module.
8G

The 8G module can support up to 4 aggregate interfaces (covered in a later section). The
aggregate interfaces must be paired in a sequence, that is, ports 1 and 2, 3 and 4 and so
forth. It is not possible to mix ports (ports 1 and 4). Ports must also be exactly the same type
(SX and SX/LX and LX) and must reside on the same module (it is not possible, for example,
to aggregate port 1 on modular slots 2 and 3 from a 5400 perspective).
2G24FE

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 14

This module is capable of supporting up to 6 aggregate interfaces, 1 for the GBIC pairs and
5 between the 24 Fast Ethernet ports. Unlike the 8G module, any combination of FE pairs
can be aggregated together, but it is still recommended that they be paired sequentially. It is
not possible to aggregate the GBICs and the FEs together.
Depending on the combination of modules, it is possible to obtain a maximum of 26 useable
ports (1 x 2G24FE) on a 5200 and 78 useable ports (3 x 2G24FE) on a 5400.
2.2. Interfaces
Regardless of their physical specification, and regardless of whether they are part of a
Systems module or fixed to an Appliance, interfaces can be put to a variety of uses.
So how do you change the function of an interface? Simply by binding it to a different type of
zone (Zones are covered in the next section). It is only possible to bind an interface to one
zone, but one zone may have multiple interfaces bound to it. That is, it would be possible, on
an Appliance with 4 interfaces, to assign 2 interfaces to a Security zone (the same zone
even) and 2 to the Management zone in order to have 2 dedicated management interfaces
(yes, you could bind all 4 interfaces to the Management zone but that would be somewhat
silly wouldnt it? Please say yes)
Interfaces can be configured in three modes:
Transparent
Route
NAT
By assigning an interface to a Layer 2 Security zone, the interface is automatically set to
Transparent mode. If the interface is set to a Layer 3 Security zone, then Route or NAT
mode is definable by the administrator. In Route mode, the interface passes traffic without
performing any type of Network Address Translation. In NAT mode, all traffic passing into the
interface (ingress) will have its source IP addresses automatically NATed to that of the
outgoing interfaces (egress) IP address.
!
Despite certain misconceptions, the NATing of source IP addresses using
interface NAT only occurs for traffic destined to the Untrust zone. Traffic
destined to other zones (DMZ for example) will not be NATed, even though
the ingress interface is set to NAT mode.

Although it is possible to mix Layer 3 interfaces (have some NAT and some Route), it is not
possible to mix Layer 3 and Layer 2 interfaces. The NetScreen firewall either needs to be a
routing firewall or a switching firewall, it cannot be both at once (though, the exception to this
is Virtual Systems, covered in a later section).

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 15
Interface Details
To obtain information about the available interfaces, use the command:
get interface
Output:
A - Active, I - Inactive, U - Up, D - Down, R - Ready

Interfaces in vsys Root:
Name IP Address Zone MAC VLAN State VSD
eth1 10.3.1.1/24 Trust 0040.ab33.12f0 - U -
eth2 10.2.6.1/24 DMZ 0040.ab33.12f5 - U -
eth3 100.100.100.2/24 Untrust 0040.ab33.12f6 - U -
eth4 192.168.1.1/24 Provisioni~ 0040.ab33.12f7 - U -
vlan1 0.0.0.0/0 VLAN 0040.ab33.12ff 1 D -

To obtain specific information about a particular interface, use the command:
get interface interface
Output:
Interface ethernet1:
number 0, if_info 0, if_index 0, mode route
link up, phy-link up/half-duplex
vsys Root, zone Trust, vr trust-vr
dhcp client disabled
PPPoE disabled
*ip 10.3.1.1/24 mac 0040.ab33.12f0
*manage ip 10.3.1.1, mac 0040.ab33.12f0
route-deny disable
ping enabled, telnet disabled, SSH enabled, SNMP disabled
web enabled, ident-reset disabled, SSL enabled
webauth disabled, webauth-ip 0.0.0.0
RIP disabled
bandwidth: physical 100000kbps, configured 0kbps, current 0kbps

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 16
total configured gbw 0kbps, total allocated gbw 0kbps
DHCP-Relay disabled
DHCP-server disabled
The wealth of information presented here can inform you as to whether the interface is up,
what the management IP address, what management options have been enabled and
whether any traffic shaping properties have been configured.
2.2.1. Security Interfaces
The most common use of an interface is to allocate it to a Security zone (making it a Security
interface) and using it to firewall traffic between the same or another zone. If the NetScreen
is to be placed in Layer 3 mode (function as a router), then IP addresses can also be
assigned to the interfaces. If left in Layer 2 mode (function as a switch), then IP addresses
are not required.
The necessary binding to become a Security interface is not just restricted to physical
interfaces. Subinterfaces, aggregate interfaces, redundant interfaces, Virtual Security
interfaces (VSIs), loopback interfaces and even tunnel interfaces can all be bound to a
Security zone.
Configuring a Security Interface
If the interface has been previously configured for another purpose, it is necessary to remove
all configured specifics of the interface before being able to change its zone.
unset interface interface ip
set interface interface zone security_zone
And if the interface is a Layer 3 interface:
set interface interface ip ip-address/mask(in octet)
!
Even though the NetScreen CLI provides a means to short-cut commands,
(and we all take advantage of it), for the purposes of the exam, it is necessary
to know the full command line syntax.

2.2.2. Functional Interfaces
When assigned to a Function zone, interfaces take on a specific task not related to standard
traffic processing. It is possible for an interface to be bound to a Management zone for
example, so the interface becomes the dedicated interface in which to manage the firewall.
Another function is to dedicate the interfaces for providing High Availability by putting them in
the HA Function zone.
!
Only physical interfaces may be placed in the HA zone.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 17
2.2.3. Tunnel Interfaces
As discussed later in the VPN section, a tunnel interface is a means for a Route-Based VPN
to function by routing traffic through the tunnel interface and having the necessary VPN
properties applied. Tunnel interfaces are bound to Security zones to facilitate policy
configuration.
Creating a Tunnel Interface
set interface tunnel.number zone security-zone
Where number corresponds to the number you would like to assigned to the
interface (eg. tunnel.1)
2.3. Advanced Interfaces
2.3.1. Subinterfaces
When the number of physical interfaces no longer suffices, it is possible to create
Subinterfaces (logical extensions of a physical interface) using the 802.1Q VLAN tagging
and identification method. These logical interfaces function just as any physical interface in
the sense that they can be assigned an IP addresses, be allocated to any Security zone
(even i f it is different to the actual physical interfaces Security zone) and perform Network
Address Translation. There are however, a few restrictions:
The maximum bandwidth of a Subinterface can never exceed that of the physical
interface
The subinterface inherits the interface mode from the physical interface (i.e. if the
physical interface is in Route mode, then the Subinterface will automatically be in
Route mode and cannot be changed from it)
The only interfaces that can have Subinterfaces are: physical interfaces, redundant
interfaces and aggregate interfaces
If an interface with one Subinterface configured is connected to a switch, then the
switch must be VLAN aware
If an interface with more than one Subinterface configured is connected to a switch,
then the switchs interface must be set to trunk and must be a member of all the
relevant Subinterface VLANs
When creating a Subinterface, it is necessary to specify an interface ID and a VLAN tag. The
notation of the interface is: interface.ID. For example, ethernet4.5, aggregate1.10,
redundant3.500. The ID and the tag do not need to be the same number, though, itll save
you plenty of confusion in the long term if they are. The interface ID can be anything from 1
to 4095.
The number of Subinterfaces you can create is dependant on the restrictions of the firewall
you are using.
!
It is important to remember the notation for each interface type. Not only will
this assist you in quickly determining what type of interface you are dealing
with, but it is also often tested for in the exam.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 18
Creating Subinterfaces
set interface interface.ID zone zone
set interface interface.ID ip ip-address/mask(octet) tag VLAN-tag
2.3.2. Aggregate Interfaces
Aggregate interfaces are only supported on the 5000 series systems and is a method of
increasing bandwidth by combining two interfaces together. There are restrictions regrinding
how and which interfaces can be aggregated. Please refer to the NS5000 section for details.
Creating Aggregate Interfaces
set interface aggregate<number> zone zone
set interface aggregate<number> ip ip-address/mask(octet)
set interface aggregate<number> route|nat
First Interface:
set interface interface<module>/port aggregate aggregate<number>
Second Interface:
set interface interface<module>/port aggregate aggregate<number>
2.3.3. Redundant Interfaces
Redundant interfaces allow you to achieve a link-level of redundancy by combining two
physical interfaces together, whereby one physical interface acts as primary and the other
backup. In the instance that a link is lost on the primary interface, the second interface
becomes active and retains the up status of the overall link.
Only physical interfaces can be grouped into a Redundant interface. It is not possible to
group Subinterfaces. However, it is possible to assign a VLAN tag to a Redundant interface,
and it is also possible to create Subinterfaces from a Redundant interface.
All Redundant interfaces follow the naming convention redundant1, redundant2 etc. On a
5000 System, the same restrictions regarding which interfaces must be grouped to form an
Aggregate interface also apply for Redundant interfaces.
Though it is not essential, it is recommended that each physical interface of the Redundant
interface group is connected to different layer 2 devices.
When the primary interface fails in a Redundant group, it is possible to enforce a holddown
time, dictating how long the backup interface should wait before becoming primary. This
must be configured on both physical interfaces prior to being grouped into the Redundant
interface.
Configuring the Holddown Timer
Issue this command on both physical interfaces:
set interface interface phy holddown number

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 19
Where number is the number of seconds an interface should wait before becoming
primary.
It is best practice to specify the interface that will be the primary interface in the Redundant
interface group. Otherwise, the firewall will take the first interface added into the group as the
primary.
Creating a Redundant Interface
set interface redundant<number> zone zone
set interface redundant<number> ip ip-address/mask(octet)
For the first interface:
set interface physical-interface group redundant <number>
For the second interface:
set interface physical-interface group redundant <number>
Changing the mode of the interface:
set interface redundant<number> route|nat
Assigning a Manage-IP:
set interface redundant<number> manage-ip ip-address
Assigning the primary interface:
set interface redundant<number> primary physical-interface
2.3.4. Virtual Security Interfaces
When NetScreen firewalls are clustered together with NSRP, all the existing interfaces of
both firewalls are converted to Virtual Security Interfaces (VSIs). VSIs belong to a respective
Virtual Security Device (VSD) Group. Depending on how many VSD Groups exist in a
NetScreen cluster, the firewall will have a certain number of VSIs for each VSD Group. VSIs
can be identified with the notation: interface:<VSD Group Number>. For example,
ethernet4:0 is Ethernet interface 4 and belongs in the VSD Group 0.
VSIs and VSD Groups are covered in full detail in the NSRP section.
2.4. Zones
NetScreen firewalls view zones as logical segregations for the purposes of security or
functionality. When we typically think of a standard firewall setup, we think of an internal
network (and sometimes a DMZ), being protected from an external network such as the
Internet. NetScreen refers to these segregation of areas as Security zones (trust zone the
internal network, DMZ zone the DMZ network and Untrust zone the Internet). Other
zones are used to provide dedicated functions to the firewall and are known as Function
zones (Management zone, HA zone). Tunnel zones also exist for the explicit purpose of VPN
functionality.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 20
As mentioned in the interface section, an interfaces function can change depending on
which zone it is bound to. Remember that it is only possible to bind an interface to a single
zone, but one zone may have many interfaces bound to it. Zones are in turn bound to virtual -
routers. We now start to see the fundamental NetScreen three-tiered architecture (interfaces
-> zone -> virtual -router).
Zone Details
To obtain detailed information regarding the available zones, issue the command:
get zone
Output:
Total 14 zones created in vsys Root - 8 are policy configurable.
Total policy configurable zones for Root is 8.
------------------------------------------------------------------------
ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr hidden Root
1 Untrust Sec(L3) Shared untrust-vr ethernet3 Root
2 Trust Sec(L3) trust-vr ethernet1 Root
3 DMZ Sec(L3) trust-vr ethernet2 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr null Root
6 HA Func trust-vr null Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) trust-vr v1-untrust Root
12 V1-Trust Sec(L2) trust-vr v1-trust Root
13 V1-DMZ Sec(L2) trust-vr v1-dmz Root
14 VLAN Func trust-vr vlan1 Root
16 Untrust-Tun Tun trust-vr hidden.1 Root
100 Provisioning Sec(L3) trust-vr ethernet4 Root
------------------------------------------------------------------------
It is possible to create additional custom Security zones. The number of zones that can be
created is a restriction specific to each model.
All zones are referenced by a zone ID. Zone IDs 7-9 and 15 are reserved for future use. All
custom defined zones have a zone ID of 100 or greater.
It is possible to obtain further information regarding a zone by issuing the commands:
get zone zone

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 21
Or
get zone id zone-i d
Output:
Zone name: Trust, id: 2, type: Security(L3), vsys: Root, vrouter:trust-vr
Intra-zone block: Off, attrib: Non-shared, flag:0x6208
TCP non SYN send reset: On
IP/TCP reassembly for ALG on traffic from/to this zone: No
Asymmetric vpn: Disabled
Policy Configurable: Yes
Interfaces bound:1. Designated ifp is ethernet1
interface ethernet1(0x1ab9ed0)
2.4.1. Security Zones
The NetScreen firewall uses Security zones to effectively apply security policies. When
defining security policies, it is necessary to specify which Security zone traffic will originate
from, and which Security zone the traffic will be destined to.
Security Zones can be configured as a Layer 3 zone (for when a NetScreen is set to
Route/NAT mode) or a Layer 2 zone (for when the NetScreen is set to transparent mode).
By default, there are 4 Layer 3 Security zones (Trust, Untrust, DMZ and Global) and 3 Layer
2 Security zones (V1-Trust, V1-Untrust and V1-DMZ).
!
Its important not to confuse a Security zone with a particular network. A
network is defined not by zone, but by the interface, and since a zone can
have multiple interfaces bound to it, it can represent numerous different
networks. For example, a single Trust Security zone can have 4 interfaces
bound to it, each interface representing a different network such as
192.168.1.0/24, 192.168.2.0/24 and so forth.

The Screen options allow a Security zone to defend itself from malicious probes and attacks
such as port-scans and various Denial of Service attacks. These options can be selectively
enabled or disabled by the administrator. Configuration and details regarding the Screen
function is not covered as part of the JNCIS-FWV.
Something that is included in the JNCIS-FWV however, and is extremely important, is the
concept of Intrazone Blocking and Policies. We will cover these concepts in more detail in
the respective section, but when configuring a zone, an option exists to turn Intrazone
Blocking on or off. When Intrazone Blocking is disabled for a zone, traffic from and to that
same zone is explicitly permitted. Taking the example above, if all 4 of our interfaces are
bound to the Trust zone, and the Trust zone has Intrazone Blocking disabled (which it does
by default), then all traffic to and from those networks are permitted to pass through the
NetScreen without any configured policies.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 22
But wait what if I want to restrict that traffic with policies and dont want it to be permitted
by default? I hear you ask! That is the purpose of enabling Intrazone Blocking. Now, all
traffic from and to the same zone will be explicitly denied unless a policy exists to permit it.
But isnt it strange creating a policy from and to the same zone? How does the policy know
which interface Im referring to when the policy is within a zone and not between interfaces?
The simple answer is, no, its not strange (especially if youre using the NetScreen as an
internal departmental firewall) and the NetScreen simply works out which interfaces traffic is
allowed from and to based on the source and destination addresses of the policy.
Creating a Security Zone
To create a layer 3 zone:
set zone name zone
To create a layer 2 zone:
set zone name zone l2 1
!
When creating a layer 2 zone, all zone names must begin with L2-, so for
example, L2-marketing. Also, the 1 represents the VLAN ID for the Layer 2
zone which must always be set to 1 (VLAN1).

To specify which virtual-router a zone should be bound to:
set zone zone vrouter vrouter
To configure Intrazone Blocking:
set zone zone block
2.4.2. Function Zones
Interfaces bound to a Function zone are intended to perform a specific task not related to the
processing of standard network traffic. By default, there are 5 Function zones:
MGT (for dedicated firewall management)
HA (for dedicated HA)
Self (for all connectivity direct at the NetScreen as opposed to through the
NetScreen)
Null (a zone to temporarily allocate interfaces not bound to any other zone)
VLAN zone (the zone in which the VLAN1 interface resides when the firewall is in
transparent mode).
!
With respect to the MGT and HA zones, an interface which is bound to a
Security zone can still be used for the purposes of management and high
availability. However, by separating an interface off to the dedicated Function
zone, you can ensure that those forms of administrative traffic will not be
disrupted (intentionally or unintentially) by standard network traffic.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 23

2.5. Virtual Routers
All firewalls can route (well, layer 3 ones anyway), but NetScreen firewalls dont just route;
they include virtual routers which can be configured in their own right. Lets not get down to
the DoD nitty gritties about why having routers on each side of a firewall is best practice (ala
the screen subnet method), but in short, the NetScreen can simulate this with the two default
virtual routers included with the firewall: trust-vr and untrust-vr.
By default, all zones are bound to the trust-vr. However, if the main intention was to ensure
that external -type zones could not see or accidentally route into more internal -type zones,
then its a smashing idea to separate the zones out and bind them to different virtual -routers.
Virtual routers also include the ability to provide dynamic routing (OSPF, BGP, RIP etc).
Additional virtual routers can be created to provide further segregation of zones. The number
of additional virtual routers creatable is dependant on the NetScreen model.
Virtual Router details:
To obtain information regarding virtual routers, issue the command:
get vrouter
Output:
* indicates default vrouter
A - AutoExport, R - RIP

ID Name Vsys Owner Routes Flags
1 untrust-vr Root shared 2/max
* 2 trust-vr Root shared 7/max

total 2 vrouters shown and 0 of them defined by user
Changing the Default Virtual Router:
To change the default virtual router for a NetScreen (root or virtual system):
set vrouter vrouter default-vrouter
2.5.1. Static Routes
Although the NetScreen is capable of both static and dynamic routing, only static routing is
covered in the JNCIS-FWV.
In order for traffic to route properly between networks through the firewall, it is important that
the NetScreen understands where traffic needs to go (if it is not a directly connected
interface). This is achievable through the configuration of static routes. Heres the element of
complexity though as a NetScreen firewall has more than one virtual router, it is often

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 24
necessary to configure routes through or between both virtual routers (basic NetScreen
configurations can just use the one virtual router so static routes only need to be added to
the one virtual router).
Creating a Static Route:
Static routes can be network or host based. To add a static route to a virtual router:
set vrouter vrouter route ip-address/mask(octet) interface interface gateway gw-ip-
address metric metric
The interface is the outgoing interface for traffic, and ultimately how the traffic will
reach the next-hop gateways IP address (gw-i p-address). At times, a destination will
reside on an interface, even though its network is different (as we will see with NAT-
dst and route-based VPNs) and hence, the gateway portion of the command can be
omitted. The metric portion of the command is also optional.
Sometimes, a particular route or a next-hop gateway exists on another virtual router, and as
such, it is necessary to create the static route from one virtual router to the other.
set vrouter vrouter route ip-address/mask(octet) vrouter dst-vrouter
Where dst-vrouter is the virtual router ultimately responsible for passing the traffic to
the next-hop gateway.
To configure a default route, simply use 0.0.0.0/0 as the network IP address and mask (but
of course, you didnt need me to tell you that).
Just to throw you off, sometimes in documentation and troubleshooting guides (and in the
config file) you will see static routes being added in this way:
set route ip-address/mask(octet) gateway gw-ip-address
Indeed, this command is valid. Why? Because of the default virtual router setting
remember? As a NetScreen can be configured with a default virtual router, all routes
added using the above short-cut command are added to the default virtual router.
!
The exam often tries to trick you with this clever foolery! Dont be dooped into
answering the question incorrectly just because the details of the question or
answer options use the short-cut static route command.

Listing the Routing Table
It is ever useful when troubleshooting routing issues (and validating configurations) to ensure
your routing has been configured correctly. To view the NetScreens routing table:
get route
Output:
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
untrust-vr (2 entries)
--------------------------------------------------------------------------------

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 25
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 2 0.0.0.0/0 eth3 100.100.100.1 S 20 1 Root
* 1 100.100.100.0/24 eth3 0.0.0.0 C 0 0 Root
trust-vr (7 entries)
--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 4 0.0.0.0/0 n/a untrust-vr S 20 0 Root
* 7 1.1.1.1/32 eth2 10.2.6.100 S 20 1 Root
* 6 10.1.0.0/16 eth2 10.2.6.2 S 20 1 Root
* 2 10.2.6.0/24 eth2 0.0.0.0 C 0 0 Root
* 1 10.3.1.0/24 eth1 0.0.0.0 C 0 0 Root
* 8 192.168.1.0/24 eth4 0.0.0.0 C 0 0 Root
* 5 10.5.0.0/16 eth1 10.3.1.9 S 20 1 Root
As you can see, the routing table provides a wealth of information (yes, and all tested on).
The asterix at the start of an entry dictates whether a particular route is active or not.
Inactivity may be due to several things (when related to dynamic routing), but in the static
routing world, one can assume that it is due to the interface being disconnected.
All routes have a route ID. By the route prefix, we can also determine what type of route it is
(C directly connected, S static route). A legend exists at the top of the table for those of
us with poorer memory (like myself). The route preference is not to be confused with the
route metric (even though, they by and large do serve the same greater good). A route
metric determines the ease of routing to the host or network. Different routing protocols have
different routing metrics, but for simplicity sake, we can say that the lower the metric count,
the more likely it will be selected as the route. However, you encounter some interesting
circumstances where there may be two different route paths to arrive at the same
destination, and they both happen to have the same metric. One way might be over Gigabit
Fibre, but the other way over good ol fashion dialup. In that instance, you would want to add
a preference to ensure all traffic goes through to the Gigabit Fibre connection by default. The
closer the preference value is to 0, the higher the preference.
Obtaining Specific Route Information
Route IDs provide a wealth of benefit as it allows you to perform a detailed lookup on a
configured route.
get route id id
Output:
route in vr trust-vr:
--------------------------

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 26
id: 7
IP address/mask: 1.1.1.1/32
next hop (gateway): 10.2.6.100
preference: 20
metric: 1
outgoing interface: ethernet2
vsys name/id: Root/0
tag: 0
flag: 00000040/00000008
type: static
status: active (for 7 days 7 hours 1 minutes 9 seconds)
The main tid-bit of information you want to obtain is how long the route has been active for.
If only the world could be so lucky as having the tiny routing table in the example. In the real -
world, routing tables can get quite large (especially at central sites which provide the
interconnectivity for numerous numerous networks). Sometimes combing through a routing
table to determine which route selected traffic is taking requires as much intensive
concentration as a magic-eye 3D image (but with more frustration). The NetScreen comes to
our rescue with a simple command to do this for us:
get route ip ip-address
Output:
Destination Routes for 1.1.1.1
---------------------
trust-vr : => 1.1.1.1/32 (id=7) via 10.2.6.100 (vr: trust-vr)
Interface ethernet2 , metric 1

potential routes in other vrouters:

untrust-vr : => 0.0.0.0/0 (id=2) via 202.65.22.1 (vr: untrust-vr)
Interface ethernet3 , metric 1
This quickly allows you to determine which routes in the routing table the firewall is
attempting to use and the alternative routes which may be possible (and quite possibly the
one you prefer the traffic to take).

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 27
2.6. Security Policies
Security policies are the life-blood of firewall enforcement and as such, how intuitive the
policies are to create and how well they can be implemented affects the firewalls overall
security posture. As we saw in the last section, policies are configured around the concept of
zones. Policies from and to different zones are known as Interzone policies, from and to the
same some are known as Intrazone policies and a concept that we will now introduce is the
from and/or to the Global zone (which represents all zones) known as Global policies.
Though we will explore the specifics in more detail later, it is important to understand the
policy search order that takes place when a packet first arrives at the firewall. Assuming a
route to the destination network has been found, the NetScreen will determine which source
and destination zones are applicable to the traffic flow. It will then begin performing a policy
lookup in the following order:
1. If the source and destination zones are different, the NetScreen will perform a policy
lookup using the Interzone policy list.
Or
If the source and destination zones are the same, the NetScreen will perform a
policy lookup using the Intrazone policy list.
2. If the NetScreen performs either an Interzone or Intrazone policy lookup and fails to
find a match, it will attempt to perform a lookup on the Global policy list.
3. If the NetScreen fails to find a policy match after performing an Interzone and Global
policy lookup, the NetScreen will then apply the implicit policy to the packet (which is
to drop and not log by default this policy can be changed).
Or
If the NetScreen fails to find a policy match after performing an Intrazone and Global
policy lookup, the NetScreen will then apply the Intrazone Blocking setting for that
particular zone (generally a permit in this instance).
!
There are numerous questions in the exam that deal with the correct ordering
of procedures, so Id recommend you come up with a method of
remembering them that works best for you. Use an acronym if it helps like
gud Granular (Inter/Intrazone), Universal (Global), Default.

Obtaining Policy Details
In order to see all the policies configured for your NetScreen firewall, issue the command:
get policy
Output:
Total regular policies 2, Default deny.
ID From To Src-address Dst-address Service Action State ASTLCB
1 Trust Untrust Any Any ANY Permit enabled ---XXX
2 Untrust Global Any Any ANY Deny enabled ---X-X

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 28
The top of the output displays the number of policies and the implicit policy (in this instance,
deny). The policies are then referenced by a policy ID, followed by the general properties of
the policy. Two important properties to pay attention to are the policy State (whether the
policy is enabled or disabled) and the ASTLCB flags. The flag settings are: Alarm, Schedule,
Traffic shaping, Log, Count and session Backup.
More detailed information can be obtained from a specific policy by issuing the command:
get policy id policy-id
Output:
name:"none" (id 1), zone Trust -> Untrust,action Permit, status "enabled"
src "Any", dst "Any", serv "ANY"
Policies on this vpn tunnel: 0
nat off, url filtering OFF
vpn unknown vpn, policy flag 0000, session backup: on
traffic shaping off, scheduler n/a, serv flag 00
log yes, log count 0, alert no, counter yes(3) byte rate(sec/min) 0/0
total octets 0, counter(session/packet/octet) 0/0/3
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/-1
No Authentication
No User, User Group or Group expression set
It is often necessary to check the specifics of a policy to ensure that the policy is taking
effect. Viewing the specifics of the policy also displays the NAT properties (if any Policy-
based NATs have been set).
2.6.1. Interzone Policies
In a typical NetScreen firewall configuration, various interfaces are applied to various zones
and traffic will need to be permitted or denied between these zones. In order to achieve this,
it is necessary to create Interzone policies.
Creating Interzone Policies
In order to create a basic Interzone policy, the following command syntax should be used:
set policy from src-zone to dst-zone src dst service action [options]
The src-zone (source zone) and dst-zone (destination zone) can be applied to any two
different zones. The src (source) and dst (destination) can be any object (host, network or
group) from the relevant zones address book. The service can be any service from the pre-
defined or user-defined service books. The action can be permit, deny or tunnel. The
numerous options available include (but are not limited to) log, count, traffic, schedule and
auth.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 29
!
The JNCIS-FWV does not place a large emphasis on advanced policy
creation as it is covered in the JNCIA-FWV. Hence, numerous additional
policy configuration options will not be covered by this study guide, and if they
somehow manage to sneak in, it is assumed that you have an understanding
of such usage.

When a policy is created, the NetScreen automatically assigns it a random policy ID (well,
its not so much random as it is the next sequential policy ID available). It is possible to
manually specify the policy ID during the policy creation by appending id id after the
command set policy.
!
A quick reminder Unlike policies created using the WebUI, objects cannot
be dynamically created when being specified in a new policy using CLI. For a
policy to be valid, the src and dst objects used must already exist in the
zones respective address book. The explanation of addresses and address
boks is not covered as part of the JNCIS-FWV.

2.6.2. Intrazone Policies
When a zone has numerous interfaces bound to it , and it becomes necessary to enforce
policies between the different networks associated with those interfaces, the NetScreen
allows us to create Intrazone policies to permit or deny such traffic.
Remember that it is necessary for the Intrazone Block to be enabled to ensure that traffic is
not automatically permitted between interfaces bound to the same zone..
Creating Intrazone Policies
The syntax for creating an Intrazone policy is the same as an Interzone policy:
set policy from src-zone to dst-zone src dst service action [options]
The difference being that the src-zone and the dst-zone will be the same zone.
2.6.3. Global Policies
Global policies allow us to create blanket policies, covering enforcement from and/or to all
zones. The typical usage for Global policies include permitting traffic from our Trust zone to
any other zone, and performing global denies.
!
While it is possible to rely on the implicit policy (with a default value of deny),
it is best practice to configure the last rule of your security policy to be a
global deny with logging enabled as the implicit policy does not log. It also
prevents a security breach in the instance that the default value for the
implicit rule is accidentally changed to a permit.

Creating a Global Policy
Once again, the syntax for the policy creation is the same:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 30
set policy from src-zone to dst-zone src dst service action [options]
The difference on this occasion being that either, or both the src-zone and dst-zone are set
to the zone global.
2.6.4. Policy Configuration Order
There is no hard and fast way as to which components should be configured first when
creating a policy instance. However, some commands during policy creation will not be
accepted until those components are configured. As a JNCIS-FWV, Juniper has a
recommended order which you should endeavour to commit to memory (for the purpose of
the exam anyway). As constantly demonstrated in the ScreenOS Configuration Examples
document, the rough order should be:
1. Configure the interface(s)
2. Create the address entries
3. Create custom service and/or service group (can be omitted if pre-defined services
are being used)
4. Configure the correct routes on relevant virtual routers
5. Create the policy
2.7. Network Address Translation
Without delving into the details, Network Address Translation (NAT) is the translation of the
source (NAT-src) and/or destination (NAT-dst) IP address in an IP packet header. An
optional extra is to translate the port number in the TCP segment or UDP datagram header.
NetScreen firewalls support various NATs at various points of the firewall.
As with most things NetScreen related, NAT also has its priorities. This is particularly the
case with NAT-src. A quick explanation to clarify:
1. If the interface is configured in Route mode (and no Policy NAT has been
configured), the traffic will not be NATed.
2. If Interface NAT has been enabled, traffic will be NATed using the egress interfaces
IP address.
3. If Policy NAT-src has been configured without a specified DIP, traffic will be NATed
using the egress interfaces IP address regardless of whether the interface is in NAT
or Route mode.
4. If Policy NAT-src has been configured with a specified DIP, traffic will be NATed
using an address from the DIP pool regardless of whether the interface is in NAT or
Route mode.
5. If the source host or network relates to a configured VIP or MIP, traffic will be NATed
using the NAT IP address of the configured VIP or MIP regardless of whether Policy
NAT-src is used and whether the interface is in NAT or Route mode.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 31
!
Sometimes when you observe the traffic leaving your NetScreen, the source
IP address may not be what you expected. This is often due to the fact that
the host or network is referenced in a MIP or VIP. MIP and VIP NAT takes
precedence over all other forms of NAT, and hence, even if you do have
Policy NAT configured, the MIP or VIP NAT will take effect first.

2.7.1. Interface NAT
The simplest application of NAT-src is to configure it at the interface level. Remember that it
is possible to set an interface bound to a layer 3 zone in either Route mode or NAT mode. If
an interface is set to Route mode, no automatic NAT-src is applied. However, if the interface
is in NAT mode, then NAT-src will automatically be applied using the egress interfaces IP
address.

!
Just another reminder that Interface NAT only applies the NAT-src when
traffic is destined to the Untrust zone. Even if an interface is set to NAT
mode, NAT-src is not applied if the traffic is destined to any other zone.

Applying Interface NAT
In order to configure Interface NAT, simply set an interface to NAT mode with the following
command:
set interface interface nat
2.7.2. Policy NAT-src
Interfaces set to Route mode are not excluded from the NAT party. Several options are
available in which to apply NAT-src, and in fact, the policy NAT-src options are generally
preferred over standard Interface NAT becaus e of the additional flexibility they provide.
When creating or editing a policy, it is possible to access advanced policy features and apply
a NAT-src function. The default option is to select a DIP (dynamic IP) address pool from the
available list. If no DIP is selected (or it is left as default), the egress interface will be used.
This provides more flexibility than interface NAT as you can perform the desired NAT-src on
a policy-by-policy basis.
!
As the egress IP address is a single IP address, the NetScreen firewall
automatically enables Port Address Translation to facilitate the number of
hosts being NAT-srced.

Configuring Policy NAT-src
In order to configure Policy NAT-src, simply append the relevant options near the end of a
policy configuration:
set policy from src-zone to dst-zone src dst service nat src action

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 32
This will NAT the source IP address of all outgoing packets using the egress interface
(regardless of the zone the interface is bound to).
2.7.3. DIPs
At some point it will be necessary to translate the source IP for outgoing traffic to something
other than the egress interface IP address. Dynamic IP (DIP) address pools allow you to
translate the source address to a single or range of available IP addresses. As DIPs are
applied on a policy-by-policy basis, it is possible to apply DIPs selectively, increasing the
flexibility of standard policy NAT-src.
!
It is important to ensure that your DIP pool does not include the IP address of
the interface, any other device on that network and any MIPs or VIPs on that
network.

A DIP pool with a single IP address can support up to 64,500 hosts concurrently if Port
Address Translation has been enabled. It is possible to configure DIP without PAT, as some
systems are configured to expect a particular source port.
!
If you are going to disable PAT, just remember that the DIP pool size will now
have to be large enough to facilitate every IP address that will be using it, as
there will be a one-to-one relation of real IP addresses to NAT-src DIP
addresses.

Creating a DIP Pool
To create a DIP pool, issue the following command:
set interface interface dip dip-id start-IP end-IP
The dip-id can be 5 or any number above it. The start-IP and end-IP can be the same IP
address if configuring a DIP pool with a single host.
!
NetScreen reserves DIP IDs 1 to 4 for internal use. Most commonly, the DIP
ID of 2 is used for all NAT-src instances referring to the egress interface.

In order to disable PAT, append the option: fix-port to the end of the above command.

On occasion, a single host will open multiple outbound connections on different ports, and
when it matches a policy with a DIP pool applied, the source address will be different for
each connection. As a result, it may be necessary in some instances to use the Sticky DIP
option.
Enabling Sticky DIP
To enable Sticky DIP, enter the command:
set dip sticky

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 33
Note that once Sticky DIP has been enabled, it will be applied to all DIP instances.

In instances where a Class C subnet is being NAT-srced, you may want to retain the original
last octet of the host IP address, but translate the other octets. So for example, translating
192.168.1.1 to 200.200.200.1. NetScreens allow you to perform NAT-src using DIPs for an
entire network easily with the Address Shift option.
Creating a DIP pool with Address Shift
In order to configure a DIP pool with Address Shift for a range of IP addresses or a whole
network, enter the command:
set interface interface dip dip-id shift-from original -IP to shiftstart-IP shiftend-IP
In this instance, if you wanted to shift a whole Class C of 192.168.1.0 to 200.200.200.0, you
would use 192.168.1.1 as the original-IP and 200.200.200.1 and 200.200.200.254 as the
shiftstart -IP and shiftend-IP addresses.
Using a DIP pool in a Policy
In order to use a configured DIP pool in a policy, simply modify the policy entry as follows:
set policy from src-zone to dst-zone src dst service nat src dip-id dip-id action
Where dip-i d is the ID of the DIP pool that you created.
2.7.4. Policy NAT-dst
Policy NAT-dst allows you to configure advanced destination NATs at the policy level. It is
most often used to provide advanced NAT configurations when there are overlapping
networks in a VPN. When using Policy NAT-dst, it also possible to apply Port Address
Translation in order to perform a one-to-many destination NAT configuration.
Three steps are necessary to enable Policy NAT-dst to take place:
1. A host or network with the NAT IP address must be created in the address book of
the same zone as the real host or networks IP address.
2. A static route must be added to the NAT IP address. The static route must point to
the interface where the actual real IP address range is configured.
3. The NAT-dst must be configured in the policy.
!
Policy NAT-dst, unlike MIPs and VIPs, are not often used for standard
inbound NAT scenarios. This is because it is not possible for the NAT IP
address to be on the same network as the ingress interface. In other words, it
is not possible to translate a public IP address used on your external network
to a private address on say, your DMZ network using Policy NAT-dst.

Configuring Policy NAT-dst
In order to configure Policy NAT-dst, issue the following commands:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 34
set address zone address-name NAT-i p-address/mask(octet)
set vrouter vrouter route NAT-i p-address/mask(octet) interface interface
set policy from src-zone to dst-zone src address-name service nat dst ip real-i p-
address permit
Remember that the address-name entry that represents the NAT IP has to reside in the
same zone as the real IP. When the NetScreen performs the route lookup, it needs to be
able to resolve both the NAT IP and the real IP to the same zone so the policy matches
accordingly.
The route is added to the same vrouter that the egress interface is bound to (or the zone in
which the egress interface is bound to to be more precise).
!
For advanced configurations, it is possible to apply Policy NAT-src and Policy
NAT-dst to traffic at the same time. The NetScreen will always perform Policy
NAT-dst before it performs Policy NAT-src.

2.7.5. MIPs
Mapped IP (MIP) addresses are the most common way in which inbound destination NAT is
performed on a NetScreen firewall. They provide a means of mapping one IP address to one
other (one-to-one relationship). A MIP can also be used to translate an entire network range
to another network range. MIPs are created on an interface and the NAT IP consumes one
of the IP addresses available on that network. On some NetScreen firewalls, it is possible to
use the actual interfaces IP address as the NAT IP of a MIP. The number of MIPs that can
be configured on a NetScreen is dependant on the model.
!
When an internal host is used as the Real IP of a MIP, outgoing traffic
initiated from that host will be NAT-srced to the NAT IP address defined in the
MIP.

When MIPs are created, they are stored in the Global zones address book even though the
interface they are configured on may reside in a different zone. Why is this necessary? If you
think about it, if the MIP can only be referenced by the interface and hence zone its created
in, then your policy will be incorrect. Lets use an interface bound to the Untrust zone as an
example. If you created a MIP on that interface which translates to a host on an interface
bound to the Trust zone, but could only reference the MIP using the Untrust zone, then your
policy will be from Untrust zone to Untrust zone. As a result, the traffic will never reach the
real host. As such, the MIP must be located in the Global zone address book, so when you
create a policy for Untrust to Trust, the MIP can still be referenced as the destination.
Obtaining MIP Information
In order to obtain the details regarding configured MIPs, issue the command:
get mip
Output:
Total MIPs under Root configured:1 Max:1000.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 35
Map IP Host IP NetMask Interface VRouter
192.168.1.10 1.1.1.1 255.255.255.255 ethernet1 trust-vr

Configuring a Policy using MIPs
To perform NAT-dst using MIPs, you must first create the MIP and then reference it in the
policy like so:
set interface interface mip NAT-ip-address host real-i p-address netmask netmask
vrouter vrouter
set policy from src-zone to dst-zone source mip(NAT-ip-address) service action
When you create the MIP, you also need to enter the vrouter in which the interface of the
real IP address is bound to. This is because the NetScreen performs a route lookup when it
encounters a MIP, and hence needs to know which virtual router it needs to use to determine
the correct destination zone. Also, note the manner in which the MIP is referenced in the
policy mip(NAT-ip-address). A MIP must be referenced in this way for the policy to be
created.
2.7.6. VIPs
Virtual IP (VIP) addresses are similar to MIPs in the sense that they are purely used for
inbound destination NAT. The difference is that VIPs use PAT to allow for a one-to-many
inbound NAT configuration. Depending on what the destination port is, the VIP allows you to
forward the traffic to a different host.
A VIP is comprised of two components. The VIP (the NAT IP address bound to the relevant
interface) and the VIP Service. The VIP Service specifies the destination port the VIP will
listen on and the real IP address that it will forward that traffic to.
The number of VIPs that can be created on a NetScreen is dependant on the model.
Typically, a single VIP can only have up to 8 VIP Services configured. Unlike MIPs, which
can be configured on any interface, VIPs can only be configured on interfaces bound to the
Untrust zone. On some NetScreen models, it is possible to create a VIP using the same IP
address as the interface bound to the Untrust zone (assuming you only have one interface
bound to the Untrust zone). However, when you use that IP address as a VIP, you cannot
create any other VIPs, regardless of the limit.
VIP entries are also stored in the Global zone address book for the same reasons MIP
entries are.
Obtaining VIP Information
In order to obtain details regarding configured VIPs, issue the command:
get vip
Output:
Virtual IP Interface Port Service Server/Port
10.10.10.10 ethernet3 80 HTTP 192.168.1.100/80(DOWN)

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 36

Configuring a Policy using VIPs
In order to create a policy using VIPs, you must first create the VIP and VIP service, and
then bind it in the policy like so:
set interface interface vip NAT-i p-address listen-port destination-service real-ip-
address
set policy from untrust to dst-zone source vip(NAT-i p-address) service action
When configuring the VIP service, you must enter the listen-port as a number, but the
destination-service must be an existing service defined in any of the service books. When
creating the policy, the service port must match that of the listen-port in order for the VIP to
direct the traffic to the appropriate host.
VIP Services can be added to an existing VIP using the following method:
set vip NAT-i p-address + listen-port destination-service real -ip-address
2.8. Packet Flows
Now that we understand the NetScreen three-tiered architecture and the configuration of
security policies, we can examine the journey of a packet through the firewall. Taken from
the ScreenOS Configuration and Examples Guide:
1. When a packet first arrives at the firewall, the interface module identifies the
incoming interface and, consequently, the source zone to which the interface is
bound. The source zone determination is based on the following criteria:
If the packet is not encapsulated, the source zone is the security zone to
which the incoming interface or subinterface is bound.
If the packet is encapsulated and the tunnel interface is bound to a VPN
tunnel, the source zone is the security zone in which the tunnel interface is
configured.
If the packet is encapsulated and the tunnel interface is in a tunnel zone, the
source zone is the corresponding carrier zone (a security zone that carries a
tunnel zone) for that tunnel zone.
2. If you have enabled SCREEN options for the source zone, the firewall activates the
SCREEN module at this point. SCREEN checking can produce one of the following
three results:
If a SCREEN mechanism detects anomalous behaviour for which it is
configured to block the packet, the firewall drops the packet and makes an
entry in the event log.
If a SCREEN mechanism detects anomalous behaviour for which it is
configured to record the event but not block the packet, the firewall records
the event in the SCREEN counters list for the ingress interface and
proceeds to the next step.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 37
If the SCREEN mechanisms detect no anomalous behaviour, the firewall
proceeds to the next step.
3. The session module performs a session lookup, attempting to match the packet with
an existing session.
If the packet does not match an existing session, the firewall performs First
Packet Processing, a procedure involving the following steps 4 through 9.
If the packet matches an existing session, the firewall performs Fast
Processing, using the information available from the existing session entry
to process the packet. Fast Processing bypasses steps 4 through 8 because
the information generated by those steps has already been obtained during
the processing of the first packet in the session.
!
Take note of these two terms First Packet Processing and Fast Processing.
They are referred to in the exam several times.

4. If a mapped IP (MIP) or virtual IP (VIP) address is used, the address-mapping
module resolves the MIP or VIP so that the routing table can search for the actual
host address.
5. The route table lookup finds the interface that leads to the destination address. In so
doing, the interface module identifies the destination zone to which that interface is
bound.
The destination zone determination is based on the following criteria:
If the destination zone is a security zone, that zone is used for the policy
lookup.
If the destination zone is a tunnel zone, the corresponding carrier zone is
used for the policy lookup.
If the destination zone is the same as the source zone and intrazone
blocking is disabled for that zone, the firewall bypasses steps 6 and 7 and
creates a session (step 8). If intrazone blocking is enabled, then the firewall
moves to the next step. If no policy is found, then the firewall drops the
packet.
6. The policy engine searches the policy set lists for a policy between the addresses in
the identified source and destination zones.
The action configured in the policy determines what the firewall does with the
packet:
If the action is permit, the firewall determines to forward the packet to its
destination.
If the action is deny, the firewall determines to drop the packet.
If the action is tunnel, the firewall determines to forward the packet to the
VPN module, which encapsulates the packet and transmits it using the
specified VPN tunnel settings.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 38
7. If destination address translation (NAT-dst) is specified in the policy, the NAT
module translates the original destination address in the IP packet header to a
different address.
If source address translation is specified (either interface-based NAT or policy-based
NAT-src), the NAT module translates the source address in the IP packet header
before forwarding it either to its destination or to the VPN module.
(If both NAT-dst and NAT-src are specified in the same policy, the firewall first
performs NAT-dst and then NAT-src.)
8. The session module creates a new entry in the session table containing the results
of steps 1 through 7.
The firewall then uses the information maintained in the session entry when
processing subsequent packets of the same session.
9. The firewall performs the operation specified in the session.
Some typical operations are source address translation, VPN tunnel selection and
encryption, decryption, and packet forwarding.
2.9. Review Questions

1. Which command can you use to determine how long a route has been active for?
a. get route
b. get route route-i d
c. get route active
d. get route id route-i d
2. When observing the traffic leaving your firewall, the source IP address of traffic has been
changed even though you have not configured a policy or any other configurations to
NAT the source IP address. What could be causing the NAT to take place? Select the
two BEST answers.
a. The ingress interface is in NAT mode
b. You have a DIP pool configured and bound to the relevant policy
c. A MIP or VIP is active for that host or network
d. You have not configured NAT-src for the relevant policy
e. The destination zone is the Untrust zone
3. On a NetScreen System, which component is responsible for Fast Processing?
a. CPU
b. RAM

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 39
c. Interface ASIC
d. Management ASIC
4. What is the maximum interface ID that can be assigned to a Subinterface?
a. 256
b. 4095
c. 1024
d. 4094
5. What does the following route entry perform: set route 0.0.0.0/0 gateway 1.1.1.1
a. Adds a default route to the Untrust-vr
b. Adds a default route to the Trust-vr
c. Adds a default route to the default virtual router
d. Nothing. The command is not valid.
6. On a NetScreen 5400, what intefaces can be used to create an aggregate interface?
Select the two best answers.
a. Ethernet1/1 and Ethernet1/2
b. Ethernet1/1 and Ethernet 2/1
c. Ethernet1/1 and Ethernet1/4
d. Ethernet 2/3 and Ethernet2/4
7. What is the easiest way to determine the ID of all zones?
a. Use the get config command
b. Use the get zone command
c. Use the get zone zone command
d. The zone ID only appears in the config
8. You issue the get route command and notice that an asterix (*) is missing next to one of
the route entries. What could be the possible cause?
a. The route has been incorrectly entered
b. NAT is taking place for that particular route
c. The physical interface for that route is disconnected
d. That route entry has the highest priority
9. Which VLAN standard does the NetScreen use for Subinterfaces?

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 40
a. 802.1D
b. 802.1Q
c. 802.1E
d. 802.3
10. If an NS500 has 1 Fast Ethernet module, 2 mini-GBIC module, and 1 GBIC modules,
what is the total number of useable interfaces (not including the management and HA
interfaces)?
a. 5
b. 7
c. 8
d. 6
11. Place the following in the correct order:
a. creates a new session
b. checks screen options for the zone
c. performs a policy lookup
d. resolves MIPs and VIPs
e. Performs a route lookup to determine the destination zone
12. What is the reason why you cant assign a VLAN ID to an interface?
a. The interface is in Route mode
b. The interface is in NAT mode
c. The interface is in Transparent mode
d. The interface type is Tunnel
13. What is the correct command to make the Untrust-vr your default virtual router?
a. set default-vr untrust-vr
b. set vrouter untrust-vr default vr
c. set vrouter untrust-vr default-vrouter
d. set untrust-vr default
14. What command would you use to determine the route used to reach the host
200.200.200.1/32?
a. get route 200.200.200.1

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 41
b. get route ip 200.200.200.1
c. get route network 200.200.200.1
d. get vrouter untrust-vr route 200.200.200.1
15. You cannot add an IP address to one of your interfaces. What is most likely the problem?
a. The interface is in NAT mode
b. The interface is in Route mode
c. The interface is bound to the Null zone
d. The interface is disconnected
2.9.1. Review Answers

1. Which command can you use to determine how long a route has been active for?
d. In order to obtain the uptime for a specific route, it is necessary to have the routes ID
and to issue the command get route id route-id. The get route command only displays
the routing table with all the routing IDs. The other commands are erroneous.
2. When observing the traffic leaving your firewall, the source IP address of traffic has been
changed even though you have not configured a policy or any other configurations to
NAT the source IP address. What could be causing the NAT to take place? Select the
two BEST answers.
a & e. If no policy NAT, MIPs or VIPs have been configured and source IP NAT is
occuring, it is safe to say that the ingress interface has been set to NAT mode and traffic
is destined to the Untrust zone.
3. On a NetScreen System, which component is responsible for Fast Processing?
c. As a NetScreen Systems modules include their own ASIC, they are used in a Fast
Processing instance (traffic that matches an existing session) in order to increase speed.
First Packet Processing is performed by the CPU.
4. What is the maximum interface ID that can be assigned to a Subinterface?
b. The other figures are erroneous.
5. What does the following route entry perform: set route 0.0.0.0/0 gateway 1.1.1.1
c. The command is valid, and as the virtual router has not been specified, the route is
added to the default virtual router.
6. On a NetScreen 5400, what intefaces can be used to create an aggregate interface?
Select the two best answers.
a & d. When creating aggregate interfaces, the physical interfaces must be grouped
sequentially. It is not possible to create aggregate interfaces between different modules.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 42
7. What is the easiest way to determine the ID of all zones?
b. Although all the options are correct (apart from option a), issuing the get zone
command is the easiest way to display the zone ID for all zones.
8. You issue the get route command and notice that an asterix (*) is missing next to one of
the route entries. What could be the possible cause?
c. If an asterix next to a route entry is missing, it means the route entry is currently
inactive. The most common reason is that the interface has been disconnected.
9. Which VLAN standard does the NetScreen use for Subinterfaces?
b. 802.1Q is the IEEE standard for VLANs. The other options are erroneous.
10. If an NS500 has 1 Fast Ethernet module, 2 mini-GBIC module, and 1 GBIC modules,
what is the total number of useable interfaces (not including the management and HA
interfaces)?
b. A Fast Ethernet module has 2 interfaces, a mini-GBIC module has 2 interfaces, and a
GBIC module has 1 interface, hence 2 + 1 + (2 x 2) = 7.
11. Place the following in the correct order:
b, d, e, c, a. Screen occurs before a VIP/MIP resolution, when then requires a route
lookup, a policy lookup and a new session to be created.
12. What is the reason why you cant assign a VLAN ID to an interface?
a. Tunnel interfaces do not support VLANs.
13. What is the correct command to make the Untrust-vr your default virtual router?
c. All other options are not valid commands.
14. What command would you use to determine the route used to reach the host
200.200.200.1/32?
b. All other options are not valid commands.
15. You cannot add an IP address to one of your interfaces. What is most likely the problem?
c. The interface must belong to a valid Security or Function zone before an IP address
can be assigned to it.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 43
3. VPNs
A Virtual Private Network (VPN) allows two disparate sites to communicate securely over an
insecure medium (namely the Internet).
NetScreen firewalls support the standard IPSec protocol for site-to-site and client-to-site
VPNs. As a JNCIS-FWV, Juniper expects you to understand VPN technology, the
associated protocols, the types of VPN configurations supported by a NetScreen firewall,
additional ways to secure the VPN connection (such as the use of digital certificates) and
how to troubleshoot VPN issues.
There are two types of tunnel negotiation methods, Manual Key and AutoKey. In a Manual
Key IPSec VPN, all Security Association (SA) parameters are predefined, and as a result,
authentication and security properties of the tunnel are already set. Hence, it is possible for
one device to simply encrypt the traffic and forward it to the other device. As a device is
required to establish more and more tunnels with other devices, the Manual Key method
becomes vary laborious and is inherently less secure (as the parties on both end of the VPN
tunnel need to agree on and share all the SA parameters).
!
A Security Association is a unidirectional agreement between both VPN end
points regarding the methods and parameters to use in order to secure the
communication channel.

An AutoKey IKE IPSec VPN automates a good portion of the negotiation process. This type
of VPN can be divided into two distinct phases. Phase 1 (IKE phase) is responsible for
negotiating how a VPN tunnel should be authenticated and secured. Phase 2 (IPSec phase)
is responsible for determining how traffic should be secured when traversing through the
tunnel.
3.1. PKI
A Public Key Infrastructure (PKI) is the construct that enables digital certificates to be
hierarchically trusted, securely issued and appropriately revoked. The fundamental
components of a PKI include the Certificate Authority (CA), the Registration Authority (RA)
and the Certificate Revocation List (CRL).
3.1.1. Digital Certificates
Digital certificates are a form of electronic identity which have been validated by an external
trusted third party (a Certificate Authority). Users and devices can exchange digital
certificates in order to prove their identity, allowing a circle of trust to form. This is on the
proviso that all the users and devices trust the validation of the Certificate Authority.
As a digital certificate contains the public encryption key for a particular user or device, the
other party receiving the digital certificate (having trusted the digital certificate), can use the
public key for the purpose of encrypting data and traffic back to the owner of the digital
certificate.
3.1.2. Certificate Authorities
A Certificate Authority (CA) is the trusted third party which validates digital certificates. It
does this by signing the digital certificate with its own private key. CAs function in a

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 44
hierarchical structure, allowing for a hierarchy of trust to exist. Typically, a CA can have
another CA above it and so forth. The CA at the top of the tree is known as the Root CA.
Providing that you trust the Root CA, you can safely trust any digital certificate signed by that
Root CA or any CA below it.
A Registration Authority (RA) typically handles digital certificate signing requests on behalf of
the CA.
3.1.3. Certificate Revocation
When a digital certificate becomes compromised, there needs to be an efficient method to
revoke them so they can no longer be used. A Certificate Revocation List (CRL) can be
referenced when validating a digital certificate to ensure that the certificate has not been
revoked.
The validating of digital certificates against a CRL is normally a manual processes whereby
the CRL is downloaded on a period basis (daily, weekly, monthly). In the instance that the
validator does not have the latest CRL, a presented certificate may still be trusted even
though it may have been revoked and added to a more recent CRL. To address this issue,
the OCSP (Online Certificate Status Protocol) was developed to provide online and real-time
verification of a digital certificates status.
!
When a NetScreen uses OCSP, it is referred to as the OCSP client (or
requester). The server which receives the verification request is known as the
OCSP responder.
3.1.4. Configuring Digital Certificates on a NetScreen
Manual Certificate Generation
Before the NetScreen can obtain a signed certificate, you must generate a certificate request
from it and forward it to an appropriate CA to be signed. Issue the following commands to
generate the certificate request and have it forwarded to the CAs email address:
set pki x509 dn count ry-name country *
set pki x509 dn email your-email -address *
set pki x509 dn ip NetScreen-ip-address
set pki x509 dn local-name location
set pki x509 dn name hostname *
set pki x509 dn org-name company-name
set pki x509 dn org-unit-name department
set pki x509 phone phone-number
set pki x509 dn state-name state
set pki x509 default send-to ca-email -address *
exec pki rsa new-key 1024 *

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 45
Any line with an * is mandatory, where the other lines are optional.
Loading the Digital Certificate
Once you receive your digital certificate (typically through email), it needs to be saved to a
tftp server where it can uploaded to the NetScreen. The NetScreen requires 3 items for the
Digital Certificate to function properly: the digital certificate assigned to the NetScreen
(typically called local.cer), the signing Certificate Authoritys digital certificate (typically called
auth.cer) and the CRL (usually *.crl). Load the three items to the NetScreen with the
following commands:
exec pki x509 tftp tftp-ip-address cert-name auth.cer
exec pki x509 tftp tftp-ip-address cert-name local.cer
exec pki x509 tftp tftp-ip-address crl-name filename.crl
Configuring CRL Settings
During the Phase 1 negotiation, it is important for a NetScreen to check the status of
certificates received against a CRL to ensure their validity. If a CRL was not loaded into the
NetScreens database, the firewall attempts to retrieve the CRL defined on the CA certificate
through LDAP or HTTP. If a CRL is not defined on the CA certificate, it attempts to use the
URL you define for the CRL.
set pki authority default cert-path full
set pki authority default cert-status crl url URL
set pki authority default cert-status crl server-name CA-server-IP-address
set pki authority default cert-status crl refresh daily|weekly|monthly
Configuring OCSP
It is possible to configure the NetScreen to use OCSP for certificate validation as opposed to
using a CRL. To configure the NetScreen for OCSP, issue the following commands:
Configure the NetScreen to use OCSP for the relevant CA:
set pki authority CA-ID cert -status revocation-check OCSP
Configure the OCSP Responder:
set pki authority CA-ID cert -status ocsp url URL
The CA-ID refers to the identification number assigned to the configured CA by the
NetScreen firewall. To view the list of configured CAs and their IDs, issue the command:
get pki x509 list ca-cert
3.2. IKE
Even though the Internet Key Exchange (IKE) protocol is synonymous with IPSec VPNs, it is
in itself a separate protocol. IKE is used to automatically generate and negotiate keys and
Security Associations. A preshared key or a digital certificate (more secure) can be used as

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 46
the method to secure communication between two end points of a VPN tunnel. IKE uses the
preshared key or public key bound to the certificate to automatically change keys at
predetermined intervals.
In order to facilitate this secure key exchange, IKE uses the Diffie-Hellman (DH) key
exchange algorithm. There are 5 different groups. NetScreen supports the following 3:
DH Group 1: 768-bit Modulus
DH Group 2: 1024-bit Modulus
DH Group 5: 1536-bit Modulus
The larger the modulus, the more secure the generated key is considered to be.
3.2.1. Modes
IKE supports two modes of negotiation, Main mode and Aggressive mode. Main mode is the
standard method used for site-to-site VPNs with static peers. Aggressive mode is typically
used for VPN clients and sites with dynamic IP addresses.
In Main mode, the VPN tunnel initiator and the recipient send three two-way exchanges (a
total of 6 messages).
First exchange (messages 1 and 2): Propose and accept the encryption and
authentication algorithms
Second exchange (messages 3 and 4): Execute a DH exchange where the initiator
and recipient each provide a nonce (a randomly generated number)
Third exchange (messages 5 and 6): Send and verify identities
By exchanging identity information after the second exchange where an encryption method
has been established, the identity information remains secure.
In Aggressive mode, a secure tunnel is still established but requires only 2 exchanges with a
total of 3 messages.
First message: The VPN tunnel initiator proposes the SA, initiates a Diffie-Hellman
key exchange, sends a nonce and its IKE identity
Second message: The recipient accepts the SA, authenticates the initiator, sends a
nonce, its IKE identity and its digital certificate (if digital certificates are in use)
Third message: The initiator authenticates the recipient, confirms the exchange and
sends its digital certificate (if digital certificates are in use)
Because the identities of both parties are sent in the clear, Aggressive mode does not
provide identity protection.
!
It is imperative that you remember the different modes of IKE negotiation, the
number of exchanges and messages, and what takes place during each of
the message exchanges.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 47
3.2.2. Proposals
The Phase 1 proposal sets the terms of the IKE tunnel negotiation. Both end points need to
agree on the same proposal. To facilitate this, it is possible to define up to 4 Phase 1
proposal types.
The structure of a Phase 1 proposal is as follows:
Method: indicates whether preshared key (pre) or digital certificates (using RSA-
Sig or DSA-Sig) are used as the authentication method
DH Group: Indicates the Diffie-Hellman group used for the key generation or
exchange (g1, g2 or g5)
Encrypt/Auth: Indicates the encryption algorithm (3DES, DES or AES) and the
hash algorithm (MD5 or SHA-1) used
Examples of Phase 1 proposals include:
pre-g1-des-md5
dsa-g2-3des-sha1
rsa-g5-aes128-md5
or the current de-facto standard: pre-g2-3des-sha1
!
While it is not necessary to remember all the values that can be applied, it is
important to remember how a Phase 1 proposal is constructed so it is
possible to identify between a Phase 1 proposal and a Phase 2 proposal.

Another important aspect of the proposal is the key lifetime. This indicates the life of the key
(how often the key should be changed) and can be configured in terms of seconds, minutes
hours or days. Although a Phase 1 tunnel may still be established when both ends use
different key lifetimes, when one end decides to change its key, the tunnel may no longer be
valid.
3.3. IPSec
Once IKE has been used to establish a tunnel to provide a secure channel of
communication, IPSec is used to provide a means of securing the actual data that will
traverse the tunnel.
3.3.1. Protocols
Two protocols exist to secure the packets destined for a VPN tunnel. The Authentication
Header (AH) protocol provides authenticity and integrity of the content and origin of a packet.
This is achieved through either the MD5 or SHA-1 hash algorithms. When applying AH, the
packet payload is left in its original form, and an AH header is appended to the packet
header.
The Encapsulation Security Payload (ESP) protocol provides security of data by encrypting
the packets payload. ESP supports the DES, 3DES and AES protocols for encryption. Like

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 48
AH, an ESP header is appended to the packet. The benefits of ESP is that it includes both
encryption capabilities and the authentication capabilities of AH.
3.3.2. Encapsulation
IPSec allows for data to be encapsulated in two ways after AH or ESP has been applied.
Transport mode retains the original header, the newly appended header (either AH or ESP)
and the payload. Tunnel mode encapsulates the whole packet (including the original header)
into a new packet and appends a new header to the packet.
3.3.3. Perfect Forward Secrecy
As we observed in the IKE phase, Diffie-Hellman is used to generate and negotiate keys.
When no Perfect Forward Secrecy (PFS) is enabled, Phase 2 can use this same key for the
purposes of its encryption. The enabling of PFS requires another separate key to be
generated using DH purely for Phase 2 usage. This increases security as a compromise in
Phase 1 keys does not equate to a compromise in Phase 2 keys.
3.3.4. Proposals
Much like Phase 1 proposals, Phase 2 proposals follow a certain structure.
PFS: Indicates whether PFS is not being used (nopfs) or if it is, which DH group is
being applied (g1, g2 or g5).
Encapsulation: Whether the ESP (esp) protocol is being used for encryption and
authentication, or just the AH (ah) protocol.
Encryption/Authentication: Indicates the encryption algorithm (DES, 3DES or
AES) and/or the hash algorithm (MD5 or SHA1) to be used.
Examples of a Phase 2 proposal include:
nopfs-esp-des-md5
g1-ah-null -sha1
And the defacto standard: g2-esp-3des-sha1
3.3.5. Proxy-IDs
One of the most important yet overlooked aspects of a successful VPN setup is the proxy-ID.
The proxy-ID determines which networks and services are permitted through the VPN. A
proxy-ID is made up of the local network, remote network and service. Both end points of the
VPN exchange their proxy-ID which needs to match for the Phase 2 negotiation to be
complete.
A proxy-ID can be extracted from a security policy if a Policy-based VPN is being used as
the necessary proxy-ID information resides in the policy (source, destination and service).
When a Route-based VPN is configured, a policy may not be necessary, and if so, may not
necessarily contain the correct information in which to create the proxy-ID. As a result, the
proxy-ID must always be manually entered when configuring Route-based VPNs.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 49
!
Manually specifying a proxy-ID in a Policy-based VPN scenario will overwrite
the proxy-ID automatically obtain from the security policy.
3.4. Policy-Based VPNs
NetScreen firewalls support two types of IPSec VPN configuration, Policy-based and Route-
based. Policy-based VPNs are established by traffic matching a particular security policy
with the action of tunnel. In this instance, the tunnel is treated as an object with which is
specifically named in order to form the security policy.
!
The action of tunnel implies permit. Hence, it is not possible to create
granular security policies which allows certain traffic and denies other traffic
through a Policy-based VPN tunnel.

Policy-based VPNs are far more simplistic to configure and work extremely well for basic
site-to-site or client-t o-site VPN connectivity. No additional components apart from the
definition of the Autokey or Manual IPSec tunnel is required.
Configuring a Site-to-Site Policy-based VPN
In order to configure a Policy-based VPN, complete the following steps:
Create the gateway using Preshared Keys:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface
preshare preshared-key proposal p1-proposal
set vpn vpn-name gateway gw-name sec-level p2-proposal
Or alternatively, with Digital Certificates:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface
proposal p1-proposal
set ike gateway gw-name cert peer-ca CA
set ike gateway gw-name cert peer-cert -type ca-type
set vpn vpn-name gateway gw-name sec-level p2-proposal
Create the bi -directional policies which refer to the tunnel:
set policy top name policy-name from src-zone to dst-zone source-net remote-net
any tunnel vpn vpn-name
set policy top name policy-name from src-zone to dst-zone remote-net source-net
any tunnel vpn vpn-name
3.5. Route-Based VPNs
A Route-based VPN provides more flexibility when more complicated routing or more
stringent access control is required. This is because a Route-based VPN does not use
policies which specifically reference a VPN tunnel. A tunnel interface is required with

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 50
bindings to the VPN tunnel. When traffic attempts to route to a destination address specified
as going through the tunnel interface, traffic is rerouted there and the VPN is established.
In Policy-based VPNs, it is possible to reference a single tunnel in multiple policies, but in
doing so, additional SA pairs are generated for each security policy. As Route-based VPNs
are initiated by a destination address and enabled through a tunnel interface, a single SA
pair will exist regardless of the number of policies created.
Route-based VPNs also support the exchange of dynamic routing information through the
VPN tunnels.
!
As each VPN type is initiated differently, the number of Policy-based VPNs is
limited by the number of security policies supported by the firewall and the
number of Route-based VPNs is limited by the number of routes or tunnel
interfaces supported by the firewall.

Configuring a Route-based Site-to-Site VPN
The configuration for a Route-based VPN requires additional steps:
Firstly, create and define the tunnel interface:
set interface tunnel-int -name zone zone
set interface tunnel-int -name ip unnumbered interface phy-interface
!
For the purpose of a standard Site-to-Site Route-based VPN, the tunnel
interface can be configured as unnumbered which means that it will take on
the IP address of the physical interface it is bound to. However, in more
advanced Route-based VPN configurations, it is possible to assign the tunnel
interface an IP address for the purposes of NATing. We will see this in a later
section.

The creation of the VPN is quite similar to that of a Policy-based VPN but with one
difference. The tunnel interface must be bound to the VPN tunnel and a proxy-ID
must be manually configured:
For a Preshared Key configuration:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface
preshare preshared-key proposal p1-proposal
set vpn vpn-name gateway gw-name sec-level p2-proposal
set vpn vpn-name bind interface tunnel-int -name
set vpn vpn-name proxy-id local -ip local -proxy-id/mask remote-ip remote-proxy-
id/mask service
Or, for a Digital Certification configuration:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface
proposal p1-proposal

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 51
set ike gateway gw-name cert peer-ca CA
set ike gateway gw-name cert peer-cert -type ca-type
set vpn vpn-name gateway gw-name sec-level p2-proposal
set vpn vpn-name bind interface tunnel-int -name
set vpn vpn-name proxy-id local -ip local -proxy-id/mask remote-ip remote-proxy-
id/mask service
Just as the name implies, a Route-based VPN is instigated through the routing of
traffic to a particular destination, and as such, a static route needs to be added:
set vrouter vrouter route remote-net interface tunnel-int-name
Optionally, a security policy can be used to control traffic outbound to and inbound
from the tunnel:
set policy top name policy-name from src-zone to dst-zone source-net remote-net
any permit
set policy top name policy-name from src-zone to dst-zone remote-net source-net
any permit
!
If the tunnel interface is bound to the same zone as the destination zone and
Intrazone Blocking is disabled, then a security policy is not required to permit
the traffic as it is assumed that all traffic is permitted by default. Binding the
tunnel interface to a different zone requires the use of a security policy to
explicitly permit traffic.
3.6. IPSec Packet Flow
Now that we have an understanding of Policy and Route based VPNs and their
configuration, we can analyse the packet flow sequence from the initiator to the recipient in
more detail.
We will examine a Route-based VPN packet flow, and then highlight the differences in
regards to a Policy-based VPN.
From the initiator:
1. A host attempts to send a packet destined for an IP address on the recipient
network via its default gateway.
2. The packet arrives at the egress interface, which is bound to a particular zone (let
us assume the Trust zone).
3. If SCREEN options have been enabled for the zone, the NetScreen firewall
activates the SCREEN module at this point.
4. The session module then performs a session lookup, attempting to match the
packet with an existing session.
5. The address-mapping module checks if a Mapped IP (MIP) configuration uses the
destination IP address.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 52
6. The route module performs a route lookup for the destination IP address and
determines that the traffic needs to be routed through a tunnel interface. The tunnel
interface is in turn bound to a VPN tunnel. By determining the ingress and egress
interfaces, the firewall has thereby determined the source and destination zones and
can now do a policy lookup.
7. The policy engine performs a policy lookup between the two zones. Based on the
derived policy, the policy engine performs the defined action (let us assume that it is
a permit).
8. The IPSec module checks if an active Phase 2 security association (SA) exists
with the remote gateway. If so, the process skips to step 10. If not, the next step is
initiated.
9. The IKE module checks if an active Phase 1 SA exists with the remote peer. If so,
the IPSec module attempts to establish a Phase 2 negotiation. The process
continues to the next step on successful completion of Phase 2 negotiation. If Phase
1 negotiations fail, traffic will fail at this point.
10. The IPSec module encapsulates the packet using the appropriate protocols (in
this example, lets assume that its tunnel mode using ESP). The packet is
appended with a new header which includes the outgoing interfaces IP address as
its source IP address and the remote gateways IP address as the destination. The
packets payload is then encrypted to the next header field in the original IP header
and authenticated from the ESP trailer to the ESP header.
11. The NetScreen firewall then sends the encrypted and authenticated packet
destined for the remote gateway through the outgoing interface to the next-hop-
gateway.
From the recipient:
1. The packet arrives at the external interface which is bound to a particular zone
(lets presume its the Untrust zone).
2. Using the SPI, destination IP address, and IPSec protocol contained in the outer
packet header, the IPSec module attempts to locate an active Phase 2 SA with the
initiating peer along with the keys to authenticate and decrypt the packet. If
successful, the firewall moves onto step 4. If an active Phase 2 SA cannot be found,
the NetScreen moves onto the next step.
!
An SPI (Security Parameter Index) is a hexadecimal value used to uniquely
identify each VPN tunnel.

3. The IKE module checks if an active Phase 1 SA exists with the remote peer. If a
Phase 1 SA does not exist, the NetScreen attempts to establish a Phase 1 tunnel
with the remote gateway.
4. The IPSec module performs an anti-replay check.
5. The IPSec module attempts to authenticate the packet.
6. Using the Phase 2 SA and keys, the IPSec module decrypts the packet,
uncovering its original source address (the original host that send the packet) and its
ultimate destination (the original destination of the packet ). The firewall determines

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 53
which VPN the packet came through, and as a result, which tunnel interface the
VPN was bound to. From this point forward, the firewall treats the packet as if its
ingress interface is the tunnel interface. It also adjusts the anti-replay sliding window
at this point.
7. If SCREEN options have been enabled for the zone, the firewall activates the
SCREEN module at this point.
8. The session module performs a session lookup, attempting to match the packet
with an existing session. It then either performs First Packet Processing or Fast
Processing.
9. The address-mapping module checks if a mapped IP (MIP) or virtual IP (VIP)
configuration uses the original destination IP address.
10. The route module first uses the ingress interface to determine the virtual router
to use for the route lookup. It then performs a route lookup for the destination and
determines which interface it needs to send the packets out from. By determining
the ingress interface and the egress interface, the NetScreen can thereby determine
the source and destination zones. It is now possible to perform a policy lookup on
the respective zones.
11. The policy engine checks its policy list from the source zone to the destination
zone and finds a policy that grants access (or possibly denies access).
12. The firewall then forwards the packet through the interface to the destination
host.
The packet flow for a Policy-based VPN are largely the same apart from the following points:
From the initiator:
Route Lookup: To determine the destination zone, the route module does a route
lookup for the destination IP address. As there is more than likely not a route for that
particular IP address, the NetScreen uses the default gateway and the zone
associated with the ultimate outgoing interface (let us assume its the Untrust zone).
By determining the ingress and egress interfaces, the firewall has thereby
determined the source and destination zones, and can now perform a policy lookup.
Policy Lookup: The policy engine does a policy lookup between the two zones. The
lookup matches the source address and zone, destination address and zone, and
service and finds a policy that references a VPN tunnel.
The NetScreen device then forwards the packet through to the destination using the
VPN tunnel configured in the policy.
From the recipient:
Most stages of the inbound packet flow on the recipients end are the same for both
route-based and policy-based VPN configurations except that the tunnel is not
bound to a tunnel interface, but to a tunnel zone. The NetScreen device learns that
the packet came through vpn1, which is bound to the Untrust-Tun tunnel zone,
whose carrier zone is the Untrust zone. Unlike route-based VPNs, the firewall
considers ethernet3 to be the ingress interface of the decrypted packet - not
tunnel.1.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 54
Route Lookup: The route module performs a route lookup for destination IP address
and discovers the relevant interface and zone for the delivery of the packet. By
learning the source zone and determining the destination zone based on the egress
interface, the firewall can now check for a policy from the respective zones that
references the VPN tunnel.
!
Unlike that of a Route-based VPN, a Policy-based VPN isnt reliant on a
tunnel interface. Instead, all VPNs are generally bound to a tunnel zone
(namely the Untrust-tunnel -zone). The tunnel zone relies on the carrier zone
(in this instance, the Untrust zone) to determine which zones it should use for
policy lookup. The physical interface the packet arrives on is used as the
ingress interface as opposed to the tunnel interface in a Route-based VPN
situation.

Policy Lookup: The policy engine checks its policy list from the source zone to the
destination zone and finds a policy that references the VPN tunnel.
The NetScreen then forwards the packet to its destination.
3.7. Dynamic Peers
Situations arise when a remote site does not have a static IP address (typical for home or
small office sites). As a result, it is not possible to define the remote gateways IP address for
the purpose of VPN tunnel establishment. NetScreen firewalls provide a solution for this
through the use of local and peer IDs.
By configuring a local ID on the initiating device with the dynamic IP address, the device
presents this information to the recipient device when attempting to establish Phase 1
negotiation. The recipient device is configured to recognise this through a peer ID, and as a
result, can accept the initiators current IP address.
!
The Phase 1 mode of VPNs with Dynamic Peers must be set to aggressive.

Configuring a Site-to-Site VPN with a Dynamic Peer
The configuration is largely the same with the following exceptions when the gateway is
being defined:
On the initiating device:
For Preshared Key configuration:
set ike gateway gw-name address remote-gw aggressive local-id local-i d outgoing-
interface phy-interface preshare preshared-key proposal p1-proposal
Or when using Digital Certificates:
set ike gateway gw-name address remote-gw aggressive local-id local-i d outgoing-
interface phy-interface proposal p1-proposal
On the recipient device:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 55
For Preshared Key configuration:
set ike gateway gw-name dynamic peer-id aggressive outgoing-interface phy-
interface preshare preshared-key proposal p1-proposal
Or when using Digital Certificates:
set ike gateway gw-name dynamic peer-id aggressive outgoing-interface phy-
interface proposal p1-proposal
Where the peer-id defined on the recipient device is the local -id defined on the
initiator device.
3.8. Hub and Spoke VPNs
NetScreen firewalls provide enhanced VPN functionality in order to allow inbound traffic from
one tunnel to be routed out through another VPN tunnel. This type of configuration is known
as a Hub and Spoke (many remote sites with a VPN into the central site, allowing all remote
sites to route between each other).
!
Hub and Spoke VPNs are generally easiest to configure using Route-based
VPNs. While it is possible to achieve the same type of advanced VPN
functionality through Policy-based VPNs, it is only possible through the Trust
and Untrust zones.

As with any interface and zone assignment, tunnel interfaces assigned to the same security
zone do not require policies for traffic to route between them (providing Intrazone blocking
has been disabled). However, if granular access control is required (for example, site A
being able to route through to site B, but not the other way around) then tunnel interfaces
can be assigned to different zones in order to control the traffic through security policies.
This type of Hub and Spoke VPN is known as a Back-to-Back VPN.
!
It is often required to calculate the total number of VPN tunnels that will be
required in a fully meshed VPN for a given number of sites. The easiest way
to calculate this is with the formula: [N x (N-1)]/2 where N is the number of
sites.

Configuring a Hub and Spoke VPN
In order to explain the configuration, we will use an example of a Head Office which is acting
as the hub and two remote sites, Site A and Site B acting as the spokes.
For Head Office:
Security Zones and Virtual Routers:
unset interface interface ip
unset interface interface zone
set zone untrust vrouter untrust-vr

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 56
unset zone untrust block
Where interface is the interface bound to the Untrust zone.
Interfaces:
set interface interface zone untrust
set interface interface ip HO-external -IP/mask(octet)
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface interface
set interface tunnel.2 zone untrust
set interface tunnel.2 ip unnumbered interface interface
Where interface is the interface bound to the Untrust zone.
VPN for Site A:
set ike gateway SiteA address siteA-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteA-VPN gateway SiteA sec-level compatible
set vpn SiteA-VPN bind interface tunnel.1
set vpn SiteA-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
It is possible to use other Phase 1 & 2 proposals apart from compatible.
VPN for Site B:
set ike gateway SiteB address siteB-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteB-VPN gateway SiteB sec-level compatible
set vpn SiteB-VPN bind interface tunnel.2
set vpn SiteB-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
Routes:
set vrouter untrust-vr route siteA-net/mask(octet) interface tunnel.1
set vrouter untrust-vr route siteB-net/mask(octet) interface tunnel.2
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
For Site A:
Security Zones and Virtual Routers:
unset interface interface ip

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 57
unset interface interface zone
set zone untrust vrouter untrust-vr
Where interface is the interface bound to the Untrust zone.
Interfaces:
set interface interface-trust zone trust
set interface interface-trust ip trust-ip/mask(octet)
set interface interface-trust nat
set interface interface zone untrust
set interface interface ip siteA-external-IP/mask(octet)
set interface tunnel.1 zone untrust
set interface tunnel.1 ip unnumbered interface interface
Address:
set address untrust SiteB siteB-net/mask(octet)
VPN:
set ike gateway HeadOffice address HO-external -IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn HO-VPN gateway HeadOffice sec-level compatible
set vpn HO-VPN bind interface tunnel.1
set vpn HO-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
Routes:
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
set vrouter untrust-vr route SiteB-net/mask(octet) interface tunnel.1
Policies:
set policy from trust to untrust any SiteB any permit
set policy from untrust to trust SiteB any any permit
!
Even though a policy is not required on the Head Office to permit the traffic a
policy is still required at both sites to permit the traffic to and from each other.

Configuration for Site B mirrors that of Site A (with configuration details relevant to Site B).

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 58
3.8.1. Back-to-Back VPNs
When it is necessary to control the traffic at the hub between two spokes, a Back-to-Back
VPN configuration can be used. A Back-to-Back VPN requires the tunnel interfaces to reside
in different zones (or, for Intrazone Blocking to be enabled). While it is not essential that
tunnel interfaces be assigned with an IP address, it is recommended as NAT and other
features may sometimes be required for policy configuration between spokes. Another
typical application is enforcing all Internet access from spoke sites to flow through and be
enforced by the hub site.
Configuring Back-to-Back VPNs
The confi guration for a Back-to-Back VPN is largely the same as for a standard Hub and
Spoke. We will use the same example as previously, showing the configuration changes
required at the Head Office.
For Head Office:
Security Zones and Virtual Routers:
unset interface interface ip
unset interface interface zone
set zone untrust vrouter untrust-vr
set zone untrust block
set zone name x1
set zone x1 vrouter trust-vr
set zone x1 block
set zone name x2
set zone x2 vrouter trust-vr
set zone x2 block
Where interface is the interface bound to the Untrust zone
Interfaces:
set interface interface zone untrust
set interface interface ip HO-external -IP/mask(octet)
set interface tunnel.1 zone x1
set interface tunnel.1 ip tunnel1-ip/mask(octet)
set interface tunnel.2 zone x2
set interface tunnel.2 ip tunnel2-ip/mask(octet)

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 59
In this instance, the tunnel1-ip should be an IP address that resides on the local
area network of Site A and the tunnel2-i p should be an IP address that resides on
the local area network of Site B.
VPN for Site A:
set ike gateway SiteA address siteA-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteA-VPN gateway SiteA sec-level compatible
set vpn SiteA-VPN bind interface tunnel.1
set vpn SiteA-VPN proxy-id local-i p siteB-net/mask(octet) remote-ip siteA-
net/mask(octet) any
It is possible to use other Phase 1 & 2 proposals apart from compatible. To provide
granular restriction of what can be routed between the spokes, the proxy-ID is
enforced to be the local area networks of both spokes. To simplify the configuration,
It would be possible to configure a 0.0.0.0/0 proxy-ID.
VPN for Site B:
set ike gateway SiteB address siteB-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteB-VPN gateway SiteB sec-level compatible
set vpn SiteB-VPN bind interface tunnel.2
set vpn SiteB-VPN proxy-id local-ip siteA-net/mask(octet) remote-ip siteB-
net/mask(octet) any
Routes:
set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
A static route addition to the spoke sites is not required as each tunnel interface
resides on the same network, and as such, the routing table knows of the route
because of this direct connection.
Addresses:
set address x1 SiteA LAN siteA-net/mask(octet)
set address x2 SiteB LAN siteB-net/mask(octet)
Policies:
set policy top from x1 to x2 SiteA LAN SiteB LAN any permit
set policy top from x2 to x1 SiteB LAN SiteA LAN any permit

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 60
3.8.2. VPNs using the NHTB
If for some reason, a certain configuration makes it difficult for a single tunnel interface to be
allocated for each VPN tunnel, it is possible to assign multiple VPN tunnels to a single tunnel
interface. In order to achieve this, the NetScreen firewall relies on the standard routing table
and an additional routing table known as the Next-Hop Tunnel Binding (NHTB) table. The
NetScreen firewall maps the next-hop gateway IP address specified in the routing table to a
particular VPN tunnel specified in the NHTB table.
The following tables describe how the routing and NHTB table relate to each other:

As the routing table uses the remote peers tunnel IP address as the next-hope gateway IP
address, the route must be manually entered or learned through BGP. In the NHTB table,
the same gateway IP address must also be entered along with the VPN tunnel name. This
can also be entered manually, or learnt automatically during Phase 2 negotiations.
Creating Entries in the NHTB Table
Once you have learnt the IP address of the remote peers tunnel interface, you can issue the
following command to manually create an entry into the NHTB table:
set interface tunnel-interface nhtb peer-tunnel -interface-i p vpn vpn-name
!
Although it is possible to add entries into the NHTB table, it actually isnt
possible to view it.

If you prefer to make the population of both the NHTB and route tables automatic, the
following conditions must be met:
The remote peers for all VPN tunnels bound to a single local tunnel interface must
be NetScreen devices running ScreenOS 5.0.x or above.
Each remote peer must bind its tunnel to a tunnel interface, and that interface must
have an IP address unique among all peer tunnel interface addresses.
At both ends of each VPN tunnel, VPN monitoring with the rekey option must be
enabled, or, the IKE heartbeat reconnect option for each remote gateway must be
enabled.
The local and remote peers must have an instance of Border Gateway Protocol
(BGP) enabled on their connecting tunnel interfaces.
Configuring Multiple VPNs Through a Single Tunnel Interface using static NHTB
In this example, we will bind 3 AutoKey IKE VPNs to a single tunnel interface at Head Office,
showing the configurations for Head Office and one of the spoke sites.
For Head Office:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 61
Security Zones and Virtual Routers:
unset interface untrust-interface ip
unset interface untrust-interface zone
set zone untrust vrouter untrust-vr
Interfaces:
set interface trust-interface zone trust
set interface trust-interface ip ipaddress/mask(octet)
set interface untrust-interface zone untrust
set interface untrust-interface ip HO-external-IP/mask(octet)
set interface tunnel.1 zone untrust
set interface tunnel.1 ip HO-tunnel -IP/mask(octet)
Addresses:
set address trust HO-Net ipaddress/mask(octet)
set address untrust SiteA-Net ipaddress/mask(octet)
set address untrust SiteB-Net ipaddress/mask(octet)
set address untrust SiteC-Net ipaddress/mask(octet)
set group address untrust RemoteSites + SiteA-Net
set group address untrust RemoteSites + SiteB-Net
set group address untrust RemoteSites + SiteC-Net
VPNs:
set ike gateway SiteA address siteA-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteA-VPN gateway SiteA sec-level compatible
set vpn SiteA-VPN bind interface tunnel.1
set vpn SiteA-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
set ike gateway SiteB address siteB-external-IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteB-VPN gateway SiteA sec-level compatible
set vpn SiteB-VPN bind interface tunnel.1
set vpn SiteB-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 62
set ike gateway SiteC address siteC-external -IP outgoing-interface interface
preshare presharedkey sec-level compatible
set vpn SiteC-VPN gateway SiteA sec-level compatible
set vpn SiteC-VPN bind interface tunnel.1
set vpn SiteC-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
It is possible to use other Phase 1 & 2 proposals apart from compatible.
Routes:
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
set vrouter untrust-vr route siteA-Net interface tunnel.1 gateway siteA-tunnel -IP
set vrouter untrust-vr route siteB-Net interface tunnel.1 gateway siteB-tunnel -IP
set vrouter untrust-vr route siteC-Net interface tunnel.1 gateway siteC-tunnel-IP
set interface tunnel.1 nhtb siteA-tunnel-IP vpn SiteA-VPN
set interface tunnel.1 nhtb siteB-tunnel-IP vpn SiteB-VPN
set interface tunnel.1 nhtb siteC-tunnel -IP vpn SiteC-VPN
Policies:
set policy from trust to untrust HO-Net RemoteSites any permit
set policy from untrust to trust RemoteSites HO-Net any permit
For Site A:
Security Zones and Virtual Routers:
unset interface untrust-interface ip
unset interface untrust-interface zone
set zone untrust vrouter untrust-vr
Interfaces:
set interface trust-interface zone trust
set interface trust-interface ip ipaddress/mask(octet)
set interface untrust-interface zone untrust
set interface untrust-interface ip HO-external-IP/mask(octet)
set interface tunnel.1 zone untrust
set interface tunnel.1 ip siteA-tunnel -IP/mask(octet)

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 63
Addresses:
set address trust SiteA-Net ipaddress/mask(octet)
set address untrust HO-Net ipaddress/mask(octet)
VPN to Head Office:
set ike gateway HO address HO-external -IP outgoing-interface interface preshare
presharedkey sec-level compatible
set vpn HO-VPN gateway HO sec-level compatible
set vpn HO-VPN bind interface tunnel.1
set vpn HO-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any
Routes:
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
set vrouter untrust-vr route HO-Net interface tunnel.1 gateway HO-tunnel-IP
Policies:
set policy from trust to untrust SiteA-Net to HO-Net any permit
set policy from untrust to trust HO-Net to SiteA-Net any permit
Configuring Multiple VPNs Through a Single Tunnel Interface using BGP
In order to configure the binding of 3 AutoKey IKE VPNs to a single tunnel interface with
BGP for automatic route entry, use the previous example with the following modified
commands:
For Head Office:
VPNs:
set vpn SiteA-VPN monitor rekey
set vpn SiteB-VPN monitor rekey
set vpn SiteC-VPN monitor rekey
Remember that when using an automatic configuration, VPN monitoring must be
turned on at the hub site (explained further in a following section).
Dynamic Routing:
When configuring dynamic routing, it dynamic routing protocol must be enabled on
both the virtual router and the interface.
ns-> set vrouter untrust-vr protocol bgp AS-Number
ns-> set vrouter untrust-vr protocol bgp enable

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 64
ns-> set interface tunnel.1 protocol bgp
ns-> set vrouter untrust-vr
ns(untrust-vr)-> set protocol bgp
ns(untrust-vr/bgp)-> set neighbor siteA-tunnel-IP remote-as AS-Number outgoing
interface tunnel.1
ns(untrust-vr/bgp)-> set neighbor siteA-tunnel-IP enable
ns(untrust-vr/bgp)-> set neighbor siteB-tunnel-IP remote-as AS-Number outgoing
interface tunnel.1
ns(untrust-vr/bgp)-> set neighbor siteB-tunnel-IP enable
ns(untrust-vr/bgp)-> set neighbor siteC-tunnel-IP remote-as AS-Number outgoing
interface tunnel.1
ns(untrust-vr/bgp)-> set neighbor siteC-tunnel-IP enable
ns(untrust-vr/bgp)-> exit
ns(untrust-vr)-> exit
For Site A:
Dynamic Routing:
ns-> set vrouter untrust-vr protocol bgp AS-Number
ns-> set vrouter untrust-vr protocol bgp enable
ns-> set interface tunnel.1 protocol bgp
ns-> set vrouter untrust-vr
ns(trust-vr)-> set protocol bgp
ns(untrust-vr/bgp)-> set neighbor HO-tunnel -IP remote-as AS-Number outgoing
interface tunnel.1
ns(untrust-vr/bgp)-> set neighbor HO-tunnel -IP enable
ns(untrust-vr/bgp)-> exit
ns(untrust-vr)-> exit
3.9. Overlapping VPN Networks
As the range of IP addresses assignable for the use in private networks is relatively small,
there is a good possibility that you may face a situation where the local area networks of
both VPN end points use the same IP address. This is known as an Overlapping of VPN
Networks. Through the use of NetScreen firewalls we can overcome this problem and still
allow traffic to communicate between the networks by performing both NAT-src and NAT-dst
for both networks.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 65
For the NAT-src configuration, the interfaces at both ends of the tunnel need to be in
mutually exclusive IP address ranges, and have a DIP pool configured so Policy-based NAT-
src can be applied to outgoing traffic.
For the NAT-dst configuration, two options are available for the permitting of inbound traffic:
Policy-based NAT-dst: A policy can apply NAT-dst to translate inbound VPN traffic to
an address that is either in the same subnet as the tunnel interface (but not in the
same range as the local DIP pool used for outbound VPN traffic) or to an address in
another subnet to which the NetScreen device has an entry in its route table.
Mapped IP (MIP): A policy can reference a MIP as the destination address. The MIP
uses an address in the same subnet as the tunnel interface - but not in the same
range as the local DIP pool used for outbound VPN traffic.
Configuring a VPN for Overlapping Networks
In this example, we have two overlapping networks with Policy-based NAT-src and NAT-dst
in order to allow connectivity between a server on each network.
For Site A:
Interfaces:
set interface interface zone untrust
set interface interface ip siteA-external-IP/mask(octet)
set interface tunnel.1 zone untrust
set interface tunnel.1 ip siteA-tunnel -IP/mask(octet)
Configure the DIP pool:
set interface tunnel.1 dip dip-i d dip-start dip-end
The DIP pool needs to be configured in the same network range as the tunnel
interface IP, but cannot include the tunnel interface IP address itself.
Addresses:
set address trust SiteA-Net ipaddress/mask(octet)
set address trust siteA-NAT-IP ipaddress/mask(octet)
This address entry represents the NAT IP address of the server residing on the Site
A network that we will use in the Policy NAT-dst.
set address untrust SiteB-Net ipaddress/mask(octet)
As the Site B network is NAT-src using the DIP configured on Site Bs tunnel
interface, this entry uses the IP address of the DIP since that is what Site A sees the
source IP address as.
set address untrust siteB-NAT-IP ipaddress/mask(octet)
This entry represents the NAT IP address that Site B will use for its Policy NAT-dst.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 66
Routes:
set vrouter untrust-vr route siteB-Net/mask(octet) interface tunnel.1
This route entry represents the entire network assigned to Site Bs tunnel interface.
set vrouter trust-vr route siteA-NAT-IP/mask(octet) interface trust-interface
This entry is required for NAT-dst to function.
set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw
Policies:
set policy from trust to untrust SiteA-Net to siteB-NAT-IP any nat src dip-id dip-id
permit
set policy from untrust to trust SiteB-Net to SiteA-Net any permit
3.10. VPN Monitoring
VPN monitoring allows the NetScreen to send ICMP echo requests through a VPN tunnel at
specified intervals to determine the status of the tunnel. If the status of a VPN tunnel is Up,
and the firewall does not receive a response after a specified number of attempts, the
NetScreen believes the VPN is down and changes the status to Down. If a VPN tunnel is
down and the firewall receives a response while the Phase 2 SAs are still active, the
NetScreen will change the status of the tunnel back to Up.
There are some policy configurations which may need to be considered when configuring
VPN Monitoring. From the source firewall, it may be necessary to configure a policy to permit
ICMP echo requests from the source zone to the destination zone if:
The source zone is in a different zone from the destination address; or
The source interface is in the same zone as the destination address, and intrazone
blocking is enabled.
On the destination firewall, it may also be necessary to configure a policy to permit ICMP
echo requests from the source zone to the destination zone if:
The destination address is in a different zone from the source address; or
The destination address is in the same zone as the source address, and intrazone
blocking is enabled.
Configuring VPN Monitoring
In order to configure VPN Monitoring for a given VPN tunnel, issue the following commands:
set vpnmonitor frequency frequency-number
Where frequency-number is in seconds. The default value is 10 second intervals.
set vpnmonitor threshold threshold-number

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 67
Where the threshold-number is the number of consecutive successful or failed
responses. The default value is 10.
set vpn vpn-name monitor source-interface interface destination-ip dst-ip [optimized]
[rekey]
By default, the firewall will use the VPN tunnels egress interface address as the
source-interface and the destination interfaces IP address as the dst-ip. However, if
necessary, these values can be changed to suit the VPN Monitoring. Both the
optimized and rekey settings are optional.
3.10.1. Rekey
Normally, the NetScreen firewall will only perform VPN monitoring (if it is enabled) while the
tunnel is active and UP and user-generated traffic is passing through the tunnel. By enabling
the Rekey option, the firewall will continuously send ICMP echo requests as soon as the
tunnel has been configured. The echo requests will attempt to trigger the IKE module to
establish an active VPN tunnel and will continue to do so until the state of the tunnel is Up.
Once the tunnel is active and up, the firewall will continue to monitor as normal.
If VPN monitoring then detects that the tunnel is Down, the firewall will instead deactivate the
Phase 2 SAs for that peer and will continuously send echo requests to the peer in order to
reinitiate Phase 2, and if need be, Phase 1 negotiations. The firewall will continue to do this
until negotiations are successful, in which case, the Phase 2 SAs are reactivated and a new
key is generated to reestablish the tunnel.
3.10.2. Optimisation
Another option when enabling VPN Monitoring is to enable the Optimization feature. In
certain situations, there may be limited bandwidth in order to continuously send ICMP echo
requests to monitor the status of a tunnel. By enabling Optimisation, the following VPN
Monitoring behaviours come into effect:
The NetScreen device considers incoming traffic through the VPN tunnel to be
the equivalent to ICMP echo replies. Accepting incoming traffic as a substitute
for ICMP echo replies can reduce false alarms that might occur when traffic
through the tunnel is heavy and the echo replies do not get through.
If there is both incoming and outgoing traffic through the VPN tunnel, the firewall
suppresses VPN Monitoring ICMP echo requests altogether, thus assisting in
reducing network traffic.
3.11. VPN Groups
NetScreen firewalls can be deployed in a configuration in order to provide fault-tolerant VPN
connectivity between sites. A VPN Group is a cluster of up to 4 NetScreen firewalls to
provide VPN failover in the instance that one member of the group becomes inactive (either
due to hardware failure or possibly external connectivity failure).
When a NetScreen firewall attempts to establish a VPN with a cluster of NetScreen firewalls
configured as a VPN Group, it performs Phase 1 and 2 negotiations with all firewalls in the
VPN Group. VPN traffic is then sent through to the group member with the highest priority (or
weight). If that VPN tunnel fails, the active tunnel will failover to the tunnel and gateway with
the second highest priority in the group.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 68
NetScreen firewalls use two mechanisms to monitor the members of a VPN Group to
determine their ability to terminate VPN traffic: IKE Heartbeats and IKE Recovery Attempts.
With the addition of the TCP Application Failover option, traffic can be shifted between the
tunnels of different VPN Group members without disrupting the VPN tunnel and without the
experience of packet loss.
IKE heartbeats are hello messages that IKE peers send to each other through an
established Phase 1 Security Association (SA) to confirm the connectivity and wellbeing of
the other. If, for example, device_m (the monitor) does not receive a specified number of
heartbeats (the default is 5) from device_t (the target), device_m concludes that device_t is
down. Device_m clears the corresponding Phase 1 and Phase 2 security associations (SAs)
from its SA cache and begins the IKE recovery procedure. After a defined interval, the
monitor attempts to initiate Phase 1 negotiations with the failed peer. If the first attempt is
unsuccessful, the monitor continues to attempt Phase 1 negotiations at regular specified
intervals until negotiations are successful (the IKE Recovery Attempt).
!
In order for VPN Groups to function correctly, IKE Heartbeats must be
enabled on both the initiating device and each of the recipients in the VPN
Group. Otherwise, one of the devices will suppress the IKE Heartbeats and
an error will occur.
3.11.1. Priorities
Members in a VPN Group are assigned a different priority or weight. This weight determines
which member will be responsible for the active tunnel. In the instance that the member with
the highest priority fails, the next highest priority member will take over the active tunnel. A
weight is a number, and the closer the number is to 1 (1 being the lowest number), the lower
the priority.
!
As you will see now, and throughout this study guide, there are many
different weights and priorities regarding various points of configuration for a
NetScreen firewall. Many of these weighting schemes are not consistent with
others, and hence, you must make an extra effort to remember the ordering
of different priorities for each option.

Configuring VPN Redundancy with VPN Groups
To configure a VPN Group, issue the following commands on the device connecting to the
VPN Group (this example uses Policy-based VPNs):
!
Configuring a VPN Group is very different to configuring an NSRP Cluster (as
we will see in a later section). VPN Group members are not aware of each
other. The properties of the VPN Group is configured on the device which is
connecting to the group. When a group member fails, it is the connecting
device which determines the next member in the group that it should begin
passing traffic to.

On the firewall connecting to the VPN Group:
set ike gateway gw-name heartbeat hello number
Where number indicates the number of heartbeats to send. The default is 5.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 69
set ike gateway gw-name heartbeat reconnect interval
Where interval is the number of seconds a peer should wait before attempting to
reinitiate Phase 1 or 2 negotiations. The minimum interval is 60.
set ike gateway gw-name heartbeat threshold number
Where number is the number of successful or failed heartbeats before a tunnel will
be deemed as active or inactive. The default is 5.
set vpn-group id group-id vpn vpn-name weight weight
This command is issued for each peer in the VPN group where weight is the priority
assigned to that peer.
unset flow tcp-syn-check-in-tunnel
This command prevents failover packets from being dropped. If an action session
fails over to a new VPN Group member, the first packet it receives may not be a syn
packet (as the session had already been established previously). Normally, the
default reaction of the firewall would be to drop the packet. Hence, when configuring
VPN Groups, it is necessary to disable the tcp-syn-flag checking option.
Policies:
set policy top from src-zone to dst-zone src-net dst-net any tunnel vpn-group group-
id
set policy top from src-zone to dst-zone dest-net source-net any tunnel vpn-group
group-id
3.12. VPN Troubleshooting
When a VPN cannot be established, it is expected that you, as a JNCIS-FWV, can figure out
what the problem is. Thankfully, NetScreen firewalls provide a wealth of troubleshooting and
debug options for you to be able to determine the exact issue.
A VPN can fail due to many different reasons. When they do fail, the best place to check for
the problem is not on the initiating device, but on the recipient device. This is because the
initiating device generally provides little to no information as to why the VPN has failed.
Mostly, you will see the initiating device continuously send requests to establish a tunnel
over and over again. This may indicate something is wrong with that particular phase, but it
does not provide the information to assist you in determining what the exact problem is.
However, on the recipient device, error messages can be easily obtained, detailing exactly
why the initiators attempts to establish a VPN are failing.
3.12.1. IKE
Its safe to say that a majority of the time, a failure in VPN tunnel establishment is due to
failures in IKE or IPSec negotiations. NetScreen firewalls include various commands to
diagnose issues with Phase 1 establishment.
IKE Cookies
This command allows you to determine the status of a Phase 1 IKE tunnel:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 70
get ike cookies
Output:
Active: 1, Dead: 0, Total 1
522f/0003, 1.1.1.2:500->1.1.1.1:500, PRESHR/grp2/3DES/SHA, xchg(2)
resent-tmr 7166032 lifetime 28800 lt-recv 28800 nxt_rekey 28379 cert-expire 0
initiator, err cnt 0, send dir 0, cond 0x0
nat-traversal map not available
ike heartbeat : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
The first line displays whether there are any active or dead Phase 1 tunnels. If there are
active tunnels, their details are displayed.
The second line shows the initiator and recipient IP addresses and the Phase 1 proposal
type.
The second line shows the SA lifetime with the nxt_rekey value displaying the time until the
next Phase 1 rekey.
In this example, we can see that nat-traversal has not been enabled.
The final few lines also highlight where IKE heartbeats have been enabled (in this example
there is possibly a configuration error, but more likely, it is indicating that VPN Groups are
not in use). The last line shows whether XAuth is in use.
Viewing the Event Log
The event log is responsible for displaying successful and unsuccessful VPN tunnel
negotiations. Use the following command to view the event log:
get event
Output:
2000-04-12 15:31:33 system info 00536 IKE<1.1.1.1> Phase 2 msg ID <11f49203>:
Completed negotiations with SPI
<e3270b99>, tunnel ID <1>, and
lifetime <3600> seconds/<0> KB.
2000-04-12 15:31:33 system info 00536 IKE<1.1.1.1> Phase 2: Initiated
negotiations.
2000-04-12 15:31:33 system info 00536 IKE<1.1.1.1> Phase 1: Completed Main

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 71
mode negotiations with a
<28800>-second lifetime.
In the example output, you can observe that Phase 1 and Phase 2 negotiations have
succeeded. The information displayed includes the peer, the SPI, and key lifetimes.
Using IKE Debug
The event log also displays failed negotiation attempts and even though it includes the
general error message, it does not display the specific error instance. In order to view that,
we need to enable the debugging of IKE. To enable IKE debugging, issue the following
command:
debug ike basic | detail
Output:
In order to view the output, you must issue the following command:
get dbuf stream
!
As sending a large amount of debugging messages to the console screen
can sometimes overwhelm remote access connections, the NetScreen
firewall stores all debug messages in a debug buffer called dbuf. We will
examine the debug buffer in more detail in a later section.

## 16:23:57 : IKE<1.1.1.2 > Recv*: [HASH] [SA] [NONCE] [ID] [ID]
## 16:23:57 : IKE<1.1.1.2 > extract payload (136):
## 16:23:57 : IKE<1.1.1.2 > QM in state OAK_QM_SA_ACCEPT.
## 16:23:57 : IKE<1.1.1.2 > Start by finding matching member SA (verify -1/-1)
## 16:23:57 : IKE<1.1.1.2 > IKE<1.1.1.2> Matching policy: gw ip <1.1.1.2> peer entry
id<0>
## 16:23:57 : IKE<1.1.1.2 > Local ID: 192.168.1.0/24 prot<0> port<0> type<4>
## 16:23:57 : IKE<1.1.1.2 > Remote ID: 192.168.2.0/24 prot<0> port<0> type<4>
## 16:23:57 : IKE<0.0.0.0 > protocol matched expected<0>.
## 16:23:57 : IKE<0.0.0.0 > port matched expect<0>.
## 16:23:57 : IKE<1.1.1.2 > Proxy ID match: No policy exists for the proxy ID
received
## 16:23:57 : IKE<1.1.1.2 > proxy-id do not match ipsec sa config
## 16:23:57 : IKE<1.1.1.2 > oakley_process_quick_mode():exit
## 16:23:57 : IKE<1.1.1.2 > Phase 2 msg-id <4717e7ea>: Negotiations have failed.
!
Despite its name, IKE Debug also shows IPSec negotiation messages.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 72

3.12.2. Security Associations
A Security Association is created when a tunnel is successfully established with both ends
agreeing on all the security parameters.
Obtaining SA Information
Once Phase 2 negotiations have completed, it is possible to view these properties by
examining the Security Association information. To obtain SA information, issue the
command:
get sa
Output:
total configured sa: 1
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000001< 1.1.1.1 500 esp:3des/sha1 e3270b99 3193 unlim A/- 2 0
00000001> 1.1.1.1 500 esp:3des/sha1 3c472af5 3193 unlim A/- 1 0
The HEX ID represents the unique VPN identifi er.
The Gateway displays the remote peer gateway IP address.
The Port displays the IKE Port in use.
Algorithm displays the Phase 2 proposal used for the tunnel.
The SPI displays the SPI ID for the VPN tunnel.
Life:sec displays the number of seconds remaining before a Phase 2 rekey.
Kb displays the Kilobit rekey threshold.
The VPN status is displayed using the Sta value where the first character (on the left side of
the /) represents A = Active, D = down or I = inactive. The second character (on the right
side of the /) represents the status of the VPN if VPN Monitoring has been enabled where
U = up and D = down. If VPN Monitoring is not enabled, the - character will appear.
For Policy-based VPNs, PID represents the Policy ID that VPN is bound to.
And lastly, Vsys relates to the Virtual System where the VPN resides.
Obtaining More Detailed SA Information
In order to obtain further information regarding a given SA, issue the following command:
get sa id id
Output:
index 0, name VPN to Core - Phase2, peer gateway ip 1.1.1.1. vsys<Root>

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 73
auto key. policy node, tunnel mode, policy id in:<2> out:<1> vpngrp:<-1>.
sa_list_nxt:<-1>.
tunnel id 1, peer id 0, NSRP Local. site-to-site. Local interface is untrust
<1.1.1.2>.
esp, group 0, 3des encryption, sha1 authentication
autokey, IN active, OUT active
monitor<0>, latency: 0, availability: 0
DF bit: clear
app_sa_flags: 0x2067
proxy id: local 192.168.2.0/255.255.255.0, remote 192.168.1.0/255.255.255.0, proto 0,
port 0
ike activity timestamp: 62839
nat-traversal map not available
incoming: SPI e3270b99, flag 00004000, tunnel info 40000001, vector(d:65e4c0)
life 3600 sec, 2248 remain, 0 kb, 0 bytes remain
anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1352 seconds
next pak sequence number: 0x0
outgoing: SPI 3c472af5, flag 00000000, tunnel info 40000001, vector(e:660f18)
life 3600 sec, 2248 remain, 0 kb, 0 bytes remain
anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1342 seconds
next pak sequence number: 0x4
The additional information provides the incoming and outgoing SPI used as well as proxy ID
information.
3.12.3. Common VPN Errors
As a JNCIS-FWV candidate, you are examined on a number of the VPN error messages,
and are expected to be able to understand what they refer to and also how to fix them.
Detailed errors appear on the recipient end of the VPN tunnel.
Phase 2: No policy exists for the proxy ID received
This error relates to a misconfigured proxy-ID. The following is a sample output containing
this error:
2004-04-06 16:24:25 system info 00536 IKE<1.1.1.2> Phase 2 msg ID <4717e7ea>:
Negotiations have failed.
2004-04-06 16:24:25 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with
cookies cfaf76fe7f73ae52 and

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 74
57436be50cbe5372 because the peer sent
a proxy ID that did not match the one
in the SA config.
2004-04-06 16:24:25 system info 00536 IKE<1.1.1.2> Phase 2: No policy exists
for the proxy ID received: local ID
(<192.168.1.0>/<255.255.255.0>, <0>,
<0>) remote ID (<192.168.2.0>/
<255.255.255.0>, <0>, <0>).
It is common for different ends of the VPN to have a different policy configured for the VPN.
One end may be using an entire network range while the other is using a single host. This
results in a proxy-ID mismatch between the two devices during Phase 2 negotiation.
The most common place to look for a proxy-ID when a tunnel has been established is in the
Detail Security Association information. However, if the tunnel is failing, where are some
other places we can look? Well, if it is a Route-based VPN, the proxy-IDs are required to be
configured as part of the VPN tunnel. But what if its a Policy-based VPNs? If you recall, in a
Policy-based VPN, the proxy-ID is based on the policy which references the VPN (unless the
proxy-ID has been manually specified). Hence, we can view the proposed proxy-ID by
examining the details of the relevant policy using the following command:
get policy id id
Let us examine the two policies for this current example.
Output:
ns208-> get policy id 1
name:"none" (id 1), zone Trust -> Untrust,action Tunnel, status "enabled", pair
policy 2
src "Any", dst "192.168.2.0/24", serv "ANY"
Policies on this vpn tunnel: 0
nat off, url filtering OFF
vpn VPN to Remote Site1 - Phase2, nsp tunnel 40000002, sa index 1, sa tunnel id 2
policy flag 0000, session backup: on
traffic shapping off, scheduler n/a, serv flag 00
log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 285846, counter(session/packet/octet) 0/0/0
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/-1
proxy id:
local 0.0.0.0/0.0.0.0, remote 192.168.2.0/255.255.255.0, proto 0, port 0

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 75
No Authentication
No User, User Group or Group expression set

ns5gt-> get policy id 2
name:"none" (id 2), zone Untrust -> Trust,action Tunnel, status "enabled", pair
policy 1
src "192.168.1.0/24", dst "192.168.2.0/24", serv "ANY"
Policies on this vpn tunnel: 1
[192.168.1.0/24, 192.168.2.0/24, 0-65535, 0-65535, 0]
nat off, url filtering OFF
vpn VPN to Core - Phase2, nsp tunnel 40000001, sa index 0, sa tunnel id 1
policy flag 0000, session backup: on
traffic shapping off, scheduler n/a, serv flag 00
log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 284852, counter(session/packet/octet) 0/0/0
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/-1
proxy id:
local 192.168.2.0/255.255.255.0, remote 192.168.1.0/255.255.255.0, proto 0, port 0
No Authentication
No User, User Group or Group expression set
Note the difference in the proxy-IDs. The policy on the ns208 is using a destination of any
while the ns5gt is using a specified network of 192.168.1.0. The easiest way to correct this
problem, is to change the relevant value on either device (depending on which is more
incorrect). For example, if we changed the ns208s policy from any to 192.168.1.0/24 then
both proxy-IDs would match.
Rejected an IKE packet because there were no acceptable Phase 1 proposals
This error typically occurs if the Phase 1 proposals on both end points do not match. The
following is a sample output containing this error:
2004-04-06 16:52:54 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with
cookies 1b61a768b134a44a and
99cd98ba0e182b07 because there were no
acceptable Phase 1 proposals.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 76
In order to obtai n the specific proposals being used and expected, simply use the IKE debug.
The following is a sample output relevant to this example:
## 16:52:15 : IKE<1.1.1.2 > Process [SA]:
## 16:52:15 : IKE<1.1.1.2 > Proposal received:
## 16:52:15 : IKE<1.1.1.2 > auth(1)<PRESHRD>, encr(5)<3DES>, hash(2)<SHA>, group(2)
## 16:52:15 : IKE<1.1.1.2 > xauth: disabled
## 16:52:15 : IKE<1.1.1.2 >
## 16:52:15 : IKE<1.1.1.2 > xauth flag: 0, 0
## 16:52:15 : IKE<1.1.1.2 > auth value: 1, 1
## 16:52:15 : IKE<1.1.1.2 > enc value: 5, 5
## 16:52:15 : IKE<1.1.1.2 > [0] expect:
## 16:52:15 : IKE<1.1.1.2 > auth(1)<PRESHRD>, encr(5)<3DES>, hash(1)<MD5>, group(2)
## 16:52:15 : IKE<1.1.1.2 > xauth: disabled
## 16:52:15 : IKE<1.1.1.2 > Phase 1: Rejected proposals from peer. Negotiations
failed.
## 16:52:15 : IKE<1.1.1.2> (0,r): ERROR: IKE error, when processing oak_no_sate
You can see that the initiating device, sent a proposal which entailed preshared/3DES/SHA
where the recipient was expecting preshared/3DES/MD5.
The simplest way to correct this problem is to modify the proposal for one of the devices so it
matches the other.
Rejected an IKE packet because there were no acceptable Phase 2 proposals
This error typically occurs if the Phase 2 proposals on both end points do not match. The
following is a sample output containing this error:
2004-04-06 17:15:01 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with
cookies 83e1f5209ce4640e and
fc666af880db4a5c because there were no
acceptable Phase 2 proposals.
Much like the Phase 1 proposal errors, the IKE debug provides full specifics regarding the
proposal settings. The following is a sample output relevant to this example:
## 17:15:01 : IKE<1.1.1.2 > Phase 2 received:
## 17:15:01 : IKE<1.1.1.2 > atts<00000003 00000000 00000003 00000002 00000001
00000000>
## 17:15:01 : IKE<1.1.1.2 > proto(3)<ESP>, esp(3)<ESP_3DES>, auth(2)<SHA>,
encap(1)<TUNNEL>, group(0)

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 77
## 17:15:01 : IKE<1.1.1.2 > expect [0]:
## 17:15:01 : IKE<1.1.1.2 > atts<00000003 00000000 00000003 00000001 00000001
00000000>
## 17:15:01 : IKE<1.1.1.2 > proto(3)<ESP>, esp(3)<ESP_3DES>, auth(1)<MD5>,
encap(1)<TUNNEL>, group(0)
## 17:15:01 : IKE<1.1.1.2 > proposal not acceptable, but no more proposal in payload.
## 17:15:01 : IKE<1.1.1.2 > Phase 2: Rejected proposals from peer. Negotiations
failed.
## 17:15:01 : IKE<1.1.1.2> (3,r): ERROR:
You can see in this example that the initiator sent a proposal of no-PFS/ESP/3DES/SHA
while the recipient was expecting no-PFS/ESP/3DES/MD5. To correct this problem, simply
modify the Phase 2 proposal for one of the devices so it matches the other.
Rejected an IKE packet (The preshared keys might not match.)
The answer to this one is rather obvious, but its safe to say that the preshared keys used by
both devices did not match. The following output displays the IKE debug relevant to this
example:
## 17:22:26 : IKE<1.1.1.2 > Construct ISAKMP header.
## 17:22:26 : IKE<1.1.1.2 > Msg header built (next payload #4)
## 17:22:26 : IKE<1.1.1.2 > Construct [KE] for ISAKMP
## 17:22:26 : IKE<1.1.1.2 > Construct [NONCE]
## 17:22:26 : IKE<1.1.1.2 > throw packet to the peer, paket_len=184
## 17:22:26 : IKE<1.1.1.2 > Xmit : [KE] [NONCE]
## 17:22:26 : IKE<1.1.1.2 > send_request to peer
## 17:22:26 : IKE<1.1.1.2 > Send Phase 1 packet (len=184)
## 17:22:26 : IKE<1.1.1.2 > ike packet, len 96, action 0
## 17:22:26 : IKE<0.0.0.0 > coach. sock 1024
## 17:22:26 : IKE<1.1.1.2 > ****** Recv packet if <ethernet3> of vsys <Root> ******
## 17:22:26 : IKE<1.1.1.2 > Catcher: get 68 bytes. src port 500
## 17:22:26 : IKE<1.1.1.2 > SA: (Root, local 1.1.1.1, state 2/620f, r):
## 17:22:26 : IKE<1.1.1.2 > ISAKMP msg: len 68, nxp 5[ID], exch 2[MM], flag 01 E
## 17:22:26 : IKE<1.1.1.2 > gen_skeyid()
## 17:22:26 : IKE<1.1.1.2 > Decrypting payload (length 40)
## 17:22:26 : IKE<1.1.1.2 > Recv*: [ID] +++ Corrupted MSG
## 17:22:26 : IKE<1.1.1.2 > Validate (40): bad 30
## 17:22:26 : IKE<1.1.1.2 > Packet is invalid!

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 78
## 17:22:26 : IKE<1.1.1.2 > Pre-shared key might not match.
To correct this issue, simply double check the preshared keys on both end points to ensure
that they match.
Rejected an IKE packet an initial Phase 1 packet arrived from an unrecognized peer
gateway.
This error commonly occurs when the outgoing interface for a given VPN has been
incorrectly specified. For example, if the Internet facing interface and recipient of VPN traffic
is Ethernet3, but the VPN has been incorrectly configured with an outgoing interface of
Ethernet1, then this error will occur as the VPN tunnel is expecting the IKE traffic to arrive on
Ethernet1.
The following is a sample output containing this error:
2004-04-06 17:37:36 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with
cookies 2744c0e8d008c6e3 and
0000000000000000 because an initial
Phase 1 packet arrived from an
unrecognized peer gateway.
To correct this issue, simply reconfigure the VPN configuration to the correct interface.
3.13. Review Questions

1. Which of the following is not a valid Phase 2 proposal?
a. nopfs-esp-3des-sha
b. g5-ah-null -md5
c. g3-esp-aes-md5
d. g1-esp-des-sha
2. At which point do the end points exchange a nonce during main mode negotiations?
a. Messages 1 and 2
b. Messages 2 and 3
c. Messages 3 and 4
d. Messages 5 and 6
3. Which of the following options must be additionally configured to allow two overlapping
networks to establish a VPN successfully? Select the THREE best options.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 79
a. NAT-src using DIPs
b. NAT-src using Interface NAT
c. MIPs
d. VIPs
e. A route to the remote network through the tunnel interface.
4. Which options must be configured for VPN redundancy? Select the two best options.
a. Aggressive mode
b. IKE Heartbeats and Recovery Attempts
c. TCP-SYN-Check
d. Main mode
e. VPN Group Weightings
5. How many VPN tunnels are required for full mesh bidirectional traffic between 20
NetScreen devices?
a. 200
b. 100
c. 190
d. 150
6. While troubleshooting a VPN problem, you notice the following error message: packet
arrived from an unrecognized peer gateway. What might be causing the problem?
a. The initiator is using the wrong peer IP address.
b. The recipient is using the wrong outgoing interface for the VPN.
c. The initiator is using the wrong outgoing interface for the VPN.
d. The recipients IP address is configured incorrectly.
7. Observe the following information:
Active: 1, Dead: 0, Total 1
522f/0003, 1.1.1.2:500->1.1.1.1:500, PRESHR/grp2/3DES/SHA, xchg(2)
resent-tmr 7166032 lifetime 28800 lt-recv 28800 nxt_rekey 28379 cert-expire 0
initiator, err cnt 0, send dir 0, cond 0x0
nat-traversal map not available
ike heartbeat : disabled

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 80
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
What can you determine from the presented information? Select the TWO best answers.
a. Phase 1 negotiation has failed.
b. NAT traversal is not enabled.
c. The key has been valid for 421 seconds.
d. The key has been valid for 28379 seconds.
e. The identification method is Digital Certificates.
8. Observe the following information:
total configured sa: 1
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000001< 1.1.1.1 500 esp:3des/sha1 e3270b99 3193 unlim A/- 2 0
00000001> 1.1.1.1 500 esp:3des/sha1 3c472af5 3193 unlim A/- 1 0
What can you determine from the presented information? Select the TWO best answers.
a. The VPN tunnel is not active.
b. VPN Monitoring is enabled and the tunnel is Up.
c. The SA has been valid for 3193 seconds.
d. The SA has been valid for 407 seconds.
e. The outgoing SA is related to policy 500.
9. Which of the following commands can be used to troubleshoot Phase 1 connectivity
problems? Select the TWO best answers.
a. get event on the initiator
b. get event on the recipient
c. debug IKE detail on the recipient
d. debug IKE on the initiator
e. get IKE detail on the recipient
10. Observe the following information:
2004-04-06 16:24:25 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 81
cookies cfaf76fe7f73ae52 and
57436be50cbe5372 because the peer sent
a proxy ID that did not match the one
in the SA config.
2004-04-06 16:24:25 system info 00536 IKE<1.1.1.2> Phase 2: No policy exists
for the proxy ID received: local ID
(<172.16.1.1>/<255.255.255.255>, <0>,
<0>) remote ID (<172.16.2.0>/
<255.255.255.0>, <0>, <0>).
The policy for the initiator is:
src "172.16.2.0/24", dst "172.16.1.1/32", serv "ANY"
The policy for the recipient is:
src "172.16.1.0/24", dst "172.16.2.0/24", serv "ANY"
Which of the below options could be used to correct this issue?
a. Change the dst for the initiator to be 172.16.1.0/24
b. Change the src for the recipient to be 172.16.1.0/32
c. Change the dst for the recipient to be 172.16.2.1/32
d. Change the src for the initiator to be 172.16.2.1/32
11. What are the components required to be loaded on a NetScreen Firewall to support
digital certificates? Select the THREE best answers.
a. CRL
b. CAs Private Key
c. CAs Digital Certificate
d. Local Certificate
e. OCSP
12. What attributes about the NHTB table are true? Select the TWO best answers.
a. NHTB tables are intrinsic to the firewall and cannot be manipulated.
b. NHTB tables support automatic entries.
c. NHTB tables can be written to but cannot be viewed.
d. NHTB tables can be viewed but not written to.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 82
e. NHTB tables include the destination and VPN tunnel to use.
13. Observe the following information:
Firewall 1: VPN Group 1 Weight 3
Firewall 2: VPN Group 1 Weight 1
Firewall 3: VPN Group 1 Weight 4
Firewall 4: VPN Group 1 Weight 2
If the VPN tunnel to the highest priority group member were to fail, which firewall would
be next to take over the VPN tunnel?
a. Firewall 1
b. Firewall 2
c. Firewall 3
d. Firewall 4
14. Which attributes need to be configured for a VPN to be successfully established with a
Dynamic Peer? Select the THREE best answers.
a. Aggressive Mode
b. A peer ID on the Dynamic Peer
c. A local ID on the Dynamic Peer
d. A peer ID on the Static Peer
e. A local ID on the Static Peer
15. When an OCSP server receives a request from a NetScreen firewall, what is it typically
referred to?
a. An OCSP Receiver
b. AN OCSP Server
c. AN OCSP Responder
d. AN OCSP Handler
16. What is the default proxy-ID for a Route-based VPN?
a. It is dynamically derived from the policy.
b. Route-based VPNs do not have a default proxy-ID. It must be specified.
c. The source IP and destination IP of the first packet through the VPN.
d. Any network.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 83
17. What components are required for a Route-based VPN? Select the THREE best
answers.
a. Tunnel interface.
b. Security Policies.
c. A binding of the VPN to the tunnel interface.
d. A binding of the tunnel interface to the VPN.
e. A route to the remote network through the tunnel interface.
18. What must be configured on a Hub and Spoke VPN for it to be able to enforce policies?
Select the TWO best answers.
a. Intrazone Blocking needs to be disabled.
b. Intrazone Blocking needs to be enabled.
c. All tunnels need to be in the same zone.
d. All tunnels need to be in different zones.
e. You cannot enforce policies on a Hub and Spoke VPN.
19. What is exchanged during a Phase 2 proposal?
a. Identities.
b. Proxy-IDs.
c. Preshared Keys.
d. Digital Certificates.
3.13.1. Review Answers
1. Which of the following is not a valid Phase 2 proposal?
c. The construct of a Phase 2 proposal is NO-PFS|DH
Group/ESP|AH/Encryption/Authentication. The NetScreen only supports DH groups 1, 2
and 5.
2. At which point do the end points exchange a nonce during main mode negotiations?
c. Main mode negotiation is made up of 3 exchanges with 2 messages per exchange.
The generation and exchanging of nonces occurs during messages 3 and 4 once a
secure channel has been established using messages 1 to 4.
3. Which of the following options must be additionally configured to allow two overlapping
networks to establish a VPN successfully? Select the THREE best options.
a, c, e. NAT-src using DIPs is required to translate the source traffic if Policy NAT-dst is
being used for inbound NAT. MIPs can be used to provide both NAT-src and NAT-dst. A
route to the remote network is also required using the tunnel interface.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 84
4. Which options must be configured for VPN redundancy? Select the TWO best options.
b, e. In order to connect to a VPN Group, IKE heartbeats and IKE recovery attempts
must be configured, as well as the assignment of weightings to each of the VPN Group
members. It is possible to connect to a VPN Group regardless of the IKE mode being
used. While TCP-SYN-Check provides seamless failover, it is not mandatory (leaving it
enabled will require connections to be re-established by the client).
5. How many VPN tunnels are required for full mesh bidirectional traffic between 20
NetScreen devices?
c. Recall the formula [N x [N 1]]/2 where N is the number of sites/devices in the VPN
mesh. Applying the formula to the information given: [20 x [20 1]]/2 = 190.
6. While troubleshooting a VPN problem, you notice the following error message: packet
arrived from an unrecognized peer gateway. What might be causing the problem?
b. This error will normally occur if the recipient has configured the wrong outgoing
interface in relation to the VPN. The issue cannot be with the initiator or with the
recipients IP address as the packet would not have arrived at the recipient otherwise.
7. Observe the following information:
Active: 1, Dead: 0, Total 1
522f/0003, 1.1.1.2:500->1.1.1.1:500, PRESHR/grp2/3DES/SHA, xchg(2)
resent-tmr 7166032 lifetime 28800 lt-recv 28800 nxt_rekey 28379 cert-expire 0
initiator, err cnt 0, send dir 0, cond 0x0
nat-traversal map not available
ike heartbeat : disabled
ike heartbeat last rcv time: 0
ike heartbeat last snd time: 0
XAUTH status: 0
What can you determine from the presented information? Select the TWO best answers.
b, c. The output from get ike cookie displays information relating to a Phase 1
negotiation. The active status of this output shows that the Phase 1 negotiation is
successful. The nxt-rekey field is details the number of seconds remaining before the
next rekey. Hence, we can assume that the current key has been active for 421 seconds
(28800 28379). As the NAT traversal map is not available, we can assume that NAT
traversal has not been enabled. By the proposal method, we can tell that this Phase 1
tunnel was established using PRESHR Preshared Keys.
8. Observe the following information:
total configured sa: 1
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000001< 1.1.1.1 500 esp:3des/sha1 e3270b99 3193 unlim A/- 2 0
00000001> 1.1.1.1 500 esp:3des/sha1 3c472af5 3193 unlim A/- 1 0

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 85
What can you determine from the presented information? Select the TWO best answers.
d, e. The output of get sa displays information regarding the status of Phase 2
negotiation. If a VPN tunnel is active, the output will be similar to that of the above.
Similar to the get ike cookies output, the lifetime is displayed in the number of seconds
before rekey. Hence, we can assume that the SA has been valid for 407 seconds (3600
3193). The Sta field informs us about the status of the tunnel, and if VPN monitoring is
enabled, whether the tunnel is Up or Down. If the character of the right side of the / is -
, then we can assume that VPN monitoring has not been enabled for this VPN. The
outgoing SA is represented by the > character, and we can see that it relates to PID
(Policy ID) 1.
9. Which of the following commands can be used to troubleshoot Phase 1 connectivity
problems? Select the TWO best answers.
b, c. Error messages need to be derived on the recipient to provide the most useful
information. The only error messages displayed from the initiator are that of time outs
which dont provide sufficient information to determine what the problem is. The get
event command displays VPN log entries made to the event log, while debug ike detail
displays VPN debug information in the debug buffer.
10. Observe the following information:
2004-04-06 16:24:25 system info 00536 Rejected an IKE packet on ethernet3
from 1.1.1.2:500 to 1.1.1.1:500 with
cookies cfaf76fe7f73ae52 and
57436be50cbe5372 because the peer sent
a proxy ID that did not match the one
in the SA config.
2004-04-06 16:24:25 system info 00536 IKE<1.1.1.2> Phase 2: No policy exists
for the proxy ID received: local ID
(<172.16.1.1>/<255.255.255.255>, <0>,
<0>) remote ID (<172.16.2.0>/
<255.255.255.0>, <0>, <0>).
The policy for the initiator is:
src "172.16.2.0/24", dst "172.16.1.1/32", serv "ANY"
The policy for the recipient is:
src "172.16.1.0/24", dst "172.16.2.0/24", serv "ANY"
Which of the below options could be used to correct this issue?
a. In order for Phase 2 negotiations to be successful, both peers must exchange a
matching proxy-ID. In the above example, either the dst of the initiator can be changed to
match the recipient, or the src of the recipient can be changed to match the dst of the
initiator.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 86
11. What are the components required to be loaded on a NetScreen Firewall to support
digital certificates? Select the THREE best answers.
a, c, d. When loading a digital certificate manually, the three components which need to
be imported into a NetScreen are the CAs digital certificate, the local certificate assigned
to the device, and the CRL.
12. What attributes about the NHTB table are true? Select the TWO best answers.
b, c. Although the NHTB table is largely intrinsic to the firewall, they can be added to and
removed, but cannot be viewed. NHTB table entries can be made manually or
automatically during Phase 2 negotiations.
13. Observe the following information:
Firewall 1: VPN Group 1 Weight 3
Firewall 2: VPN Group 1 Weight 1
Firewall 3: VPN Group 1 Weight 4
Firewall 4: VPN Group 1 Weight 2
If the VPN tunnel to the highest priority group member were to fail, which firewall would
be next to take over the VPN tunnel?
a. As the lower the weight, the lower the priority, in the above example, Firewall 3 has the
highest priority and would be the firewall of choice to initiate VPN traffic to out of the VPN
Group. If Firewall 3 were to fail, the next highest priority member would be Firewall 1.
14. Which attributes need to be configured for a VPN to be successfully established with a
Dynamic Peer? Select the THREE best answers.
a, c, d. Dynamic Peer VPNs require that the IKE mode be set to aggressive, and a local
ID configured on the dynamic peer with the matching ID configured as the peer ID on the
static peer.
15. When an OCSP server receives a request from a NetScreen firewall, what is the OCSP
server typically referred to?
c. When a NetScreen firewall initiates an OCSP request, it is referred to as the OCSP
Requester while the server is referred to as the OCSP Responder.
16. What is the default proxy-ID for a Route-based VPN?
b. Only Policy-based VPNs can automatically derive a proxy-ID from a security policy. As
a Route-based VPN may not necessary require the configuration of policies, the default
proxy-ID does not exist and must be manually specified.
17. What components are required for a Route-based VPN? Select the THREE best
answers.
a, d, e. In order to successfully configure a Route-based VPN, a tunnel interface, a
binding of the tunnel interface to a VPN and the appropriate route referring to the tunnel
interface needs to be added. The configuring of security policies is option depending on
the source and destination zone.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 87
18. What must be configured on a Hub and Spoke VPN for it to be able to enforce policies?
Select the TWO best answers.
b, d. It is possible to enforce security policies in a Hub and Spoke VPN configuration if
the tunnel interfaces either reside in different zones (which will then require a security
policy for traffic to flow from one zone to the other) or for Intrazone Blocking to be
enabled (which will then require a security policy for traffic to flow within interfaces bound
to the same zone).
19. What is exchanged during a Phase 2 negotiation?
b. Proxy-IDs are exchanged during the Phase 2 negotiation. All other options are
exchanged during the Phase 1 negotiation.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 88
4. Network Management
NetScreen firewalls provide multiple management interfaces from multiple management
locations. As a firewall is regarded as a critical security device, the management of a
NetScreen firewall must also include various protection methods to ensure that security is
not compromised.
Management of a NetScreen device is not only restricted to how it is managed, but also
refers to the status of the firewall and the traffic passing through it.
4.1. Local Management
Local management refers to the management of a NetScreen firewall from any trusted
location. This typically includes any interface bound to the Trust zone (or any other trusted
user-defined zones) and directly into the NetScreen through the console interface.
4.2. Remote Management
Remote management refers to the management of a NetScreen firewall from any potentially
untrusted location. This typically includes any interface bound to the Untrust zone (or any
other untrusted user-defined zones).
As remote management connections are typically initiated from a location on the Internet, the
most important configuration aspect for the NetScreen device is how it will route back to the
remote site.
4.3. Manage/r IPs
Two of the most important concepts in regards to the management of NetScreen firewalls
are Manage IPs and Manager IPs (its important not to confuse them).
4.3.1. Manage IPs
Apart from direct management via the console interface, all local and remote management is
configured per interface. You can enforce which interfaces will allow management traffic, the
type of management methods allowed and the IP address to be used for management.
An interface which accepts management traffic will typically use the IP address assigned to it
for management purposes as well as standard network connectivity. However, it may
sometimes be beneficial to not use the interfaces actual IP address as the management IP
address. This is especially true when NetScreens are configured in clusters, or, when you
want to increase security by hiding the management IP address from users (who may know
what the firewalls interface IP address is). The IP address assigned to an interface for the
sole purpose of management is the Manage IP.
Configuring a Manage IP
In order to configure a Manage IP on an interface, issue the following command:
set interface interface manage-ip manage-ip

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 89
Where manage-ip is the IP address you would like assigned to the interface for
management.
The Manage IP address must be on the same network as the IP address assigned to the
interface. When the Manage IP address is assigned, the interface will respond to ARP
requests for its own IP address as well as the Manage IP address.
!
When a Manage IP address is assigned to an interface, the IP address of the
interface itself can no longer be used to manage the firewall.

In order to view the Manage IP assigned to an interface, simply view the interface properties
using the following command:
get interface interface
Output:
Interface ethernet1:
number 0, if_info 0, if_index 0, mode route
link up, phy-link up/half-duplex
vsys Root, zone Trust, vr trust-vr
dhcp client disabled
PPPoE disabled
*ip 10.3.1.1/24 mac 0040.ab33.12f0
*manage ip 10.3.1.2, mac 0040.ab33.12f0
route-deny disable
ping enabled, telnet disabled, SSH enabled, SNMP disabled
web enabled, ident-reset disabled, SSL enabled
webauth disabled, webauth-ip 0.0.0.0
RIP disabled
bandwidth: physical 100000kbps, configured 0kbps, current 0kbps
total configured gbw 0kbps, total allocated gbw 0kbps
DHCP-Relay disabled
DHCP-server disabled
In this example, we can see that manage IP address is different from the interface IP
address.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 90
4.3.2. Manager IPs
Where a Manage IP is the IP address assigned to an interface for the purposes of
management, a Manager-IP is the IP address of a host, range or network that can access
the NetScreen in order to manage it.
The Manager-IPs are global, that is, they are not configured on an interface-by-interface
basis. Once an IP address has been defined as a Manager-IP, it applies to all interfaces.
!
By default, no Manager-IPs are configured on the firewall. This means that
the NetScreen firewall can be managed from ANY IP address. To increase
security, it is recommended that the necessary local hosts are added for local
management, and the necessary remote hosts added for remote
management.

Adding Manager IPs
In order to add a Manager-IP, issue the following command:
set admin manager-ip ip-address subnet -mask
Viewing Current Manager IPs
In order to view the currently configured Manager-IPs, issue the following command:
get admin manager-i p
Output:
Mng Host IP: 192.168.1.100/255.255.255.255
4.4. Management Methods
The management methods or interfaces for a NetScreen firewall can be roughly categorised
into three groups: CLI based, WebUI based or through the NetScreen Security Manager
(NSM). In order to manage a NetScreen firewall using a given management method, that
method must be enabled on the relevant interface.
Viewing the Management Methods Configured for an Interface
In order to view the management methods that have been currently configured for an
interface, issue the command:
get interface interface
Output:
Interface ethernet1:
number 0, if_info 0, if_index 0, mode route
link up, phy-link up/half-duplex
vsys Root, zone Trust, vr trust-vr
dhcp client disabled

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 91
PPPoE disabled
*ip 10.3.1.1/24 mac 0040.ab33.12f0
*manage ip 10.3.1.1, mac 0040.ab33.12f0
route-deny disable
ping enabled, telnet disabled, SSH enabled, SNMP disabled
web enabled, ident-reset disabled, SSL enabled
webauth disabled, webauth-ip 0.0.0.0
RIP disabled
bandwidth: physical 100000kbps, configured 0kbps, current 0kbps
total configured gbw 0kbps, total allocated gbw 0kbps
DHCP-Relay disabled
DHCP-server disabled
In this example, we can see that SSH, web and SSL management methods have been
enabled.
4.4.1. CLI
The Command Line Interface (CLI) is the most efficient of all the management methods (in
terms of bandwidth). Using the CLI, commands and configurations are directly issued to the
firewall. Most debugging and troubleshooting can only be performed using one of the CLI
interfaces.
The three CLI interfaces are: telnet, SSH and console.
!
When using the CLI management method, it is important to remember that
configurations are not automatically saved. The save command must be
issued after configuration to ensure they are written to memory. This is not
required for WebUI as configurations are written to memory immediately after
they are applied.

Console is the most secure CLI method as it requires direct physical access to the device
with a console cable. The console management interface is typically used to initially
configure a NetScreen firewall and to manage it when network connectivity has failed or is
unavailable.
SSH is the most common network based CLI method as management traffic is encrypted
and secured.
!
NetScreen firewalls support both SSH v2 and v1 (for backwards
compatibility). Due to inherent weaknesses in v1, it is recommended that you
use v2 wherever possible.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 92
Telnet access is the least secure CLI method, but is handy if management access is
required and the connecting client does not have SSH client software (most clients include
telnet client software however). By default, interfaces assigned to the Trust zone have telnet
enabled. Though, management access to the interface is only through the Local Area
Network, the traffic is still visible in the clear if any disgruntled employee chooses to monitor
the traffic. Hence, the telnet management method is not recommended.
Configuring SSH Management
In order to configure SSH management for a given interface, SSH must first be enabled and
the RSA keypairs generated. In order to enable SSH, issue the following commands:
set ssh version v1|v2
set ssh enable
The keypairs are generated when ssh is enabled.
Once SSH has been enabled, it is necessary to configure the SSH management method on
the relevant interface. For the relevant interface, issue the following command:
set interface interface manage ssh
Configuring Telnet Management
In order to configure telnet management, issue the following command for the relevant
interface:
set interface interface manage telnet
4.4.2. WebUI
NetScreen firewalls provide a simple to use Web User Interface (WebUI) management
method through standard HTTP or more securely using SSL.
Unlike HTTP management, SSL management requires the loading of a digital certificate
(covered in a previous section). Unlike other devices, a NetScreen firewall cannot generate
its own digital certificate for the purposes of management.
Configuring HTTP (Web) Management
To enable web management for a given interface, issue the following command:
set interface interface web
Configuring SSL Management
Once you have obtained a digital certificate, to enable web management for a given
interface, issue the following command:
set interface interface ssl

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 93
4.4.3. NSM
The NetScreen Security Manager is the central management tool which allows you to
manage and monitor multiple NetScreen firewalls. NSM is not covered as part of the JNCIS-
FWV.
4.5. User Privileges
The concept of user privilege assignment is an important part of administration. An
administrative user should only have enough privilege to perform their given task. NetScreen
firewalls have five categories of administrative users: root, root system write/read, root
system read only, virtual system write/read and virtual system read only.
Configuring User Privileges
To configure an administrative user with various user privileges, issue the following
command:
Set admin user username password password privilege all | read-only
4.5.1. Root User
A NetScreen device can only ever have one root user (the admin user created by default).
The root user has the following privileges:
Manages the root system of the NetScreen device
Adds, removes, and manages all other administrators
Establishes and manages virtual systems, and assigns physical or logical interfaces
to them
Creates, removes, and manages virtual routers (VRs)
Adds, removes, and manages security zones
Assigns interfaces to security zones
Performs asset recovery
Sets the device to FIPS mode
Resets the device to its default settings
Perform debugging (including snoop)
Updates the firmware
Loads configuration files
Clears all active sessions of a specified admin or of all active admins

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 94
4.5.2. Root System Write/Read Users
An administrator with write/read privileges has the same level of privilege as the root
administrator, but they cannot add, modify or remove any other administrative users. The
write/read administrator also have the following privileges:
Creates virtual systems and assigns a virtual system administrator for each one
Monitors any virtual system
Tracks statistics
4.5.3. Root System Read Only Users
The read-only administrator has only viewing privileges using the WebUI, and can only issue
the get and ping CLI commands. The read-only administrator has the following privileges:
Read-only privileges in the root system, using the following four commands: enter,
exit, get, and ping
Read-only privileges in virtual systems
4.5.4. Virtual System Write/Read Users
Virtual system administrators independently manage virtual systems through the CLI or
WebUI. On each virtual system, the virtual system write/read administrator has the following
privileges:
Creates and edits auth, IKE, L2TP, XAuth, and Manual Key users
Creates and edits services
Creates and edits policies
Creates and edits addresses
Creates and edits VPNs
Modifies the virtual system administrator login password
Creates and manages security zones
Adds and removes virtual system read-only administrators
4.5.5. Virtual System Read Only Users
A virtual system read-only administrator has the same set of privileges as a read-only
administrator, but only within a specific virtual system.
4.6. Firewall Logs
A firewalls log files contain a wealth of information and should be the first place you look to
diagnose problems with the firewall or traffic flowing through the firewall. NetScreen firewalls

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 95
provide a series of different log files, each providing information about a different aspect of
the firewall.
4.6.1. Self Log
The self log is responsible for monitoring and recording all packets which terminate at the
NetScreen device itself (such as management and VPN traffic).
Enabling Self Log
To enable self logging, issue the following command:
set firewall log-self
Once self logging has been enabled, the NetScreen firewall will log the traffic in both the self
log and the traffic log.
!
Self log entries typically have a source zone of null and a destination zone
of self.

Viewing the Self Log
To view the sel f log, issue the following command:
get log self
4.6.2. Event Log
The event log monitors and records system level events such as configuration changes and
errors. These events can be categorised into a series of levels:
Emergency. Includes messages such as:
SYN attacks
Tear Drop attacks
Ping of Death attacks
Alert. Includes messages such as:
More than 3 authentication failures
WinNuke attacks
IP Spoofing attacks
Source Route Option attacks
LAND attacks
ICMP floods

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 96
Port scans
Address sweeps
Communication errors with external scanning servers (such as Websense)
Denied policy alarm
Incorrect CA cert used
Bad SPI
Licence key issues and expiration
DHCP range exhausted
Exceeded BGP limits
System upgrade failures
Critical. Includes messages such as:
Bad packet settings
Blocked traffic through Screen options
Issues with High Availability
Low resources
VIP connectivity issues
SSH failures
VPN monitoring status changes
Dynamic Routing errors
Error. Includes messages such as:
SSH negotiation failures
AV Scanning issues
Warning. Includes messages such as:
SMTP issues
Administrative logins/outs/failure (single failure)
SYSLOG status and failures
Local/External Authentication success/failure
Notification. Includes messages such as:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 97
Configuration changes initiated by an administrator.
Failures which do not affect the functioning of the firewall.
Information. Includes messages such as:
general information about system operations.
Debugging. Includes messages such as:
Detailed information used for debugging purposes.
!
It is important to remember what events are logged into which levels as part
of the exam.

Viewing the Event Log
In order to view the event log, issue the command:
get event
Output:
Total event entries = 27
Date Time Module Level Type Description
2001-04-13 15:13:53 system info 00002 Management restriction for
192.168.1.100 subnet 255.255.255.255
has been added
2001-04-13 14:14:51 system crit 00023 VIP server 192.168.1.100 cannot be
contacted.
2001-04-13 14:14:47 system notif 00016 VIP (10.10.10.10:80 HTTP
192.168.1.100) New by NetScreen via
cmd
2001-04-13 14:14:28 system notif 00001 Address VIP(10.10.10.10) for ip
address 10.10.10.10 in zone Global has
been added by NetScreen via cmd
session
It is possible to view specific levels of the event log by issuing the following command:
get event level emergency | alert | critical | error | warning | notification | information |
debugging

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 98
4.6.3. Traffic Log
When logging is enabled for a particular security policy, the log entries are created in the
traffic log. The traffic log notes the following elements for each session:
Date and time that the connection started
Source address and port number
Translated source address and port number
Destination address and port number
Translated destination address and port number
The duration of the session
The service used in the session
!
The traffic log is extremely useful for troubleshooting NAT issues. By viewing
the traffic log for a given policy, you can determine the NAT-src and NAT-dst
applied to traffic after it has traversed the firewall.

Viewing the Traffic Log
As traffic logs relate to specific policies, the command issued must reference a security
policy which has the logging option enabled:
get log traffic policy policy-i d
4.7. Counters
Counters provide statistical information about the firewall including traffic flow information,
number of Screens and interface details such as the number of packet failures. Counters can
be used to monitor a firewall to ensure the traffic is behaving normally, and where to
troubleshoot if there is an issue.
4.7.1. Flow Counters
Flow counters provide information regarding the traffic received by and sent through an
interface or zone. It is the first place to look when determining the amount of bandwidth
traversed through an interface or zone. It is also useful for determining the number of
malicious, abnormal or corrupted packets received by an interface or zone such as attacks
(similar to that of Screen counters) and failed packets (including VLAN and VPN packets).
Obtaining Flow Counters
To obtain the flow counters for all interfaces, issue the command:
get counter flow
To obtain the flow counters for individual interfaces, issue the command:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 99
get counter flow interface interface
Output:
Flow counters for interface ethernet1:
in bytes 11927794 | out bytes 21178341 | tcp proxy 0
in packets 128489 | out packets 136362 | tear drop 0
in vlan 0 | out vlan 0 | in permit 10756457
out permit 5553265 | src route 0 | no g-parent 0
ping of death 0 | no gate sess 0 | address spoof 0
in icmp 21156 | no nat vector 0 | land attack 0
in self 0 | no map 0 | icmp flood 0
in un-auth 0 | no conn 0 | udp flood 0
in unk prot 0 | no dip 0 | winnuke 0
To obtain the flow counters for a specific zone, issue the command:
get counter flow zone zone
Output:
Flow counter on zone Untrust
in bytes 1677192980 | out bytes 44057565 | tcp proxy 0
in packets 23625439 | out packets 177397 | tear drop 0
in vlan 0 | out vlan 0 | in permit 67996670
out permit 43584027 | src route 0 | no g-parent 0
ping of death 0 | no gate sess 0 | address spoof 0
in icmp 14504 | no nat vector 0 | land attack 0
in self 0 | no map 0 | icmp flood 0
in un-auth 0 | no conn 0 | udp flood 0
in unk prot 0 | no dip 0 | winnuke 0
4.7.2. Screen Counters
Screen counters are used to display the number of packets monitored and rejected through
a zones Screen options.
Obtaining Screen Counters
To obtain the Screen counters for a particular zone, issue the command:
get counter screen zone zone

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 100
Output:
Screen counter on zone Untrust
ICMP flood protection 0
UDP flood protection 0
WinNuke attack protection 0
Port scan protection 0
IP sweep protection 0
Teardrop attack protection 0
SYN flood protection 0
SYN Flood(same source) 0
SYN Flood(same destination) 0
IP spoof attack protection 0
Ping of Death attack protection 0
Src Route IP option filtering 0
Land attack protection 0
SYN fragment protection 0
4.7.3. Hardware Counters
Hardware counters display link level statistics for interfaces and zones.
Obtaining Hardware Counters
To obtain hardware counters for a given interface, issue the command:
get counter statistics interface interface
Output:
Hardware counters for interface ethernet1:
in bytes 78801383 | out bytes 21210461 | early frame 6152
in packets 1171854 | out packets 136621 | late frame 6152
in no buffer 0 | out no buffer 0 | re-xmt limit 0
in overrun 0 | out underrun 0 | drop vlan 0
in coll err 0 | out coll err 0 | out cs lost 0
in misc err 0 | out misc err 0 |
in dma err 0 | out bs pak 0 |
in crc err 0 | out discard 0 |

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 101
in align err 0 | out defer 0 |
in short frame 0 | out heartbeat 0 |
To obtain hardware counters for a given zone, issue the command:
get counter statistics zone zone
4.7.4. Policy Counters
Policy counters display bandwidth utilisation information for a given security policy. In order
to obtain counter statistics for a security policy, the count option is required to be
configured for the policy. The policy counters can assist you in determining the bandwidth
management settings (covered later) which may need to be applied to a certain security
policy.
Obtaining Policy Counters
To obtain policy counter statistics for a given security policy, issue the command:
get counter policy policy-id
Output:
PID: 22, Interval: Day, Unit: Mb/Day, End Time: 27 Feb 2005 21:13:06
000-005: 0000000000 0000000000 0000000000 0000000000 0000000000 0000000000
006-010: 0000000000 0000000000 0000000000 0000000000 0000000000
4.8. SYSLOG
As the NetScreen firewall is a true ASIC based appliance, it has no permanent storage
media in which to store log information. If logs need to be permanently retained, it is
recommended that a Syslog server be configured so the firewall can transfer logging
information to it.
Up to four Syslog servers can be configured. The NetScreen device can generate different
Syslog messages at predefined security levels as well as traffic log information. For each
Syslog server, you can specify the following attributes:
Whether the firewall includes traffic log entries, event log entries, or both traffic and
event log entries
Whether to send traffic through a VPN tunnel to the syslog server and - if through a
VPN tunnel - which interface to use as the source interface
The port to which the firewall sends Syslog messages
The security facility, which classifies and sends emergency and alert level messages
to the Syslog host; and the regular facility, which classifies and sends all other
messages for events unrelated to security
Configuring a Syslog Server
To configure a NetScreen firewall to use a Syslog server, issue the following commands:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 102
set syslog config syslog-server-IP port syslog-port
Where syslog-port is the port the Syslog server is listening on.
set syslog config syslog-server-IP log event | traffic | all
set syslog config syslog-server-IP facilities security-facility facility
Where security-facility and facility can be level 0 to level7
!
In Syslog terms, the security facility is used to log critical security events
where the facility is used to log all other events.

set syslog config syslog-server-IP transport protocol
Where protocol can be TCP if Syslog over TCP is desired
set syslog enable
4.9. SNMP
Simple Network Management Protocol (SNMP) provides a means to obtain statistical
information about a NetScreen device as well as receiving notification of certain system
events.
NetScreen firewalls support both SNMP v1 and v2 protocols. By default, the SNMP agent
running on the firewall can generate the following SNMP traps or notifications:
Cold Start Trap: The firewall generates a cold start trap when it becomes operational
after you power it on.
Trap for SNMP Authentication Failure: The SNMP agent in the firewall triggers the
authentication failure trap if someone attempts to connect to it using an incorrect
SNMP community string or if the IP address of the host attempting the connection is
not defined in an SNMP community. (This option is enabled by default.)
Traps for System Alarms: Firewall error conditions and firewall conditions trigger
system alarms. Three NetScreen enterprise traps are defined to cover alarms
related to hardware, security, and software.
Traps for Traffic Alarms: Traffic alarms are triggered when traffic exceeds the alarm
thresholds set in policies.
To configure a NetScreen device for SNMP, you must first create communities, define their
associated hosts, and assign read/write or read-only permissions.
When an SNMP community is created, it is possible to specify whether the community
supports SNMPv1, SNMPv2c, or both SNMP versions, as required by the SNMP
management stations. If an SNMP community supports both SNMP versions, you must
specify a trap version for each community member.
An SNMP read/write community member can change the following variables on the firewall:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 103
sysContact - Contact information for the administrator of the firewall in case the
SNMP administrator needs to contact them. This can be the administrators name, e-
mail address, telephone number, location in an office, or a combination of such
information.
sysLocation - The physical location of the firewall. This can be anything from the
name of a country, city, or building.
sysName - The name that SNMP administrators use for the firewall. By convention,
this is a fully-qualified domain name (FQDN), but it can also be any name that is
meaningful to the SNMP administrators.
snmpEnableAuthenTraps - This enables or disables the SNMP agent on the firewall
to generate a trap whenever someone attempts to contact the SNMP agent with an
incorrect SNMP community name.
ipDefaultTTL - The default value inserted into the time-to-live (TTL) field in the IP
header of datagrams originating from the firewall whenever the transport layer
protocol does not supply a TTL value.
ipForwarding - This indicates whether or not the firewall forwards traffic - other than
that destined for the firewall itself. By default, the firewall indicates that it does not
forward traffic in order to throw-off would be attackers.
The following points must be noted when configuring SNMP for a NetScreen device:
SNMP administrators are grouped in SNMP communities. A NetScreen device can
support up to three communities, with up to eight members in each community.
A community member can be either a single host or a subnet of hosts, depending on
the netmask you use when defining the member. By default, the firewall assigns an
SNMP community member with a 32-bit netmask (255.255.255.255), which defi nes
it as a single host.
If you define an SNMP community member as a subnet, any device on that subnet
can poll the NetScreen device for SNMP MIB information. However, the firewall
device cannot send an SNMP trap to a subnet, only to an individual host.
Each community has either read-only or read-write permission for the MIB II data.
Each community can support SNMPv1, SNMPv2c, or both. If a community supports
both versions of SNMP, you must specify a trap version for each community
member.
You can allow or deny each community from receiving traps.
You can access the MIB II data and traps through any physical interface.
Each system alarm (a system event classified with a severity level of critical, alert, or
emergency) generates a single NetScreen enterprise SNMP trap to each of the
hosts in each community that is set to receive traps.
The firewall sends Cold Start / Link Up / Link Down traps to all hosts in communities
that you set to receive traps.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 104
If you specify trap-on for a community, you also have the option to allow traffic
alarms.
You can send SNMP messages through a route-based or policy-based VPN tunnel.
Configuring SNMP
To define an SNMP community, issue the following commands:
set snmp contact admin-contact
set snmp location physical-local
set snmp auth-trap enable
set snmp community community-name privilege trap-on version version
Where privilege can be read-write or read-only. Where version can be v1, v2c or
any.
set snmp host community-name community-member-IP/32 trap version
Where version can be v1, v2c or any.
In order for SNMP to function, it must be enabled on the relevant interface:
set interface interface manage snmp
4.10. Traffic Alarms
When a NetScreen firewall experiences an abnormal amount of traffic for a given policy, it
could be a sign that a security incident has occurred somewhere on the network. A traffic
alarm can be configured on a security policy to trigger at a given threshold, and send an
alarm to the administrator for investigation.
When an alarm is triggered, an administrator can be notified through the following methods:
Console
Event log
E-mail (up to 2 different email addresses)
SNMP
Syslog
WebTrends
NSM
Configuring Traffic Alarms
To configure a traffic alarm for a given policy, append the following options to the end of a
policy configuration:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 105
alarm number(B/s) | number(K/m)
Where number(b/s) is the threshold in Bytes per second and number(k/m) is the
threshold in Kilobytes per minute.
!
In order for traffic alarms to function, the count option must also be enabled
in the security policy.

Configuring Traffic Alarms using Email
In order to be notified of traffic alarms via email, issue the following commands:
set admin mail alert
set admin mail mail -addr1 email -address
set admin mail mail -addr2 email -address
set admin mail server-name mail-server
set admin mail traffic-log
4.11. Review Questions

1. How many SNMP communities can be configured?
a. 8 communities with 3 members.
b. 8 communities with 8 members.
c. 3 communities with 8 members.
d. 3 communities with 3 members.
2. Which external methods can be used to monitor the status of a NetScreen device? Select
the TWO best answers.
a. SNMP community member.
b. SYSLOG server
c. WebTrends server
d. NSM
3. In what event log does a SYN flood event appear?
a. Alert
b. Critical
c. Emergency

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 106
d. Attack
4. Which command can be used to display an interfaces hardware statistics?
a. get interface interface statistics
b. get counter statistics interface interface
c. get counter interface interface
d. get counter hardware interface interface
5. What is true about manage and manager IPs? Select the TWO best options.
a. Manager IPs are configured on a per-interface basis.
b. Manage IPs are configured on a per-interface basis.
c. Manager IPs are the IP addresses that the firewall uses for management.
d. Manage IPs are the IP addresses that the firewall uses for management.
e. Manage IPs are the IP addresses that can manage the firewall.
6. How can remote management traffic be secured? Select the THREE best options.
a. Restrict which IP addresses can manage the firewall.
b. Enable Screen options.
c. Enable secure management options such as SSH and SSL.
d. Assign a different IP address on the relevant interface for management.
e. Configure an additional administrator.
7. Why would a Read-Only administrator not be able to run debug commands?
a. Only root system users can run debug commands.
b. They first need to exist the Virtual System.
c. Debug first needs to be enabled.
d. Read-only administrators cannot run debug commands regardless.
8. What command is used to view the self log?
a. get self
b. get self log
c. get log self
d. get log

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 107
9. What is the maximum number of SYSLOG servers that can be configured on a
NetScreen firewall?
a. 6
b. 4
c. 5
d. 3
10. What is the maximum number of email addresses which can be configured for alerts?
a. 1
b. 2
c. Unlimited.
d. Unlimited, though, it is only possible to specify a maximum of 2 email addresses.
11. Which of the following would not trigger a default SNMP trap or notification?
a. Power on.
b. Reboot.
c. SNMP Authentication failure.
d. Traffic alarm.
12. Which command could be used to determine the number of failed VLAN packets?
a. Get interface vlan
b. Get event
c. Get counter flow
d. Get counter policy
13. Which of the following is not a valid event log level?
a. alarm
b. critical
c. emergency
d. debugging
14. In which event log would three failed authentication attempts appear?
a. critical
b. warning

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 108
c. alert
d. Notification
15. Which command can be issued to determine the enabled management methods for a
given interface?
a. get interface interface manage
b. get manage interface interface
c. get interface interface management
d. get interface interface
4.11.1. Review Answers

1. How many SNMP communities can be configured?
c. You can configure up to 3 SNMP communities, each with 8 members.
2. Which external methods can be used to monitor the status of a NetScreen device? Select
the TWO best answers.
a, d. A NetScreen firewall can be monitored if SNMP has been configured and if it is
being managed by a NetScreen Security Manager.
3. In what event log does a SYN flood event appear?
c. SYN Floods and other critical attacks are recorded into the emergency event log.
4. Which command can be used to display an interfaces hardware statistics?
b. This command allows you to vi ew the physical statistics for an interface.
5. What is true about manage and manager IPs? Select the TWO best options.
b, d. Manage-IPs are configured per interface and when configured, is the IP address
used to manage the firewall (from that particular interface). A Manager-IP is the global list
of IP addresses that can manage the firewall.
6. How can remote management traffic be secured? Select the THREE best options.
a, c, d. In order to increase the security of remote management, you should restrict which
IP addresses can manage the firewall with Manager-IPs, use secure management
protocols such as SSH and SSL and not use the IP address of the interface.
7. Why would a Read-Only administrator not be able to run debug commands?
d. Administrators with read-only privileges cannot issue debug commands.
8. What command is used to view the self log?
c.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 109
9. What is the maximum number of SYSLOG servers that can be configured on a
NetScreen firewall?
b. The maximum number of SYSLOG servers that can be configured is 4.
10. An administrator wants traffic alarms sent to three different email address. Which of the
following options could enable this to happen?
d. As the maximum number of email addresses configurable on a NetScreen firewall for
the purposes of alarms is two, however, if those addresses are distribution lists, then it is
possible to have the alert sent to a theoreticaly unlimited number of recipients.
11. Which of the following would not trigger a default SNMP trap or notification?
b. The default SNMP traps are cold start, SNMP authentication failure, system events
and traffic alarms.
12. Which command could be used to determine the number of failed VLAN packets?
c. The get counter flow command includes a count for packets with incorrect VLAN tags.
13. Which of the following is not a valid event log level?
a. The valid event log levels are: Emergency, Alert, Critical, Error, Warning, Notification,
Information and Debugging.
14. In which event log would three failed authentication attempts appear?
c. The alert event log is largely responsible for recording certain attacks and multiple
failed authentication attempts.
15. Which command can be issued to determine the enabled management methods for a
given interface?
d. The get interface interface command can displayed the management methods enabled
and disabled for a given interface.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 110
5. Troubleshooting Traffic Flows
Anyone whos ever needed to implement a firewall can testify to the pains associated with
connectivity. Traffic that gets blocked for no reason, traffic that isnt routed somewhere
properly, traffic that is permitted when it shouldnt be the list goes on. Depending on the
platform youre working with, obtaining the information as to where the problem could lie is a
daunting task. Thankfully, NetScreen firewalls provide a set of easy debug and
troubleshooting tools for you to quickly identify where the problem is.
Although a wealth of troubleshooting and debug tools exist on the NetScreen, in this section,
we will predominately be focusing on methods to troubleshoot traffic flows. The two
commands in particular are Snoop and Flow Filter.
5.1. Debugging
Most facets of a NetScreen firewall can be debugged in one way or another (as you may
have seen in previous sections). Debug messages contain useful morsels of information that
can help identify the cause of a given problem.
5.1.1. The Debug Buffer
Sending console messages to the screen can often cause issues and even disconnect the
connecting host (in the instance where there are so many events that it overwhelms the
console). As such, NetScreen firewalls have a debug buffer, otherwise known as the dbuf
which is used to store debug events.
When you enable a particular debug, events relating to that are recorded into the dbuf.
Viewing the dbuf
In order to view the contents of the dbuf, issue the command:
get dbuf stream
Clearing the dbuf
As the dbuf fills, it is often necessary to clear it in order to obtain the newer events you may
wish to achieve. To clear the contents of the dbuf, issue the command:
clear dbuf
Manipulating the dbuf
As the dbuf resides in memory with a dedicated size, the filling of the buffer will result in the
event wrapping where newer events will begin overwriting older events. In order to avoid
this, the size of the dbuf can be increased (or decreased to save memory). To change the
allocated memory amount for the dbuf, issue the command:
set dbuf size size
Where size is between 32 to 4096 Kilobytes of memory.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 111
5.2. Snoop
Snoop is a powerful troubleshooting tool that allows you to view the traffic flow traversing in
and out of a NetScreen firewall. Snoop is most often use to confirm that traffic is indeed
reaching the NetScreen firewall on a certain interface and is leaving the firewall on the
appropriate interface. It can also be used to determine layer 2 issues.
!
Remember that all events, including those generated by Snoop, are recorded
in dbuf.
5.2.1. Activating Snoop
Enabling Snoop
In order to enable Snoop, issue the command:
snoop
Once the command has been issued, you will be prompted to confirm your command.
You can change the amount of information that Snoop will display (either standard or
detailed). To enable detailed Snoop, issue the command:
snoop detail
To change the Snoop mode to standard, issue the command:
snoop detail off
Obtaining Snoop Details
You can view the configuration of Snoop by issuing the following command:
snoop info
Disabling Snoop
Snoop can be disabled in two ways. You can either issue the following command:
snoop off
Or, by pressing the ESC key.
5.2.2. Filtering with Snoop
Filters allow you to only Snoop for given traffic characteristics that are relevant to your
problem. Snoop provides a wealth of filters as well as the ability to combine them together.
!
From ScreenOS 5.0.0 onwards, snoop filter commands require the filter
command to be added. For example, snoop filter ip ip. Snoop questions in
the JNCIS-FWV exam relate to the ScreenOS 4.0.0 use of the command, and
as such, the filter command can be omitted.

Snooping a Host

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 112
Snoop can be configured to monitor traffic only to and from any given host. To Snoop a
single host, apply a filter by issuing the command:
snoop ip ip ip-address
Snooping a Source Host
To be more specific, you can apply a filter which looks for a given source IP address by
issuing the command:
snoop ip src-ip ip-address
Snooping a Destination Host
It is also possible to apply a filter by destination IP address:
snoop ip dst-ip ip-address
Snooping a Port
As with hosts, ports can also be monitored with a bi -directional filter by issuing the
command:
snoop ip port port-number
Snooping a Source Port
A filter by source port can be applied by issuing the command:
snoop ip src-port port-number
Snooping a Destination Port
A filter by destination port can be applied by issuing the command:
snoop ip dst-port port-number
Snooping an Interface
A filter can be added to monitor traffic inbound and outbound for a given interface by issuing
the command:
snoop ip interface interface
Snooping an IP-Protocol
A filter can also be added to just monitor for a specific IP-Protocol type by issuing the
command:
snoop ip i p-proto protocol-number
Manipulating Filters with AND Logic
Snoop provides additional flexibility by allowing you to combine multiple filters together in an
AND like logic. For example, by issuing the two following commands together:
snoop ip dst-ip ip-address

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 113
snoop ip dst-port port-number
Snoop will only capture packets that contain the destination IP address AND destination port
number.
5.2.3. Snoop Output
After Snoop has captured some traffic, the next task is to retrieve the messages from the
dbuf and understand the output.
Understanding the Snoop Output
To obtain the events captured by Snoop, issue the following command:
get dbuf stream
Output:
35455.0: 4(i):0010db1c5921->0010db1b44b4/0800
10.1.10.5->1.1.70.250/1, tlen=128
vhl=45, tos=00, id=49627, frag=0000, ttl=63
In this example, line 1 includes the following information:
The timer 35455.0, indicates the time the packet was received.
The interface information 4(i) indicates the physical interface used and the direction
of the packet. The physical interface can be worked out by applying the formula [n
3] where n is the number displayed by the output. Hence, in this instance 4 3 = 1,
meaning Ethernet1. The character within the brackets indicates the direction, where
(i) implies inbound and (o) implies outbound. In our example, the packet has
arrived (inbound) on interface Ethernet1.
!
In a 5 series NetScreen firewall, there are only two interfaces. Hence, the
trust interface is represented by a 0 and the untrust interface is represented
by a 1.

The line continues by displaying the source and destination MAC addresses
0010db1c5921->0010db1b44b4 as well as the protocol type in use 0800.
Line 2 includes the following information:
The source and destination IP addresses 10.1.10.5->1.1.70.250 as well as the IP
protocol used 1.
The field tlen=128 implies the length of the datagram in bytes.
Line 3 includes the following information:
vhl=45 implies the protocol version and header length. In this example, it is IP
version 4 with a header length of 5 32 bit words.
tos=00 implies the Type of Service.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 114
id=49627 implies the ID of the datagram
frag=0000 details whether the packet has been fragmented, and if so, the fragment
ID.
ttl=62 displays the Time To Live for the packet.
Other types of output can be observed depending on the packet type:
05375.0: 0(i):00b0d080b93e->0010db06eeb0/0800
10.1.10.5->2.2.2.222/6, tlen=48
vhl=45, id=7015, frag=4000, ttl=128
ports 2459->21, seq=3821340563, ack=0, flag=7002/SYN

05375.0: 1(o):0010db06eeb1->ffffffffffff/0806
q 0010db06eeb1/2.2.2.10->2.2.2.222
05375.0: 1(i):0010a4a77630->0010db06eeb1/0806
r 0010a4a77630/2.2.2.222->2.2.2.10
In this example, we see that a TCP packet /6 has arrived on the Trust interface 0(i) from
10.1.10.5 destined to 2.2.2.222 on port 21. We can tell this packet is a SYN packet as the
ACK field is blank ack=0 and the flag is set to SYN /SYN. A SYN/ACK packet would have an
acknowledgement ID as well as the SYN flag set. An ACK would simply have an
acknowledgement ID and no SYN flag.
The example continues on by showing an ARP request q /0806 being broadcasted
ffffffffffff from the MAC address of Untrust interface 0010db06eeb1 for the destination IP
2.2.2.222.
The Untrust interface then receives 1(i) an ARP reply r /0806 containing the MAC address
of the destination 0010a4a77630.
5.3. Flow Filters
Flow Filters provide an extremely detailed account of packets arriving at the firewall and how
they are processed. Unlike Snoop which is typically used to confirm the traversal of traffic,
Flow Filters can be used to determine:
whether NAT has been applied, and if so, which type
the routing lookups and decisions made
policies applied
how the packet was delivered
!
One of the most important things to remember about Flow Filters is that they
ONLY capture incoming traffic, that is, you will never see a packet leaving the
firewall in a Flow Filter capture. As such, the Flow Filter capture will not see
traffic initiated from the firewall itself as it is not regarded as incoming traffic.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 115
traffic initiated from the firewall itself as it is not regarded as incoming traffic.

5.3.1. Using Flow Filters
Enabling Flow Filters
As the name implies, Flow Filters are filters that can be applied on the firewall to monitor the
flows of traffic. In order to enable a flow filter to actively monitor traffic, we need to define two
things: the actual filter and the debug command. To enable the debug for Flow Filters, issue
the following command:
debug flow basic | detail

!
Typically, the basic option provides sufficient information to troubleshoot an
issue. The detail option provides additional information such as internal
processor flows which is normally not required.

Setting a Flow Filter for the Destination Host
In order to capture packets destined for a given destination host, create a flow filter by
issuing the following command:
set ffilter dst-ip ipaddress
Setting a Flow Filter for the Source Host
In order to capture packets from a given source host, create a flow filter by issuing the
following command:
set ffilter src-ip ipaddress
Setting a Flow Filter for the Destination Port
In order to capture packets destined for a given destination port, create a flow filter by
issuing the following command:
set ffilter dst-port port-number
Setting a Flow Filter for the Source Port
In order to capture packets from a given source port, create a flow filter by issuing the
following command:
set ffilter src-port port-number
Setting a Flow Filter for the Protocol Type
In order to capture packets of a given protocol type, create a flow filter by issuing the
following command:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 116
set ffilter ip-proto protocol-number
Viewing Flow Filters
To view configured flow filters, issue the following command:
get ffilter
Output:
Flow filter based on:
id:0 dst ip 1.1.1.1
id:1 src ip 192.168.1.1
Notice that each flow filter has a unique ID.
Removing Flow Filters
To remove a flow filter, issue the following command:
unset ffilter id
Where id is the ID of the flow filter. You can issue the command without an ID in
which cause the flow filter with the lowest ID will be removed first.
!
It is not possible to remove all flow filters at once regardless of the command
issued. Flow filters can only be removed one at a time.

When a flow filter is removed, there is a shift in flow filter IDs. That is, if there are two flow
filters, ID=0 and ID=1, removing the flow filter with ID=0 will then shift the ID of flow filter
ID=1 to ID=0.
Combining Flow Filters
As weve seen, it is possible to create multiple flow filters with each one being assigned a
different ID. When flow filters are created in this way, it represents an OR situation. That is,
the debug packet aspect of the flow filter will capture anything that matches one flow filter,
OR anything that matches another flow filter.
Output:
Flow filter based on:
id:0 dst ip 1.1.1.1
id:1 src ip 192.168.1.1
In this example, we would capture events for anything destined to the IP address of 1.1.1.1
OR anything from the IP address of 192.168.1.1. The two filters are mutually exclusive.
!
This is different from the Snoop command where entering one command after
another implies an AND situation. It is important not to get the two confused.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 117
Combining Flow Filters with AND Logic
Not to be outshined by the Snoop command, it is indeed possible to create a flow filter that
applies AND logic to the capture. However, there are some restrictions to bare in mind. It is
only possible to combine two arguments together into a single flow filter statement. Also,
only certain combinations of filters are allowed to be combined together.
To create a flow filter with AND logic, issue the following command:
set ffilter 1
st
-argument 1
st
-property 2
nd
-argument 2
nd
-property
Observe the following entry as an example:
set ffilter dst-ip 1.1.1.1 dst-port 21
Notice how the flow filter appears in the list.
Output:
Flow filter based on:
id:0 dst ip 1.1.1.1 dst port 21
We can see that instead of being two separate filters with separate IDs, it is entered as a
single filter with a single ID.
Here is a rough guide as to which arguments cant be combined together:
It is not possible to combine the same argument twice (i.e. src-port src-port)
It is not possible to combine a src-ip and dst-ip
If a port/proto filter is used for the first argument, then a port command must also be
used for the second argument (the exception being the dst-port as it cannot be
added to if it is used as the first argument)
5.3.2. Flow Filter Output
The output of a flow filter is often lengthy and usually contains an overwhelming amount of
information. However, if you can learn to understand most of the information provided, it can
greatly assist you in determining exactly where a problem is occurring.
We will take a look at a general output, and then specific examples relating to different
issues.
Understanding Flow Filter Output
Output:
****** 12553.0: <Trust/ethernet1> packet received [60]******
ipid = 29503(733f), @d7806910
packet passed sanity check.
ethernet1:192.168.1.10/1280->194.73.82.242/512,1(8/0)<Root>

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 118
chose interface ethernet1 as incoming nat if.
search route to (192.168.1.10->194.73.82.242) in vr trust-vr for vsd-0/flag-0/ifp-
null
route 194.73.82.242->1.1.1.2, to ethernet3
routed (194.73.82.242, 0.0.0.0) from ethernet1 (ethernet1 in 0) to ethernet3
policy search from zone 2-> zone 1
Permitted by policy 3
choose interface ethernet3 as outgoing phy if
no loop on ifp ethernet3.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 1-559ef00.
Session (id:76) created for first pak 1
route to 1.1.1.2
arp entry found for 1.1.1.2
nsp2 wing prepared, ready
cache mac in the session
flow got session.
flow session id 76
post addr xlation: 1.1.1.1->194.73.82.242.
packet send out to 0010db103041 through ethernet3
Certainly is a lot there. Lets try and break each section down to get an idea of whats
happening.
!
If you havent already, now is about a good time to remember that NetScreen
packet flow from the first section

****** 12553.0: <Trust/ethernet1> packet received [60]******
The first line shows the ingress interface the packet has arrived on and the zone it is bound
to. In this instance, the packet has arrived on Ethernet1 which is bound to the Trust zone.
Note that the timer 12553.0 also exists in flow filter captures.
ipid = 29503(733f), @d7806910
This section displays the ID of the IP packet.
packet passed sanity check.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 119
The Screen options for the ingress zone are then applied to the packet. In this instance,
there were no issues with the packet.
ethernet1:192.168.1.10/1280->194.73.82.242/512,1(8/0)<Root>
Here, we can observe the source IP address, the source port, the attempted destination IP
address, the destination port and the protocol type (1). We can also see which system the
packet arrived from (in this instance, and generally, it is the <Root> system).
chose interface ethernet1 as incoming nat if.
In order to work out which source zone should be referenced for the policy lookup, the
firewall confirms the interface it will use as the egress interface. While it may be blatantly
obvious in this example, it is often less obvious when tunnel interfaces are involved. We can
also see that it refers to the interface as being a NAT interface (nat if). Strangely, despite
all forms of logic, this may not necessarily mean that the interface is in NAT mode. You will
need to observe the later lines relating to NAT to determine what type of NAT is being
applied.
search route to (192.168.1.10->194.73.82.242) in vr trust-vr for vsd-0/flag-0/ifp-
null
The firewall begins to search for the appropriate route to reach the destination IP address in
the virtual router where the ingress interface is bound. It is sometimes necessary to pass the
packet onto another virtual router.
route 194.73.82.242->1.1.1.2, to ethernet3
The firewall has decided that the most appropriate route in this instance is the default
gateway (we can then assume it failed to find any other route apart from the default route).
Ethernet3 is the interface specified in the default route entry.
routed (194.73.82.242, 0.0.0.0) from ethernet1 (ethernet1 in 0) to ethernet3
The firewall confirms the route it will use and the relevant ingress interface and egress
interface it will use.
policy search from zone 2-> zone 1
As the firewall now has the ingress and egress interfaces, it can work out what the source
and destination zones should be in order to perform a policy lookup. The zones are specified
using their zone ID (dont make it easy do they?), and in this instance, it is a policy search
from the Trust zone to the Untrust zone.
Permitted by policy 3
The outcomes over the policy lookup appear here. If the firewall finds a policy, it displays the
action. If the firewall fails to find a policy, it typically uses the implied default policy. In this
instance, the firewall has found a policy (policy ID 3) which matches the traffic with an action
of permit.
choose interface ethernet3 as outgoing phy if
The firewall has decided that it will use the actual physical Ethernet3 interface to send the
traffic out of. Once again, while this is obvious, if the egress interface was instead a tunnel
interface, this information would be more useful as it would indicate the physical interface to
use for a given tunnel interface.
session application type 0, name None, timeout 60sec

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 120
As the traffic is ICMP related in this instance, that firewall does not need to apply any type of
application inspection. If application inspection has been applied in the policy, it will be noted
in this section. A timeout of 60 seconds is applied to the session. Different protocols have
different session times.
service lookup identified service 0.
The firewall then attempts to lookup the service book to determine the specifics of the
service.
Session (id:76) created for first pak 1
As this is the first packet received by the firewall for this session (it must be, otherwise it
wouldnt appear in the flow filter right?), a new session ID is created and assigned. Packets
which match an existing session are typically Fast Processed and as a result, leave scarce
information in the flow filter output.
route to 1.1.1.2
The firewall prepares the packet for routing.
arp entry found for 1.1.1.2
An ARP entry already exists for the destination IP address. If it hadnt, the firewall would
need to perform an ARP request for the destination IP address, or the next-hop gateway IP
address. If for some reason, the destination or gateway cannot be contacted (because it may
be down for example), that information is also presented here.
cache mac in the session
In order to increase processing speeds, the firewall decides to cache the MAC address of
the destination.
post addr xlation: 1.1.1.1->194.73.82.242.
We can now see the NAT applied to the packet. If either NAT-src or NAT-dst has been
applied, we can see how the packet has transformed compared to when it first entered the
firewall. In this instance, the source IP address has changed to that of the egress interface
(1.1.1.1). The destination IP address has remained the same. As such, we can assume that
the NAT applied in this instance was Interface NAT.
packet send out to 0010db103041 through ethernet3
The packet is finally forwarded out to the destination MAC address through the egress
interface.
As you can see, reading flow filter output is almost like reading another language, but there
are some matching patterns that we can keep a lookout for in order to determine the
characteristics of the packet, and the actions performed by the firewall.
Understanding Flow Filter Output and NAT
Determining the how and which NAT was applied to a packet using the flow filter output is
relatively easy once you get the jist of it. Lets take a look at the various circumstances.
In the previous example, we saw that the packet was indeed NATed using Interface NAT.
We determined this by observing the post xlate at the end of the output, noting that the
source IP address has become the egress interface IP (this assumes that you know what the

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 121
IP address of the egress interface is, otherwise, it is relatively easy to workout based on the
IP address information provided in the output).
When a policy based NAT-src is applied, the output is slightly different and includes the
following lines:
Output:
dip id = 2, 192.168.1.10/6600->1.1.1.1/1024
This line appears after the policy lookup. We know that policy based NAT-src has been
applied by the dip statement, and we know it is using the egress interface as opposed to a
DIP pool due to the id = 2. When a DIP pool is used instead of the egress interface, the DIP
ID will be a number above 4. We can also observe what the source IP address will be. This
information will again be provided in the post xlate line.
When a NAT-dst occurs because of a MIP or VIP, the following line will be included:
Output:
hip xlate: 1.1.1.5->192.168.1.20 at ethernet3 (vs. ethernet3)
Here, we can see that there is a MIP or VIP for the IP address 1.1.1.5 which maps to the real
IP address of 192.168.1.20. The MIP/VIP is bound to the Ethernet3 interface.
Remember that hosts which are referred to in a MIP/VIP map have their source IP address
translated to the MIP/VIP address when leaving the firewall through the interface that the
MIP/VIP is configured. In that instance, we can observe the following line in the output:
Output:
found reversed mip/vip 1.1.1.5 for 192.168.1.20 (on ethernet3)
When policy NAT-dst is applied, we can observe the following line in the output:
DST xlate: 1.1.2.10(1024) to 192.168.1.30(1024)
Here we can see the NAT IP address used in the policy 1.1.2.10, mapping to the real IP
address 192.168.1.30.
!
Take the time to remember each of the NAT instances as they frequently
appear on the exam.
5.4. Session Information
Obtaining Session Information
Lastly, we can obtain information about traffic, or more specifically, sessions created by
traffic using the following command:
get session
Output:
alloc 176/max 128000, alloc failed 0, di alloc failed 0
id 45/s**,vsys 0,flag 00000040/0000/00,policy 1,time 6, dip 0

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 122
0(8801):192.168.1.10/4000->192.168.2.10/1024,1,0010db103040,2,vlan 0,tun 0,vsd
0,route 0
6(2800):192.168.1.10/4000<-192.168.2.10/1024,1,000000000000,3,vlan 0,tun 40000001,vsd
0,route 5
The session table provides a wealth of information in a quick snapshot.
The id field, similar to other debug and troubleshooting tools, represents the IP version and
the number of headers. In this example, the IP version is 4 with a header length of 5.
The vsys field determines which vsys the session is applicable (0 represents the Root
system).
policy refers to the policy ID that the session matched. In this example, the session matched
the policy ID of 1.
time refers to the session timeout value in ticks (1 tick = 10 seconds). In this example, the
session is valid for 60 seconds (6 ticks x 10 seconds = 60 seconds).
If policy NAT-src using DIPs has been applied to the traffic, we can determine which DIP
pool was used by reference the dip field. In our example, no policy NAT-src was applied.
The beginning of the session line displays the ingress interface and the session token
number. In this instance, the first line refers to the Ethernet1 interface 0(8801) and the
second line refers to the Ethernet3 interface 6(2800).
!
Yes I know, you were probably thinking that 0 refers to the trust interface and
4 refers to Ethernet1 as per our previous Snoop examples. Just to add some
confusion, the session table and snoop refers to the Ethernet1 interface in a
different way, so 0 does in fact reference Ethernet1 in a session table, but
references the trust interface in a Snoop debug. 0 can also reference the
Trust interface in the session table, it just depends on the model of firewall.

We can then observe the source IP, source port, destination IP and destination IP for the
session.
The next field displays the IP protocol used for the session. In this example, it is IP protocol 1
(ICMP).
The next field displays the MAC address of the next-hop router.
If a NetScreen has been configured with Subinterfaces and VLANs, the VLAN ID of the
packet appears in the vlan field. In this example, the packets have a VLAN ID of 2.
The tun field refers to the VPN tunnel used (if one is used).
The vsd field refers to the VSD group that the interface resides in if the firewall is in an NSRP
cluster.
Lastly, route field shows the route ID that was used to route traffic for the session.
5.5. Review Questions


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 123
1. Which of the following commands can be used to configure a flow filter for a destination
IP address of 1.1.1.1 and a destination port of 23?
a. set ffilter dst-ip 1.1.1.1
set ffilter dst-port 23
b. set ffilter dst-port 23 dst-ip 1.1.1.1
c. set ffilter dst-ip 1.1.1.1 dst-port 23
d. set ffilter dst-port 23
set ffilter dst-ip 23
2. Which command allows you to see the messages stored in the debug buffer?
a. get dbuf stream
b. get dbuf
c. get debug buffer
d. get debuffer
3. Observe the following output:
alloc 176/max 128000, alloc failed 0, di alloc failed 0
id 45/s**,vsys 0,flag 00000040/0000/00,policy 1,time 3, dip 0
5(8801):10.1.1.1/4000->10.1.2.1/80,6,0010db103040,2,vlan 0,tun 0,vsd 0,route 2
7(2800):10.1.1.1/4000<-10.1.2.1/80,6,000000000000,3,vlan 0,tun 40000001,vsd
0,route 3
What can you determine regarding the session? Select the TWO best options.
a. Policy NAT-src is occurring
b. The session is occurring between interfaces Ethernet5 and Ethernet7
c. The session timeout value for this session is 30 seconds.
d. The session timeout value for this session is 3 seconds.
e. The session is occurring between interfaces Ethernet2 and Ethernet4
4. Which commands can be used to deactivate Snoop? Select the TWO best options.
a. snoop disable
b. unset snoop
c. clear snoop
d. Use the Escape character

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 124
e. snoop off
5. What command can be used to clear all configured flow filters?
a. unset ffilter all
b. It is not possible to clear all flow filters
c. unset ffilter
d. clear ffilter
6. Observe the following output:
ipid = 40354(9da2), @c7d3b910
packet passed sanity check.
ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>
chose interface ethernet2 as incoming nat if.
search route to (10.1.1.10->100.100.100.100) in vr trust-vr for vsd-0/flag-
0/ifp-null
route 100.100.100.100->10.10.10.2, to ethernet3
routed (100.100.100.100, 0.0.0.0) from ethernet2 (ethernet2 in 0) to ethernet3
policy search from zone 3-> zone 1
Permitted by policy 10
found reversed mip/vip 10.10.10.10 for 10.1.1.10 (on ethernet3)
hip xlate: 10.1.1.10->10.10.10.10 at ethernet3 (vs. ethernet3)
choose interface ethernet3 as outgoing phy if
no loop on ifp ethernet3.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 201-218e480.
Session (id:1874) created for first pak 201
route to 10.10.10.2
arp entry found for 10.10.10.2
nsp2 wing prepared, ready
cache mac in the session
flow got session.
flow session id 1874
post addr xlation: 10.10.10.10->100.100.100.100.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 125
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
a. The destation service is SSH
b. Policy NAT-src is being used
c. A MIP is configured for 10.10.10.10 to 10.1.1.10
d. The default gateway is 10.10.10.2
e. The packet is from a user defined zone.
7. What command can be used to configure a Snoop filter to monitor bidirectional traffic
flows?
a. set snoop ip ip ipaddress
b. snoop ip ip ipaddress
c. snoop ip dst-ip ipaddress
d. snoop ip ipaddress
8. Observe the following output:
ipid = 40354(9da2), @c7d3b910
packet passed sanity check.
ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>
chose interface ethernet1 as incoming nat if.
search route to (10.1.1.1->20.20.20.20) in vr trust-vr for vsd-0/flag-0/ifp-null
route 20.20.20.20->10.10.10.2, to ethernet3
routed (20.20.20.20, 0.0.0.0) from ethernet1 (ethernet1 in 0) to ethernet3
policy search from zone 2-> zone 1
Permitted by policy 5
choose interface ethernet3 as outgoing phy if
no loop on ifp ethernet3.
session application type 0, name None, timeout 60sec
service lookup identified service 0.
existing vector list 201-218e480.
Session (id:1874) created for first pak 201
route to 10.10.10.2
arp entry found for 10.10.10.2

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 126
nsp2 wing prepared, ready
cache mac in the session
flow got session.
flow session id 1874
post addr xlation: 10.1.1.1->20.20.20.20.
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
a. Interface NAT has been applied
b. The default gateway of the firewall is 10.10.10.2
c. The packet is the first packet of a new session.
d. The destination service is SSL
e. Ethernet1 has been used as the outgoing interface.
9. What command can be used to determine the DIP pool used for a given traffic flow?
a. get dip
b. get event
c. get log policy policy-ID
d. get session
10. Observe the following output:
05375.0: 7(i):00b0d080b93e->0010db06eeb0/0800
1.1.1.100->2.2.2.200/6, tlen=48
vhl=45, id=7015, frag=4000, ttl=128
ports 2459->23, seq=3821340563, ack=1024583351, flag=5010
What can you determine from the output? Select the TWO best answers.
a. The packet is a SYN/ACK packet
b. The traffic is outbound
c. The VLAN tag is 45
d. The interface in use is Ethernet4
e. The packet has been fragmented
11. Which Snoop commands could be used to capture packets from source IP 1.1.1.1 and
source port 2222?

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 127
a. snoop ip src-ip 1.1.1.1 src-port 2222
b. snoop ip ip 1.1.1.1
c. snoop ip src-ip 1.1.1.1
snoop ip src-port 2222
d. snoop ip ip 1.1.1.1
snoop ip dst-port 2222
12. Which of the following commands are invalid?
a. get dbuf stream
b. clear dbuf
c. set dbuf size 8152
d. set dbuf size 1024
13. Which command could you use to enable Snoop?
a. snoop enable
b. snoop start
c. snoop on
d. snoop
14. Which debug command must be issued for flow filter events to appear in the debug
buffer?
a. debug ffilter
b. debug filter
c. debug packet
d. debug packet basic
15. When would you elect to use Snoop over a flow filter?
f. When you wish to monitor incoming and outgoing traffic
g. When you wish to monitor the routing decisions
h. When you wish to monitor the policy used
i. When you wish to monitor the session ID

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 128
5.5.1. Review Answers
1. Which of the following commands can be used to configure a flow filter for a destination
IP address of 1.1.1.1 and a destination port of 23?
c. When using AND logic to combine flow filters, the arguments must be entered on the
same line, otherwise OR logic will apply. The IP address argument must always be
entered first.
2. Which command allows you to see the messages stored in the debug buffer?
a. This is the correct command to view the debug buffer.
3. Observe the following output:
c, e. It is not possible to determine whether NAT is occurring in the session table. The
timeout value assigned to the session is in ticks where 1 tick = 10 seconds. Hence, the
timeout value for this session is 30 seconds ( 3 x 10 ). The interface number corresponds
to [ N 3 ] where N is the number displayed in the session table.
4. Which commands can be used to deactivate Snoop? Select the TWO best options.
d, e. Snoop can be disabled by issuing the command snoop off or by pressing the
Escape key.
5. What command can be used to clear all configured flow filters?
b. It is not possible to remove all flow filters at once.
6. Observe the following output:
ipid = 40354(9da2), @c7d3b910
packet passed sanity check.
ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>
chose interface ethernet2 as incoming nat if.
search route to (10.1.1.10->100.100.100.100) in vr trust-vr for vsd-0/flag-
0/ifp-null
route 100.100.100.100->10.10.10.2, to ethernet3
routed (100.100.100.100, 0.0.0.0) from ethernet2 (ethernet2 in 0) to ethernet3
policy search from zone 3-> zone 1
Permitted by policy 10
found reversed mip/vip 10.10.10.10 for 10.1.1.10 (on ethernet3)
hip xlate: 10.1.1.10->10.10.10.10 at ethernet3 (vs. ethernet3)
choose interface ethernet3 as outgoing phy if
no loop on ifp ethernet3.
session application type 0, name None, timeout 60sec
service lookup identified service 0.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 129
existing vector list 201-218e480.
Session (id:1874) created for first pak 201
route to 10.10.10.2
arp entry found for 10.10.10.2
nsp2 wing prepared, ready
cache mac in the session
flow got session.
flow session id 1874
post addr xlation: 10.10.10.10->100.100.100.100.
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
a, c, d. We can observe in the output that the destination port is 22 (SSH). We know
Policy NAT-src is not being used as there is a MIP configured for the IP address (also
observed by noting the hip xlate which only applies to MIPs and VIPs). In the routing
information, we can see that the output refers to the IP address 10.10.10.2 as the default
gateway. Remember that user defined zones must have an ID greater than 100.
7. What command can be used to configure a Snoop filter to monitor bidirectional traffic
flows?
a. This is the only command which will monitor bidirectional traffic and has the correct
syntax. Specifying the src-ip or dst-ip options limits the traffic monitoring to one way.
8. Observe the following output:
ipid = 40354(9da2), @c7d3b910
packet passed sanity check.
ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>
chose interface ethernet1 as incoming nat if.
search route to (10.1.1.1->20.20.20.20) in vr trust-vr for vsd-0/flag-0/ifp-null
route 20.20.20.20->10.10.10.2, to ethernet3
routed (20.20.20.20, 0.0.0.0) from ethernet1 (ethernet1 in 0) to ethernet3
policy search from zone 2-> zone 1
Permitted by policy 5
choose interface ethernet3 as outgoing phy if
no loop on ifp ethernet3.
session application type 0, name None, timeout 60sec
service lookup identified service 0.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 130
existing vector list 201-218e480.
Session (id:1874) created for first pak 201
route to 10.10.10.2
arp entry found for 10.10.10.2
nsp2 wing prepared, ready
cache mac in the session
flow got session.
flow session id 1874
post addr xlation: 10.1.1.1->20.20.20.20.
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
b, c, e. Based on the output, we can see that no NAT has been performed on the packet
(the post addr xlation is the same as the original). The default gateway from the routing
information is 10.10.10.2 and it is a new packet (otherwise it wouldnt need to create a
new session). The outgoing interface can be noted as Ethernet3.
9. What command can be used to determine the DIP pool used for a given traffic flow?
d. The session table displays the DIP pool assigned to a given traffic session.
10. Observe the following output:
05375.0: 7(i):00b0d080b93e->0010db06eeb0/0800
1.1.1.100->2.2.2.200/6, tlen=48
vhl=45, id=7015, frag=4000, ttl=128
ports 2459->23, seq=3821340563, ack=1024583351, flag=5010
What can you determine from the output? Select the TWO best answers.
d, e. From the output, we can determine that the packet is actually an ACK packet (as it
has an ACK number, but no SYN flag). We can also determine that the traffic is inbound
(i) on the interface Ethernet4 (7 3 = 4). The packet has indeed been fragmented based
on the fragment ID.
11. Which Snoop commands could be used to capture packets from source IP 1.1.1.1 and
source port 2222?
c. Unlike flow filters, Snoop arguments do not need to reside (and in fact, cannot) on the
same line.
12. Which of the following commands are invalid?
c. It is not possible to set a debug buffer larger than 4096 Kbytes.
13. Which command could you use to enable Snoop?

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 131
d. Snoop is simply enabled with the command snoop.
14. Which debug command must be issued for flow filter events to appear in the debug
buffer?
d. In order to debug packets using flow filters, the debug packet basic command must
also be issued.
15. When would you elect to use Snoop over a flow filter?
a. The benefits of using Snoop over flow filters is that it can monitor both incoming and
outgoing traffic. Using flow filters provides more information, but can only be used to
capture incoming packets.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 132
6. Traffic Management
One of the inbuilt (and largely unused) features of a NetScreen firewall is its traffic and
bandwidth management capabilities. As the firewall is often the bottle-neck for a large
network environment, deciding which traffic is more important when going out to the cloud is
almost as important as the security aspect (in fact, availability is a security aspect!).
6.1. Interface Bandwidth
Before we can begin configuring bandwidth management to policies, we must first define the
total available bandwidth for a given interface. There is a fine difference between the total
bandwidth processable by an interface (100Mb, 1Gb) and the available bandwidth
consumable on the line (128Kb ISDN for example). Without specifying the appropriate
bandwidth for an interface, the bandwidth settings we configure for policies may not be
accurate.
!
Appropriate bandwidth refers to the total bandwidth for a given interface path.
For example, if the external interface 100Mb interface is connected to a
router with a 10Mb interface which then connects to the Internet with a 2Mb
frame relay connection, then the total bandwidth for that path is 2Mb.

Configuring Interface Bandwidth
In order to configure the maximum bandwidth for a given interface, issue the following
command:
set interface interface bandwidth total-bw
Where total -bw is the total bandwidth in Kbps.
6.2. Policies and Bandwidth Management
Once interface bandwidth has been configured, we can begin adding bandwidth
management control to our security policies. This is the time to stress that bandwidth
management is a tricky art. It is recommended that you usually take a good period of time
out to baseline the traffic traversing the firewall to understand which applications are critical,
and how much bandwidth they consume. Misconfiguring the bandwidth management
aspects of security policies has been known to cause traffic that is important to be dropped.
!
Just to re-emphasise the point, the firewall does not prevent you from
allocating more bandwidth that what is available for the interface.

Even though security policies are stateful, they are defined as unidirectional (from one
host/network to another host/network). As such, the amount of bandwidth that you allocate to
a policy is reserved for this direction (be it outgoing or incoming). For example, a policy from
host A to host B with a bandwidth allocation of 10Kbps will have 10Kbps allocated for all
traffic from host A to host B and will not reserve any bandwidth for the returning traffic from
host B to host A (if required, that would be configured on another policy for that direction).
Enabling the Count Option

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 133
As discussed in a previous section, the count option allows the NetScreen to retain the
amount of bandwidth that is consumed by traffic flowing through the policy. When configuring
bandwidth management, the count option must be enabled on the policy, otherwise, the
firewall will not be able to calculate the bandwidth consumption, and as a result, fail to apply
the bandwidth management restrictions.
6.2.1. Priority Queuing
Before we begin examining the differences between guaranteed and maximum bandwidth, it
is important to understand how the NetScreen assigns priority between competing security
policies.
Although the priority feature does not relate to guaranteed bandwidth (even though it needs
to be configured at the same time), it is more-so necessary for maximum bandwidth
allocation. This is due to the fact that as soon as bandwidth management is assigned for one
security policy, it is automatically enabled for all other security policies, regardless of whether
they have bandwidth management configurations or not. If a policy does not have bandwidth
management configurations, it is assumed that it has a guaranteed bandwidth of 0, and a
maximum bandwidth of as much as it can have but at the lowest priority. Hence, we need
to ensure that a policy with bandwidth configurations has a priority, even if that priority is also
the default of lowest.
!
Unlimited maximum bandwidth is represented with a -1

The priority levels assignable are:
High priority (0)
2nd priority (1)
3rd priority (2)
4th priority (3)
5th priority (4)
6th priority (5)
7th priority (6)
Low priority (default) (7)
!
Remember when I mentioned inconsistencies in priority methods? This is one
of those examples. As you can see, in this instance, the closer to 0, the
HIGHER the priority. Refamiliarise yourself with the priority numbers for each
configuration aspect so you arent confused during the exam.

Changing the Default Bandwidth Management Settings

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 134
It is possible to deactivate the bandwidth management system wide to avoid the default
assignment of unlimited maximum bandwidth and lowest priority for all policies by issuing the
following command:
set traffic-shaping mode off
It is also possible to set the system wide settings to auto mode. This activates bandwidth
management when there is one or more policy configured with bandwidth management, but
deactivates it when these settings are removed. To set the mode to auto, issue the following
command:
set traffic-shaping mode auto
6.2.2. Guaranteed Bandwidth
When configuring bandwidth management for policies, there are two important factors to
consider. The guaranteed bandwidth, and the maximum bandwidth.
The guaranteed bandwidth is the amount of bandwidth that must be allocated to a security
policy when it is demanded. For example, if the total bandwidth available on an interface is
1Mb, and you assign a guaranteed bandwidth of 512Kb for a given policy, then there is only
512Kb remaining should the policy choose to consume its guaranteed bandwidth.
For high priority traffic, the relevant security policies should all be assigned a guaranteed
bandwidth. There is no priority when it comes to guaranteed bandwidth, as the bandwidth is,
as it is so named, guaranteed.
6.2.3. Maximum Bandwidth
After all guaranteed bandwidth has been allocated, the remaining amount is assigned to the
maximum bandwidth pool, and is allocated on a priority basis. When configuring the
bandwidth management aspects of a policy, it is possible to also specify the maximum
bandwidth. This is the most bandwidth, including (not to be confused with on-top of) the
guaranteed bandwidth that the security policy can have allocated to it.
Lets look at a similar example to the guaranteed bandwidth example, except this time, there
is 640Kb total bandwidth allocated on an interface, and two policies each have a guaranteed
bandwidth of 256Kb and a maximum bandwidth of 128Kb. In this instance, the maximum
bandwidth that can be allocated if both policies are fully utilising their guaranteed bandwidth
is 128Kb. Both policies can then theoretically consume an additional 128Kb of the available
128Kb. But how can 128Kb be allocated between two policies each vying for the same
amount of remaining bandwidth? This is where the priority settings become important. The
remaining maximum bandwidth is assigned first to the policies with the highest priorities.
After the highest level priority policies have been sated, the next priority level is allocated
bandwidth. This continues until there is no remaining bandwidth in the maximum bandwidth
pool (or there are no further policies demanding bandwidth). So, if one policy has the highest
priority, and the other policy has a priority level of 2
nd
, all the remaining bandwidth would be
consumed by the highest priority policy with none remaining for the other policy.
!
When there is more than one policy on the same priority level vyi ng for
maximum bandwidth from the maximum bandwidth pool, the bandwidth is
allocated on a round robin basis.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 135
It is possible for a policy to have a maximum bandwidth setting without a guaranteed
bandwidth setting (or, more precisely, with a guaranteed bandwidth value of 0).
6.2.4. DSCP
Differentiated Services CodePoint (DSCP) marking is an industry standard for tagging traffic
with a certain priority level. While a NetScreen firewall does not tag packets itself, it has the
ability to understand packets tagged with DSCP. In order to understand the DSCP marking,
the firewall maps its 8 priority levels, to that of the first 3 bits of the DiffServ field (or the IP
precedence in the ToS byte) contained within the IP header.
Changing the NetScreen Priority to DSCP Mapping
It is possible to change the mapping of the NetScreen priorities to the DSCP markings by
issuing the following command:
set traffic-shaping ip_precedence number0 number1 number2 number3 number4
number5 number6 number7
Where number0 represents the DSCP marking relating to NetScreen priority 0, and
number1 represents the DSCP marking relating to NetScreen priority 1 and so
forth.
Configuring the Bandwidth Management for a Policy
To configure the bandwidth management settings for a given security policy, construct the
policy like so:
set policy from src-zone to dst-zone src dst service action count traffic gbw
guaranteed-bw priority priority mbw maximum-bw dscp enable | disable
Where guaranteed-bw is the guaranteed bandwidth in Kbps, priority is a value from
0 (highest) to 7 (lowest) and maximum-bw is the maximum bandwidth in Kbps.
!
Through the CLI, it is only possible to configure bandwidth management
settings during the configuration of the initial policy. It is not possible to
append or modify bandwidth management settings to a policy through policy
context once it has been configured. Changing the bandwidth management
features requires the policy to be removed and re-added. It is possible to
modify the bandwidth management settings of the policy through the WebUI.

6.3. Review Questions

1. Which bits of the DSCP marking does the NetScreen firewall us to determine the priority?
a. First 3
b. Last 3
c. 2 to 5

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 136
d. 5 to 8
2. How many priority queues exist on a NetScreen firewall to prioritise traffic?
a. 6
b. 7
c. 8
d. 9
3. Observe the following information:
Total Interface Bandwidth: 10Mb
Policy ID Guaranteed Bandwidth Maximum Bandwidth Priority
1 3 3 2
2 2 5 0
3 3 2 1
What is the amount of bandwidth available for Policy ID 2 after all guaranteed bandwidth
has been allocated (assuming all policies are using it)?
a. 5Mb
b. 2Mb
c. 1Mb
d. 0Mb
4. How is the maximum bandwidth pool assigned when multiple policies have the same
priority?
a. First Come First Serve basis
b. Round Robin
c. DSCP
d. Hierarchy of policy ID
5. What is the default maximum bandwidth and priority assigned to policies that do not have
bandwidth management enabled?
a. Maximum bandwidth of 0 and a priority of 7
b. Maximum bandwidth of 0 and a priority of 0
c. Maximum bandwidth of -1 and a priority of 7
d. Maximum bandwidth of -1 and a priority of 0

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 137
6. What is the maximum bandwidth setting used for in a policy? Select the TWO best
options.
a. It is the bandwidth that can be allocated to a policy on top of the guaranteed
bandwidth
b. It is the total bandwidth that can ever be allocated to a policy
c. It is the bandwidth that can be allocated to a policy after all guaranteed
bandwidth has been allocated
d. It is the dedicated amount of bandwidth allocated to a policy
e. It determines the priority of the policy
7. What should the total bandwidth allocated to an interface be? Select the TWO best
options.
a. Equal to the speed/bandwidth of the interface
b. More than the speed/bandwidth of the interface
c. No more than the total bandwidth available for the path the interface is connected
to
d. Not more than the speed/bandwidth of the interface
e. Entered in Mbps
8. What is the total amount of bandwidth allocated for a policy with only a guaranteed
bandwidth of 10Mb?
a. 10 Mb outbound
b. 10 Mb inbound
c. 5 Mb outbound and 5 Mb inbound
d. 0 as there is no maximum bandwidth configuration
9. What happens when you attempt to allocate more bandwidth to policies than the total
bandwidth configured for the interface?
a. An error will occur preventing you from assigning more bandwidth than what is
available
b. No error will occur and the total bandwidth for the interface will be adjusted to
equal the maximum amount allocated to policies
c. No error will occur and any bandwidth which exceeds the total bandwidth for the
interface will be dropped
d. An error will occur and bandwidth management for all policies will be deactivated
10. What is the total amount of bandwidth that can be allocated to a policy with a guaranteed
bandwidth of 0 and a maximum bandwidth of 3Mb?

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 138
a. 3Mb
b. 0Mb
c. Unlimited
d. The bandwidth settings are not valid as you cannot have a guaranteed bandwidth
of 0
6.3.1. Review Answers

1. Which bits of the DSCP marking does the NetScreen firewall us to determine the priority?
a. The NetScreen uses the first 3 bits of the DSCP mark (or the IP precedence in the ToS
byte) contained within the IP header to determine the priority of a tagged packet.
2. How many priority queues exist on a NetScreen firewall to prioritise traffic?
c. There are 8 priority queues on a NetScreen for the purposes of bandwidth
management where 0 is the highest priority and 7 is the lowest priority.
3. Observe the following information:
Total Interface Bandwidth: 10Mb
Policy ID Guaranteed Bandwidth Maximum Bandwidth Priority
1 3 3 2
2 2 5 0
3 3 2 1
What is the amount of bandwidth available for Policy ID 2 after all guaranteed bandwidth
has been allocated (assuming all policies are using it)?
b. After all the guaranteed bandwidth has been assigned, there is a maximum bandwidth
pool of 2Mb ( 10 - (3 + 2 + 3) = 2 ). As policy ID 2 has the highest priority (the closer the
priority to 0, the higher the priority), its maximum bandwidth is allocated from the pool
first. Even though the maximum bandwidth configuration for the policy is 5Mb, there is
only 2Mb remaining in the pool, and hence, policy ID 2 is assigned 2Mb.
4. How is the maximum bandwidth pool assigned when multiple policies have the same
priority?
b. When multiple policies with the same priority compete for maximum bandwidth, the
bandwidth is assigned on a round robin basis.
5. What is the default maximum bandwidth and priority assigned to policies that do not have
bandwidth management enabled?
c. Once one policy is configured for bandwidth management, all policies default to a
maximum bandwidth of an unlimited amount (-1) and are assigned the lowest priority (7).

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 139
6. What is the maximum bandwidth setting used for in a policy? Select the TWO best
options.
b, c. The maximum bandwidth is the most bandwidth that can ever be assigned to a
policy, and is allocated after all guaranteed bandwidth has first been allocated.
7. What should the total bandwidth allocated to an interface be? Select the TWO best
options.
c, d. The total bandwidth assigned to an interface should be no more than the lowest
bandwidth point along the path that an interface is connected to, and should never be
more than the interface itself.
8. What is the total amount of bandwidth allocated for a policy with only a guarant eed
bandwidth configuration of 10Mb?
a. Bandwidth management flow is only ever applied outbound for a policy.
9. What happens when you attempt to allocate more bandwidth to policies than the total
bandwidth configured for the interface?
c. The NetScreen firewall will not prevent you from allocating more bandwidth than the
total bandwidth configured for the interface. However, when the interface total bandwidth
is exceeded, the firewall will begin dropping traffic.
10. What is the total amount of bandwidth that can be allocated to a policy with a guaranteed
bandwidth of 0 and a maximum bandwidth of 3Mb?
a. The total bandwidth that can be allocated to a policy is the maximum bandwidth,
regardless of what the guaranteed bandwidth is.



Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 140
7. Virtual Systems
NetScreen Systems can be logically partitioned into multiple virtual systems (vsys) in order
to provide multi-tenant services. Each vsys is a unique and logically separate security
domain, complete with its own set of administrators (virtual system administrators). One you
enter a vsys, the configuration commands entered only affect that particular vsys. All
commands are identical to that of the physical firewall.
7.1. Creating Virtual Systems
In vsys terms, the main firewall (that is, the physical firewall) is regarded as the root system
(rootsys).
Virtual systems are only supported on NetScreen firewall Systems (and even then, a licence
is required to enable the functionality). A vsys can only be created by the root administrator
or any other write/read administrator on the root system.
In order to create a fully functional vsys, the administrator must define the vsys object and
then make it functional by configuring its basic properties (such as assigning it interfaces and
the like).
!
Virtual Systems cannot be set to transparent mode regardless of the mode
the root system is in. However, all vsys can be set to Route or NAT mode
even if the root system is in transparent mode.

When a vsys has been defined, it creates three zones for its own use: Trust-vsys, Untrust-
Tun-vsys and Global -vsys. It also shares the root systems Untrust zone and uses it as its
Untrust zone.
Defining a Virtual System
In order for a vsys to be defined it needs to be given a name, assigned a vsys administrator
and have a default virtual router assigned to it that it will bind its zones to. The creation of a
specific vsys administrator is optional as a default one will be created with the vsys name as
the username and password should one not be defined.
When a vsys is defined, it also creates its own virtual router. Normally, the vsys will use this
virtual router to bind all its zones to. However, it is possible to assign a root system virtual
router (provided the virtual router is shared more on that later) for the vsys to bind all its
zones to.
In order to define a virtual system, enter the following commands:
set vsys vsys [ vrouter share vrouter ]
set admin name admin-name
set admin password password
exit
Where [ vrouter share vrouter ] is the optional command to use a shared root system
virtual router instead of a default.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 141
!
Once you enter a vsys context, you leave the root system and control the
vsys instead (similar in a way to entering a policy context). To return to the
root system, you need to issue the command exit.

Changing the Default Virtual Router
It is possible to change the default virtual router of a virtual system, much like on the root
system, by entering the following command within the vsys:
set vrouter vrouter default-vrouter
Entering and Exiting a Virtual System
As a root or write/read admin of the rootsys, you can enter any vsys to administer and
configure it. Once you enter a vsys, all aspects of configuration only affect that particular
vsys. To enter a vsys, enter the following command:
enter vsys vsys
To exit a back to the root system, simply enter the command exit.
!
Where root system administrators enter the vsys from the root system, vsys
administrators logon to their respective Virtual Systems directly.
7.1.1. Administration
This is probably a good time to re-cap the different user privileges as well as explore what
can and cant be done in a vsys.
In relation to Virtual Systems, only the root and write/read administrator from a root system
can:
Create a virtual system and assign physical or logical interfaces to them
Perform the same administration tasks as a Virtual System write/read administrator
A write/read Virtual System administrator can:
Create and edit auth, IKE, L2TP, XAuth, and Manual Key users
Create and edit services (user defined services only)
Create and edit policies
Create and edit addresses
Create and edit VPNs
Modify the virtual system administrator login password
Create and manage security zones
Add and remove virtual system read-only administrators

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 142
!
The write/read Virtual System admin privileges highlight what can be created
within a vsys. While subinterfaces can be created within a vsys, only a root
level write/read administrator who has entered the vsys can create them.

The vsys also inherits all predefined services from the root system.
While a read only virtual system administrator can:
Issue the following two commands: get and ping
7.1.2. Sharing
Each vsys (including the root vsys) is autonomous and segregated from other Virtual
Systems. That is, a vsys can have its own virtual router, security zones and even dedicated
interfaces. However, it is most common that a vsys will inherit some aspects (be it a virtual
router, zone or interface) from the root system. In order for this to occur, that particular
property needs to be shared.
It is possible to set the sharing right on virtual routers and zones. In order for a security zone
to be shared, the virtual router it is bound to must be shared. The settings of an interface
cannot be set to shared, but it will automatically become shared by binding it to a shared
zone.
Part of making a vsys functional is assigning interfaces in order for traffic to be processed.
Interface assignment can either be shared, or dedicated.
Sharing is an important aspect of Virtual Systems as it allows them to utilise features and
functions from the root system. The most common use of sharing is the Untrust zone and
interface bound to it. Regardless of the internal configurations, vsys typically need to share
the same Internet access as the root system. By sharing the Untrust zone and interface, all
vsys can have Internet access through the root system.
!
The untrust-vr, untrust zone and hence any interface bound to the untrust
zone is shared by default. It is not possible for a vsys to share out its own
components.

Sharing a Virtual Router
To change the status of a virtual router to shared, issue the following command:
set vrouter vrouter shared
!
You can make an unshared virtual router shared at any time, but to change a
shared virtual router back to unshared requires all Virtual Systems to first be
deleted.

Sharing a Zone
To change the status of a zone to shared, issue the following command:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 143
set zone zone shared
!
Remember, in order to make a zone shareable, it must be bound to a shared
virtual router.

7.1.3. Exporting and Importing
At times, it may be necessary to segregate a vsys in such a way that sharing could
potentially violate some aspects of security. In this instance, it is possible to dedicate a
physical interface solely for the Virtual Systems use. This can be performed by importing the
interface into the vsys as the root administrator. When interface capacity runs low and the
root system requires the interface back, it can be exported from the vsys back to the rootsys.
Importing an Interface
In order to import an interface into a vsys, you must be logged on as the root administrator,
enter the vsys and issue the import commands for an interface that is not currently in use
and in the null zone. To import the interface, issue the following sequence of commands:
Ensure that there are no configurations on the interface:
unset interface interface ip
Move the interface to the Null zone:
set interface zone null
Enter the vsys and import the interface:
enter vsys vsys
Import the interface and assign it to a zone with and provide it with an IP address:
set interface interface import
set interface interface zone zone
set interface interface ip ipaddress/mask(octet)
Exporting an Interface
In order to export the interface back to the rootsys, you must be logged on as the root
administrator, enter the vsys and move the interface to the null zone after removing its
settings. The interface can then be exported out. To export the interface, issue the following
sequence of commands:
Enter the vsys and import the interface:
enter vsys vsys
Ensure that there are no configurations on the interface:
unset interface interface ip

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 144
Move the interface to the Null zone:
set interface zone null
Export the interface:
unset interface interface import
7.2. Traffic Sorting
The most important thing to understand about Virtual Systems is how traffic is processed,
and how the NetScreen firewall can differentiate traffic to and from one vsys to another vsys
(and to itself the rootsys for that matter).
7.2.1. Self Traffic
Traffic destined to the actual NetScreen firewall (be it rootsys or vsys) is associated to the
correct system by determining which system has ownership over the destination object. The
destination object can be a configured MIP, VIP, VPN tunnel or manage IP address.
For example, if there is a MIP configured on vsys1, when traffic arrives destined for the MIP,
the NetScreen firewall understands that the MIP belongs to vsys1 and processes the traffic
as vsys1 accordingly.
7.2.2. Through Traffic
The NetScreen firewall determines the vsys to use for traffic destined to an IP address
beyond the firewall (known also as through traffic) using two different methods: VLAN-based
traffic classification, and IP-based traffic classification. VLAN-based classification utilises the
VLAN tagging method and Subinterfaces dedicated to vsys on those VLANs to determine
the vsys that should process the traffic. On NetScreen firewalls where VLANs cannot be
used, the IP-based classification method examines the source and/or destination IP address
to determine which network range the traffic belongs to, and as such, which vsys has been
configured to handle that network range.
The process of determining the Virtual System to process the traffic can be outline in three
steps:
1. Ingress Interface/Source IP Traffic Classification
The NetScreen device checks if the ingress interface is a dedicated interface or a shared
interface.
1. If the ingress interface is dedicated to a vsys (v-i, for example), the firewall associates
the traffic with the Virtual System to which the interface is dedicated.
2. If the ingress interface is a shared interface, the firewall uses IP-based classification to
check if the source IP address is associated with a particular vsys.
If the source IP address is not associated with a particular vsys, ingress IP-based
classification fails.
If the source IP address is associated with a particular vsys, ingress IP classification
succeeds.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 145
2. Egress Interface/Destination IP Traffic Classification
The NetScreen device then checks if the egress interface is shared or dedicated.
1. If the egress interface is dedicated to a vsys (v-e, for example), the firewall associates
the traffic with the system to which the interface is dedicated.
2. If the egress interface is a shared interface, the firewall uses IP-based classification to
check if the destination IP address is associated with a particular vsys.
If the destination IP address is not associated with a particular vsys, egress IP
classification fails.
If the destination IP address is associated with a particular vsys, egress IP
classification succeeds.
3. vsys Traffic Assignment
Based on the outcome of the ingress interface/source IP (I/S) and egress
interface/destination IP (E/D) traffic classifications, the firewall determines the vsys to which
traffic belongs.
If I/S traffic classification succeeds, but E/D traffic classification fails, the firewall
uses the policy set and route table for the vsys associated with the ingress interface
or source IP address (a vsys named v-i, for example).
I/S traffic classification is particularly useful when permitting outbound traffic from a
vsys to a public network such as the Internet.
If E/D traffic classification succeeds, but I/S traffic classification fails, the firewall
uses the policy set and route table for the vsys associated with the egress interface
or destination IP address (a vsys named v-e, for example).
E/D traffic classification is particularly useful when permitting inbound traffic to one
or more servers in a vsys from a public network such as the Internet.
If both classification attempts succeed and the associated virtual systems are the
same, the firewall uses the policy set and route table for that vsys.
You can use both I/S and E/D IP traffic classification to permit traffic from specific
addresses in one zone to specific addresses in another zone of the same vsys.
If both classification attempts succeed, the associated virtual systems are different,
and the interfaces are bound to the same shared security zone, the firewall first uses
the policy set and route table for the I/S vsys, and then uses the policy set and route
table for the E/D vsys.
NetScreen supports intrazone intervsys traffic when the traffic occurs in the same
shared zone. The NetScreen device first applies the v-i policy set and route table,
loops the traffic back on the Untrust interface, and then applies the v-e policy set
and route table. Such intrazone traffic might be common if a single company uses
one shared internal zone with different virtual systems for different internal
departments and wants to allow traffic between the different departments.
If both classification attempts succeed, the associated virtual systems are different,
and the interfaces are bound to different shared security zones, the firewall drops
the packet.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 146
NetScreens do not support interzone intervsys traffic between different shared
security zones.
If both classification attempts succeed, the associated virtual systems are different,
and the ingress and egress interfaces are bound to zones dedicated to different
virtual systems, the NetScreen device first applies the v-i policy set and route table.
It then loops the traffic back on the Untrust interface and applies the v-e policy set
and route table.
NetScreen supports interzone intervsys traffic between dedicated security zones.
If both classification attempts fail, the firewall drops the packet.
!
Pay particular attention to which vsys the firewall determines should process
the traffic, and when it determines to drop the traffic. Difficult questions
usually arise in the exam in regards to this topic.

7.2.3. VLAN-based Classification
With the VLAN-based traffic classification, a firewall uses VLAN tagging to direct traffic to
various subinterfaces bound to different systems. By default, a vsys has two security zones -
a shared Untrust zone and its own Trust-vsys zone. Both of these zones (and any other
custom defined vsys zones) can have subinterfaces bound to them so the firewall can more
easily determine which vsys should process the traffic.
VLAN-based classification has numerous advantages including ease of administration and
the ability for different Virtual Systems to have overlapping networks as the association of
vsys to traffic is performed using the VLAN tag and not by the source and/or destination IP
address. However, overlapping networks cannot be configured within the same vsys
between subinterfaces.
Defining a vsys Subinterface
To define a subinterface for a vsys, you must enter the vsys as root administrator or a
write/read administrator from the root system and issue the following commands:
Enter the vsys and import the interface:
enter vsys vsys
Create the subinterface, assign it to a zone and configure an IP address:
set interface interface.subif-id zone zone
Where interface is the physical interface, subif-id is the subinterface ID for the new
subinterface and zone is the vsys zone that the subinterface will be assigned to.
set interface interface.subif-id ip ipaddress/mask(octet) tag vlan-i d
Where vlan-id is the VLAN the subinterface will be associated with.
Optionally, change the interface to route mode:
set interface interface.subif-id ip route

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 147
!
By default, all subinterfaces created are in NAT mode, and as such, it is not
necessary to configure the mode for the subinterface unless you want it to be
in route mode.
7.2.4. IP-based Classification
IP-based traffic classification allows you to sort traffic to Virtual Systems without using a
VLAN environment. Instead of VLAN tags, the firewall uses IP addresses to sort traffic,
associating a subnet or range of IP addresses with a particular vsys (including the rootsys).
When using IP-based classification, all Virtual Systems are generally configured to:
Use the untrust-vr and a virtual router specific to the vsys
Use the Untrust zone and a zone specific to the vsys (the default Trust-vsys or
another vsys defined zone)
Use an Untrust zone interface and an interface bound to a zone specific to the vsys
Because IP-based traffic classification requires the use of a shared security zone, Virtual
Systems cannot use overlapping internal IP addresses, as is possible with VLAN-based
traffic classification. Also, when Virtual Systems (including the root system) share the same
interface, the operational mode for that interface must be either NAT or Route mode. It is not
possible to mix NAT and Route modes for different Virtual Systems. In this regard, the
addressing scheme of an IP-based approach is not as flexible as that allowed by the more
commonly used VLAN-based approach.
The other thing to consider is sharing virtual routers, security zones, and interfaces is
inherently less secure than dedicating an internal virtual router, internal security zone, and
internal and external interfaces to each vsys. When all Virtual Systems share the same
interfaces, it is possible for a vsys admin in one vsys to use the snoop command to gather
information about the traffic activities of another vsys. Also, because IP spoofing is possible
on the internal side, Juniper Networks recommends that you disable the IP spoofing
SCREEN option on the shared internal interface.
!
Typically, IP-based classification is used for the Internet access interface. It is
possible to combine VLAN-based classification with IP-based classification
for different interfaces. This allows for eas y administration on interfaces that
all Virtual Systems will share and use, but enhanced security for networks
and interfaces that will be used exclusively by a vsys.

Enabling IP-based Classification
Before a shared interface can process traffic using IP-based classification, it needs to be
configured in the associated shared zone by issuing the following command:
For an entire network:
set zone zone ip-classification net ipaddress/mask(octet) root | vsys vsys
Or, for a range of IP addresses:
set zone zone ip-classification range iprange_start -iprange_end root | vsys vsys

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 148
IP-based classification then needs to be enabled on the zone by issuing the following
command:
set zone zone ip-classification
7.3. InterVSYS Communication
Even though each vsys is a separated logical entity, it is possible to pass traffic between
different vsys and between the rootsys.
7.3.1. Routing
NetScreen Systems that support Virtual Systems have a single global routing table which is
visible by the rootsys and all other vsys. This way, the firewall can determine where traffic
has originated from, where it needs to go and which vsys needs to process it.
However, each vsys also has its own routing table that it uses for routing traffic between its
own zones and interfaces. Routes that are only required for the functioning of the vsys are
entered into this routing table and may not need to be included in the global routing table.
A vsys interface in NAT mode will not import any of its routes into the global route table as it
can cause routing issues (and potentially security issues). At the same time, vsys interfaces
in route mode will always import all their routing information to the global routing table as it is
presumed that those routes need to be visible by other Virtual Systems in order to
successfully route traffic to that vsys.
As we mentioned earlier, overlapping subnets between different vsys are only possible if the
relevant vsys interfaces are in NAT mode and using VLAN-based classification.
7.3.2. Policies
A Virtual System is still a firewall unto itself, and as such, traffic passing in and out of the
vsys still needs to be permitted by security policies. As we observed in the traffic flow
section, vsys can pass traffic between each other, (and at times needing to loop this traffic
through to the untrust interface) providing that both vsys allow the traffic to go out, and both
of them allow the traffic to come in.
7.4. Review Questions

1. Which command needs to be issued to enable IP-based classification?
a. set interface interface ip-classification
b. set zone zone ip-classification
c. set ip-classification enable
d. set interface interface ip-classification enable
2. When attempting to export a physical interface from a vsys back to the rootsys, the action
is not permitted. What could be the cause of the problem?

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 149
a. The interface is not in a shared zone
b. You cannot export an interface once it has been imported to a vsys
c. The interface is not in the null zone
d. The command is being attempted by a root system administrator
3. Which of the following cannot be created in a virtual system with a Virtual System
write/read administrator? Select the TWO best options.
a. Subinterface
b. Security policy
c. VPN
d. Virtual Router
e. Security zone
4. What would be the outcome of traffic if both ingress and egress IP-classification matched
but the interfaces were bound to different shared security zones?
a. The vsys associated with the ingress interface would process the traffic
b. The vsys associated with the egress interface would process the traffic
c. The root system would process the traffic
d. The traffic would be dropped
5. Which of the following statements is NOT true? Select the TWO best answers.
a. All Virtual Systems share a global routing table
b. All vsys subinterfaces are in Route mode by default
c. Each virtual system has its own routing table
d. A virtual system cannot be configured to use both IP-based and VLAN based
classification at the same time
e. VLAN-based classification is more secure than IP-based classification
6. What is required to configure a Subinterface for a vsys? Select the THREE best options.
a. Interface needs to be shared
b. A root level administrator needs to enter the vsys
c. The Subinterface needs to be created in the vsys
d. A Subinterface from the root system needs to be imported into the vsys
e. The subinterface needs to be assigned a VLAN tag

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 150
7. How many administrators would be required to enable routing between six different vsys
in route mode?
a. Just the root system administrator
b. The root system administrator and all six vsys administrators
c. Just the six vsys administrators
d. No administrators
8. Which of the following can a Virtual System read only administrator debug?
e. Just the vsys they belong to
f. Just the root vsys
g. They cannot debug any system
h. Both the root vsys and the vsys they belong to
9. What is the best definition for the term through traffic?
a. It is traffic that bypasses the firewall
b. It is the traffic destined to an IP address beyond the NetScreen either incoming
or outgoing
c. It is traffic that goes through the root system to another virtual system
d. It is the traffic that goes through a virtual system and through the root system
10. When defining a vsys, which virtual router are all zones bound to by default?
a. A virtual router created by and assigned to the vsys
b. The untrust virtual router
c. A virtual router that must be defined
d. The trust virtual router
7.4.1. Review Answers

1. Which command needs to be issued to enable IP-based classification?
b. IP-based classification must be enabled on the shared zone that the interface is bound
to.
2. When attempting to export a physical interface from a vsys back to the rootsys, the action
is not permitted. What could be the cause of the problem?
c. In order to import or export an interface, it must contain no configuration settings and
be bound to the null zone.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 151
3. Which of the following cannot be created in a virtual system with a Virtual System
write/read admi nistrator? Select the TWO best options.
a, d. Virtual System write/read administrators can manage all aspects of a vsys but
cannot create subinterfaces. Subinterfaces can only be created by a root administrator
entering the vsys. When a vsys is created, a default virtual router can be created for the
vsys. It is not possible to configure any additional virtual routers for the vsys.
4. What would be the outcome of traffic if both ingress and egress IP-classification matched
but the interfaces were bound to different shared security zones?
d. NetScreen firewalls do not support intervsys communication for different shared
security zones.
5. Which of the following statements is NOT true? Select the TWO best answers.
b, d. All Subinterfaces created in a vsys are in NAT mode by default. It is possible, and in
fact, quite common to configure two interfaces of a vsys with one in IP-based
classification (shared) and the other in VLAN-based classification mode.
6. What is required to configure a Subinterface for a vsys? Select the THREE best options.
b, c, d. In order to configure a subinterface for a vsys, a root administrator or root level
write/read administrator needs to enter the vsys, create the subinterface and assign it a
VLAN tag.
7. How many administrators would be required to enable routing between six different vsys
in route mode?
a. No administrators are required to configure routing between Virtual Systems in route
mode as the routes are added into the global routing table automatically.
8. Which of the following can a Virtual System read only administrator debug?
c. A read only administrator, regardless of the system, cannot issue debug commands.
9. What is the best definition of the term through traffic?
b. Through traffic is traffic which needs to traverse through a NetScreen firewall to a
destination behind it (either incoming or outgoing).
10. When defining a vsys, which virtual router are all zones bound to by default?
a. By default and unless otherwise specified, a virtual router with the convention vsys-vr
is created. All default vsys security zones are bound to this virtual router.


Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 152
8. NSRP
The firewall is regarded as a critical point in the network as all traffic coming into or out of the
protected network must travel through it. Environments which only have a single firewall can
have a single point of failure issue, where the failure of the firewall will stop critical
communication. To alleviate this issue, the NetScreen Redundancy Protocol enables two or
more NetScreen firewalls to be clustered together in order to provi de failover. This ensures
that the failure of a single firewall causes little to no loss of traffic.
8.1. Clustering
Clustering is the act of taking two or more NetScreen firewalls, cabling them in a fault
tolerant environment and enabling NSRP in either active/passive or active/active mode.
Once a cluster has been formed, the configuration of all members of the cluster are
synchronised, and all future commands issued on one cluster member also propagate to
other cluster members. The exception is the following properties:
Cluster ID number
User account information
Interface monitoring
Manage IP addresses
Bandwidth management configurations
IP tracking commands
Console settings
Hostnames
SNMP settings
Virtual router settings
NetScreen Systems have dedicated physical High Availability (HA) interfaces for the
purposes of clustering. For devices which do not have a dedicated HA interface, it is possible
to take any physical interface and assign it to the HA zone for the purposes of clustering.
Once two devices are connected together using their HA interfaces, they can be clustered
together and monitor the status of each other.
As another layer of redundancy, it is possible to configure a secondary path for cluster status
traffic to communicate through in the instance that the HA connection between the two
firewalls becomes inactive.
Assigning a firewall to a Cluster
NetScreen firewalls in a cluster must share the same cluster ID (which can be a number
between 1 and 7). To configure a firewall with a cluster ID, issue the following command:
set nsrp cluster id cluster-id

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 153
Assigning a Name to a Cluster
As each device has its own hostname (which is not synchronised or propagated), a failover
from one firewall to the other can cause issues with SNMP and digital certificate validity. As
a result, it is important to assign a name to the cluster which will be used regardless of which
member of the cluster is handling the traffic. To configure a cluster name, issue the following
command:
set nsrp cluster name clustername
8.2. VSD Groups
When a firewall is made a member of a cluster, it automatically becomes a member of the
Virtual Security Device (VSD) group 0. VSD group 0 is the default cluster group for all
NetScreen clusters and represents the single group entity of both physical firewalls.
In a VSD group, one firewall is always the master for the group while the other firewall acts
as a backup. When the master fails, the backup firewall will take over as the master for the
group. This is effectively how the failover in a cluster occurs.
8.2.1. VSIs
All security interfaces which were configured on a firewall before it became a cluster member
convert to Virtual Security Interfaces (VSIs) for the VSD group. When a local interface
becomes a VSI, it is an interface member in the cluster that can be failed over onto another
cluster member, and can be monitored to determine whether it has failed (in order to initiate
a potential failover).
Removing a VSI
It is possible that you may not want an automatically converted VSI to be part of the VSD
group. However, once an interface becomes a VSI for group 0, it cannot be made a local
interface again. The recommended steps for removing a VSI is to remove the VSD group 0
and create a new VSD group. Interfaces are not automatically converted to VSIs for that
group. As a result, you can selectively choose which interfaces you would like to make VSIs.
Static Routes
By default, the routing table only includes routes to the local network of all interfaces which
become VSIs. For networks beyond the VSIs local network, a static route must be added
which refers to the relevant VSI.
8.2.2. Priorities
As with anything involving more than a single NetScreen firewall, the members of a VSD
group have different priorities. The default priority assigned to a VSD group member is 100.
The closer the number to 0, the higher the priority of the group member. Generally, the
master will always have the highest priority, and hence, if it fails, the next member highest
priority (the next priority closest to 0) will become master for the cluster.
In the instance that two group members have the same level of priority, the one with the
lowest MAC address is chosen as the higher priority.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 154
8.2.3. Preempt Option
The preempt option allows a group member with a higher priority to resume as the master
once if has recovered from a failure (or, if it is a new group member and another master
already exists). Without the preempt option enabled, a backup device which has become
master can retain that status when the former master becomes active again, even if it has a
lower priority.
Enabling the Preempt Option
On the device that has the highest priority, issue the following command:
set nsrp vsd-group id vsdgroup-id preempt
The hold down timer is an option of preempt as it delays the preempt failover for a given
period of time. It wouldnt be a healthy a network environment if a high priority master goes
down, all devices switch to the backup, only to switch back to the master when it becomes
active again in a minute. To configure a hold down timer, issue the following command:
set nsrp vsd-group id vsdgroup-id preempt hold-down number
Where number is a value from 0 to 600 seconds.
8.2.4. States
Just as with priorities, VSD group members can also be in different states. There are six
states in total:
Master The state of a VSD group member that processes traffic sent to the VSI.
Primary Backup The state of a VSD group member that becomes the master
should the current master step down. The election process uses device priorities to
determine which member to promote. Note that when electing a new master, an
RTO peer has precedence over any other VSD group member, even if that member
has a better priority rating.
Backup The state of a VSD group member that monitors the status of the primary
backup and elects one of the backup devices to primary backup if the current one
steps down.
Initial The transient state of a VSD group member while it joins a VSD group,
either when the device boots up or when it is added to the group using the relevant
command.
Ineligible The state that an administrator purposefully assigns to a VSD group
member so that it cannot participate in the election process.
Inoperable The state of a VSD group member after a system check determines
that the device has an internal problem (such as no processing boards) or a network
connection problem (such as when an interface link fails).
You can determine the state of a device by observing the HA LED. The meanings of the
various colours - dark, green, yellow, red - are as follows:
Dark: The device is not enabled for NSRP.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 155
Green: The device is enabled for NSRP; it is the master in one or more VSD groups;
and it is not in inoperable mode.
Yellow: The device is enabled for NSRP; it is not the master in any VSD group; and
it is not in inoperable mode.
Red: The device is enabled for NSRP, but it is currently in inoperable mode.
Changing the Initial State Hold-down Timer
It is possible to specify how long a VSD group member stays in the initial state (the initial
state hold-down timer). The default (and minimum) setting is 5. To determine the initial state
hold-down time, multiply the init-hold value by the VSD heartbeat-interval (init-hold x hb-
interval = initial state hold-down time). For example, if the init-hold is 5 and the hb-interval is
1000 milliseconds, then the initial state hold-down time is 5,000 milliseconds, or 5 seconds
(5 x 1000 = 5000). To change the initial state hold-down timer value, issue the following
command:
set nsrp vsd-group id vsdgroup-id init-hold number
!
If you reduce the VSD heartbeat interval, you should increase the init-hold
value.

Setting a Group Member to Ineligible State
To change the state of a group member to ineligible, issue the following command:
set nsrp vsd-group id id_num mode ineligible
8.2.5. Heartbeat Messages
Every VSD group member, regardless of its state, communicates with its group members by
sending a heartbeat message every second. These messages allow every member to know
the current state of every other member. The heartbeat message includes the following
information:
Unit ID of the device
VSD group ID
VSD group member status (master, primary backup, or backup)
Device priority
RTO peer information
Configuring the Heartbeat Interval
The interval for sending VSD heartbeats is configurable and applies globally to all VSD
groups. To configure the heartbeat interval, issue the following command:
set nsrp vsd-group hb-interval number
Where number can be 200, 600, 800, or 1000 milliseconds (1000 ms is the default).

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 156
Configuring the Heartbeat Threshold
You can also configure the lost heartbeat threshold that is used to determine when a VSD
group member is considered as missing. In order to configure the heartbeat threshold, issue
the follow command:
set nsrp vsd hb-threshold number
Where number is the number of heartbeats before a device is deemed as missing
(the default is 3).
8.3. Active/Passive
When a new cluster is created and all devices are added to VSD group 0, a master (the
device with the highest priority typically) is elected from the group. If the master fails, the
backup device becomes active and changes to master state. This type of cluster
configuration is known as active/passive.
NetScreen firewalls in layer 3 mode (NAT or Route) as well as layer 2 (Transparent) mode
can be configured for active/passive failover.
Active/passive has some distinct advantages over an active/active configuration. Namely, it
is far easier to configure and manage and simplifies the deployment of fault tolerant network.
!
When the master of a cluster fails and the backup becomes active and the
new master, it sends a gratuitous ARP out of all its interfaces to nearby
networking devices to inform them that it is active (on a more technical level,
it forces all connected networking devices to refresh their ARP tables to point
relevant IP address to the MAC address of the now, new master firewall).

Configuring Active/Passive Failover
To configure active/passive failover for two NetScreen firewalls, issue the following
sequence of commands on both firewalls:
Assign the firewall to a particul ar cluster:
set nsrp cluster id cluster-id
Optionally, provide authentication and encryption for cluster status traffic (such as
heartbeats):
set nsrp auth password clusterpassword
set nsrp encrypt password encryptpassword
Assign the cluster a name to avoi d issues with digital certificates and SNMP
set nsrp cluster name clustername
Select the interfaces that the cluster will monitor. In the instance that one of the
interfaces becomes inactive on the master, the backup with become active:
set nsrp monitor interface interface

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 157
Optionally, you can configure a secondary path for the cluster status traffic in the
instance that the dedicated HA connection between the two cluster member fails.
set nsrp secondary-path interface
It is also possible to configure the number of gratuitous ARPs sent out should the
cluster member become the new master:
set nsrp arp arpnumber
8.4. Synchronisation
In order for two clustered firewalls to truly act as one logical entity, the configurations, files
and state of traffic must always be synchronised. When both firewalls are synchronised, it is
possible to have a seamless failover from one firewall to the other without the loss of traffic.
8.4.1. Synchronising Configurations
Having synchronised configurations is not only essential from a failover perspective (as the
failover device should have the same policies and settings as the master firewall, otherwise
packet loss could be experienced), but is equally as important from an administrative
perspective. The last thing that you would want to do is configure policies on both members
of a cluster.
However, if changes made on one firewall when the one reboots (or if all dedicated and
secondary HA links fail), it is possible that a configuration can become unsynchronised.
Checking for Synchronisation
You can discover if one firewalls configuration is out of sync with the other by issuing the
following command:
exec nsrp sync global -config check-sum
The output from the command shows whether the configurations of both firewalls
are in or out of sync and provides the checksum for both.
Resynchronising Configurations
If the configurations do become out of sync, it is possible to issue the following commands to
resynchronise them:
To resync without a reboot:
exec nsrp sync global -config run
Or, to resync the cluster in a way that requires a reboot:
exec nsrp sync global -config save
!
Ensure that when you are attempting to resynchronise the configurations
from a master to a target, that you issue the unset all command first to clear
all previous configurations. Otherwise, the resync may cause some duplicate
entries, which in turn can cause issues during the bootup process.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 158
8.4.2. Synchronising Files
Synchronising Files
If you need to synchronise files, issue the following command on the target firewall:
To synchronise a single file:
exec nsrp sync file name file-name from peer
To synchronise all files:
exec nsrp sync file from peer
8.4.3. Run-Time Objects
Run-time objects (RTOs) are code objects created dynamically in memory during normal
operation. Some examples of RTOs are session table entries, ARP cache entries, DHCP
leases, and IPSec security associations (SAs). In the event of a failover, it is critical that the
current RTOs be maintained by the new master to avoid service interruption. To accomplish
this, RTOs are backed up by the members of an NSRP cluster. Working together, each
member backs up the RTOs from the other, which allows RTOs to be maintained should the
master of either VSD group in an active/active HA scheme step down.
By default, NSRP cluster members do not synchronise RTOs. Before enabling RTO
synchronisation, you must first synchronise the configurations between the cluster members.
Unless the configurations on both members in the cluster are identical, RTO synchronisation
might fail.
The procedure for two NSRP cluster members to initiate their RTO mirror relationship
develops through two operational states - set and active. The devices progress through
these states as follows:
1. After you add the first device to a group, its state is set. In the set state, the device waits
for its peer to join the group. As the receiver of RTOs, it periodically transmits an r-ready
message (receiver-ready), announcing its own availability. As the sender of RTOs, it waits
until it gets an r-ready message from a device with the same cluster ID.
2. After you add the peer and the two devices are correctly cabled for HA, then the following
occurs:
a. The receiver sends an r-ready message.
b. The sender gets the r-ready message, and immediately sends a group-active
message to inform its peer that its state is now active.
c. The receiver then changes its state to active as well.
Enabling RTO Synchronisation
To enable RTO synchronisation, issue the following command:
set nsrp rto-mirror sync
Manually Resynchronising RTOs

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 159
When a firewall has RTO synchronisation enabled, it will automatically resync after a reboot.
However, if RTO synchronisation is disabled on a firewall, then renabled, an RTO
synchronisation must be performed manually. To manually resync RTOs, issue the following
command:
exec nsrp sync rto all
It is also possible to resync specific RTO components by issue the specific command:
exec nsrp sync rto arp | auth-table | dhcp | dns | l2tp | phase1-sa | pki | rm | session |
vpn
Defining RTO Heartbeats
In addition to passing RTOs from sender to receiver, both firewalls send RTO heartbeats at
user-defined intervals to communicate their operational status. To define the RTO heartbeat
interval, issue the following command:
set nsrp rto-mirror hb-interval number
To define the number of heartbeats required to deem a peer as down, changing its state
from active to set, issue the following command:
set nsrp rto-mirror hb-threshold number
Disable RTO Synchronisation
To disable RTO synchronisation from the device acting as the sender in an NSRP cluster,
issue the following command:
set nsrp rto-mirror session off
!
Disable RTO synchronisation on a particular firewall stops it from sending
RTO synchronisation, but does not stop the other peer from sending it RTO
sync information.

8.4.4. Synchronising Time
It is also possible to use NSRP to synchronise time between cluster members. However, if
NTP for each firewall is configured as well as NSRP time synchronisation, it is possible for
the time to become unsynchronised.
Disable NSRP Time Synchronisation
As NSRP time synchronisation occurs at the second level, but NTP occurs at the sub-
second level, it is recommended that you disable the NSRP time synchronisation and allow
each host to synchronise its time using NTP as it will be more accurate. To disable the
NSRP time synchronisation, issue the following command:
set ntp no-ha-sync

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 160
8.5. HA Interfaces
NetScreen Systems have dedicated HA interfaces for the purposes of connecting two
firewalls together in a cluster. As Appliances dont have dedicated HA interfaces, it is
possible to specify any physical interface as an HA interface. In order to provide maximum
fault tolerance and to eliminate a single point of failure, it is recommended that two interfaces
be used to provide HA connectivity in the instance that one of the interfaces fails.
!
HA interfaces are responsible for transmitting control messages and data
messages. When two interfaces are used for HA, one interface is used for
control messages (usually the lower interface number) and the other for data
messages. If the interfaces are gigabit, the failure of one interface will allow
the other interface to continue transmitting both control and data messages.
However, if both interfaces are only fast ethernet, the failure of one interface
will allow the remaining interface to only transmit control messages.

8.5.1. Control Messages
Two kinds of control messages are transmitted: heartbeats and HA messages.
There are three types of heartbeats, a couple which we have already covered: VSD group
heartbeats, RTO heartbeats and HA physical link heartbeats.
HA physical link heartbeats are broadcast messages from the HA interfaces of both firewalls
to monitor the status of the actual HA interfaces. If one member does not receive 3
consecutive heartbeats from a particular HA interface, it fails over all messages to the
second HA interface.
The two types of HA messages are: configuration messages and RTO messages. RTO
messages pertain the RTO synchronisation data sent between firewalls. Configuration
messages are new configuration settings that have been configured on the master which are
then sent to the other peers in the cluster.
8.5.2. Data Messages
Data messages are IP packets traversing the firewall that the backup in a VSD group must
forward to the device acting as master. When a packet arrives at the interface of a cluster
member in an active/active configuration, the firewall first identifies which VSD group must
process the packet. If the firewall that receives the packet is the master of the identified VSD
group, it processes the packet itself. If not, the packet is forwarded over the HA link to the
master
8.5.3. Link Probes
Typically, the two HA ports of both firewalls in a cluster are cabled directly together (using
say, a cross over cable). However, this type of connecti vity limits the distance that the two
firewalls can be from each other. As such, it is possible to extend this distance by having a
switch in between to extend the possible distance between the two devices.
This setup in itself has the potential for problems though. If the HA1 interface of firewall1
fails, its HA2 interface will now be carrying the control (and possibly data) message load.
However, firewall2s HA1 interface is still active (as its connectivity to the switch is still active)

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 161
and as a result, it rejects the new control messages now being received by its HA2 interface
as it is still expecting them from interface HA1.
Link probes were introduced to solve this very problem. By sending out link probes on the
HA interfaces to the HA interfaces of the other peer, a firewall can determine if a peer
interface has failed even through a switched environment.
Sending Manual Link Probes
Link probes can be sent manually by an administrator if they suspect that a peer interface
may have become inactive. The probe is sent every second for a given number of times and
if no response is received after, then the peer interface is deemed as inactive. Issue the
following command in order to manually send link probes:
exec nsrp probe interface peer-MAC count threshold
Where interface is the outgoing interface on the probing firewall, peer-MAC is the
MAC address of the HA interface of the peer and threshold is the number of probes
to be sent.
Configuring Automatic Link Probes
Link probes can also be configured automatically, so that a firewall will continuously monitor
its peers HA interface and automatically failover when it deems it as being inactive. Like the
manual method, probes are sent every second and if a reply is not received after a given
number of probes, the firewall will deem the peer interface as down. With automatic link
probing, it is also possible to configure an interval, which is the number of seconds in
between probe attempts. To configure automatic link probing, issue the following commands:
set nsrp ha-link probe interval interval threshold threshold
8.6. Active/Active
One complaint that is made about active/passive failover is that one of the firewalls remains
unutilised unless the master fails. Active/active failover utilises both firewalls, with one of the
firewalls taking over the load of both firewalls if the other fails. As you may recall, in an
active/passive failover situation, there is one VSD group and by default, both firewalls are
clustered into that group with one as a master and the other as a backup. When configuring
an active/active cluster, there is an additional VSD group with both firewalls being the master
of one group and the backup for the other. For example, if there are two VSD groups, 0 and
1, firewall 1 may be the master for group 0 and the backup for group 1 where firewall 2 may
be the master for group 1 and the backup for group 0.
!
One of the main caveats about active/active failover is that planning of the
traffic load must be done very carefully. If both firewalls are utilised at 100%,
and one fails, the other firewall will not be able handle the increased load.

Only NetScreen firewalls in layer 3 mode (NAT or Route) can be configured in active/active
mode.
!
One important tid-bit of information to mention that may not have been
mentioned up until now. Only the same model firewalls can be clustered
together. That is, an NS204 cannot be clustered with an NS208 for example.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 162
Configuring an Active/Active Cluster
Configuring an active/active cluster requires more planning than that of an active/passive
configuration. Not only is the actual configuration more complicated, but the way in which
devices connect is slightly different. Remember that with active/passive, there is one logical
firewall representing both firewalls (one that is the master, and the other one inactive in
backup). All devices still connect to this one logical firewall and if the master fails, the
backup successfully takes over. This transaction is seamless to connecting devices.
In active/active, both firewalls are active and the failure of one firewall transfers all the load to
the other firewall (which is acting as backup). As both firewalls are active, there isnt an
aspect of one logical firewall that all devices connect to. To ensure that both firewalls are
properly utilised, half of the devices on the network will connect to one firewall, and half will
connect to the other firewall.
To configure an active/active cluster, issue the following sequence of commands:
On Firewall 1:
Assign a cluster ID:
set nsrp cluster id cluster-ID
Configure the preempt options for this firewall (assuming that it will be master for the
default VSD Group 0):
set nsrp vsd-group id 0 preempt hold-down number
Where number is a value from 0 to 600 seconds.
set nsrp vsd-group id 0 preempt
Set the priority of this firewall for the VSD Group
set nsrp vsd-group id 0 priority priority
Where priority is a value between 1 and 255 (the default being 100). The closer the
priority to 0, the higher the priority. As this firewall would be the master of this
particular VSD group, you would assign it the highest priority.
Configure the other VSD Group required for an active/active configuration:
set nsrp vsd-group id 1
Enable RTO Mirror Synchronisation:
set nsrp rto-mirror sync
On Firewall 2:
Join firewall2 to the cluster:
set nsrp cluster id cluster-ID
Once both firewalls have been clustered, the commands issued on one will be
propagated to the other. The exception to this are commands to do with priority and
preempt options.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 163
Assign a cluster name to the cluster:
set nsrp cluster name clustername
Configure firewall2 to send RTO synchronisation information:
set nsrp rto-mirror sync
As firewall2 will be the master for the second VSD group (group 1), configure the
priority and preempt options accordingly:
set nsrp vsd-group id 1 priority priority
set nsrp vsd-group id 1 preempt hold-down number
set nsrp vsd-group id 1 preempt
Configure a secondary HA path in the instance that the HA interface(s) fail:
set nsrp secondary-path interface
Configure gratuitous ARPs:
set nsrp arp 5
set arp always-on-dest
Configure interfaces for VSD group 0:
set interface interface zone zone
set interface interface ip ipaddress/mask(octet)
For interface(s) that will be manageable, configure a manage IP address for it which
is different from the actual IP address:
set interface interface manage-ip manage-IPaddress
Configure monitoring for the interface:
set nsrp monitor interface interface
Configure the Virtual Security Interfaces for the other VSD group:
Set interface interface:vsd-groupID ip ipaddress/mask(octet)
Configure default gateway both the Internet facing interfaces of both VSD groups:
set vrouter vrouter route 0.0.0.0/0 interface interface gateway ipaddress
set vrouter vrouter route 0.0.0.0/0 interface interface:vsd-groupID gateway ipaddress
On Firewall1:
Firewall 1 should now have all of the configurations that were synchronised. As
manage IP information is not synchronised, enter the manage IP that will be used to
manage Firewall1:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 164
set interface interface manage-ip manage-IPaddress
8.7. Failover
Now that weve explored both cluster modes and the configuration options required, we can
more closely examine how and when a firewall will determine it needs to failover (or how the
other cluster member can determine its peer has failed).
There are effectively two types of failover: full device failover and VSD group failover.
When two firewalls are clustered together and one device fails, it will become inactive and
the backup device will become master, taking over all traffic processing.
A VSD group failover is relevant to only active/active configurations. In this instance, the
failure of say, a single port of a single interface does not constitute to a full device failover.
Instead, the master of that group will failover just that particular VSD group to the backup,
but can continue to be active and the backup for the other VSD group.
8.7.1. Failover Monitoring
It is possible to define certain objects to monitor in order to determine when a failure should
occur. Objects that can be monitored include:
Physical interfaces ensuring that the physical ports are active
Zones ensuring that all physical ports as part of a zone are active
Specific target IP addresses Up to 16 IP addresses can be monitored to determine
whether connectivity beyond the local physical connection is active
The two main settings to configure for failover monitoring are the failover threshold, and the
failure weight assigned to each of the monitored objects.
The failover threshold determines when a device or VSD group failover should occur. When
a monitored object fails (or becomes inactive), the weight assigned to it is added to a
cumulative weight count. Each monitored group has its own cumulative weight count which
in itself has a weighting value. When the threshold of the group is exceeded, the weight of
the group is added to the overall weight count. When the threshold of this weight count is
exceeded, then the device of VSD group fails over. A picture paints a thousand words:

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 165

Configuring the Device or VSD Group Threshold
It is possible to modify the device/VSD group failover by issuing the following command:
set nsrp monitor threshold threshold
Where threshold can be any value between 1 and 255 (the default).
Configuring Physical Interface Monitoring
To configure physical interface monitoring, issue the following command:
set nsrp monitor interface interface weight weight
Where weight can be any value between 1 and 255 (the default).
Configuring Zone Monitoring
To configure zone monitoring, issue the following command:
set nsrp monitor zone zone weight weight
Where weight can be any value between 1 and 255 (the default).
Configuring IP Address Monitoring
Up to 16 IP addresses can be monitored per cluster. To configure monitoring of an IP
address using track IP, issue the following command:
set nsrp track-ip ip ipaddress weight weight
Where weight can be any value between 1 and 255 (the default).
The IP address monitoring threshold is the only threshold that can be modified out of the
different monitored group thresholds. To modify the IP address monitoring threshold, issue
the following command:
set nsrp monitor track-ip threshold threshold

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 166
Where threshold can be any value between 1 and 255 (the default).
!
A situation can exist with IP address tracking where both firewalls will not
receive a response from a given IP address, and if the threshold is reached,
both devices will fail causing a traffic black hole. In this instance, it is possible
to force a device to always be a master to handle traffic. Issue the command
set nsrp vsd-group master-always-exist to ensure that a device will always
be made master.

8.8. Review Questions

1. Which command is used to determine whether the configuration of a cluster is out of
sync?
a. set nsrp sync global-config check-sum
b. set nsrp sync global-config
c. exec nsrp sync global -config check-sum
d. exec nsrp sync global -config
2. What state can members of a VSD group be in? Select the THREE best options.
a. Master
b. Primary
c. Backup
d. Primary Backup
e. Inactive
3. What does a cluster member perform when it becomes the master of a cluster?
a. Attempts to synchronise configuration with peers
b. It requests all Run-Time Objects from its peers
c. It performs a status check on its own interfaces
d. It sends out gratuitous ARPs
4. Which command is used to configure RTO synchronisati on?
a. set nsrp rto-mirror sync
b. set nsrp sync rto
c. set nsrp sync rto-mirror

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 167
d. exec nsrp rto-mirror sync
5. Which command is used to configure a cluster name for an NSRP cluster?
a. set cluster name clustername
b. set nsrp cluster name clustername
c. set nsrp cluster clustername
d. set nsrp name clustername
6. How can you ensure that two cluster members will not both try to become the master of a
cluster?
a. Leave one cluster member disconnected until it is required to become active
b. Use the preempt option
c. Ensure that both devices are the same models
d. Set both firewalls to the same priority
7. Which of the following properties are not propagated to other cluster members? Select
the THREE best options.
a. Manage IP address
b. IP address information
c. Zone configuration
d. Bandwidth management configuration
e. User account information
8. What happens when one of the dedicated HA interfaces fails in a dual HA interface
configuration?
a. The firewall with the failed interface will become inactive
b. If the interfaces are gigabit, all control and data messages will failover to the
other interface
c. If the interfaces are fast ethernet, all control and data messages will failover to
the other interface
d. The firewalls will use a secondary path for HA communication
e. At the hub site running ScreenOS 4.0.0.
9. What will occur if NTP and NSRP time synchronisation are both enabled?
a. Configuring NTP automatically disables NSRP time synchronisation
b. Configuring NSRP time synchronisation automatically disables NTP

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 168
c. The time may become unsynchronised
d. Nothing. The time will always be synchronised.
10. What type of information is included in an NSRP heartbeat message? Select the TWO
best answers.
a. IP address information
b. Unit ID of the device sending the heartbeat
c. VSD group membership status
d. Configurations
e. Traffic
11. Which are the three types of failover monitoring?
a. Physical, Zone, IP address
b. Physical, Logical, IP address
c. IP address, IP network, Zone
d. Physical, Zone, Virtual Router
12. Which command can you issue to resynchronise configurations without requiring a
reboot?
a. exec nsrp sync global -config save
b. exec nsrp sync global -config run
c. set nsrp sync global-config save
d. set nsrp sync global-config run
13. In an active/active cluster, if an interface for a particular VSD group member fails in a
VSD group failover, what would occur?
a. The device would become inactive and the other peer would take over all the
load
b. Nothing. The firewall would continue to be active for its VSD group and continue
to process traffic, just not for that particular interface
c. The device would failover that particular VSD group and make it inactive, but still
be active for any other configured VSD groups
d. Just that one interface would fail over to the peer
14. Which of the following weights would need to be assigned to a cluster peer member for it
to have a higher priority than the default?
a. 110

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 169
b. 100
c. 90
d. 255
15. What must be taken into consideration when configuring an active/active failover? Select
the THREE best options.
a. The firewalls should be connected to different layer devices
b. The firewalls should be located within close proximity
c. The load for each firewall should not exceed 50% of its total capacity
d. Dual HA interfaces should be used
e. The firewalls should be of a different hardware type
8.8.1. Review Answers

1. Which command is used to determine whether the configuration of a cluster is out of
sync?
c. Remember that when executing a command, it usually begins with an exec prefix
compared to the set which is used to apply a configuration.
2. What state can members of a VSD group be in? Select the THREE best options.
a, c, d. A VSD group member can be in 6 different states: primary, primary backup,
backup, initial, ineligible and inoperable.
3. What does a cluster member perform when it becomes the master of a cluster?
d. When a cluster member becomes master for a cluster, it sends out gratuitous ARPs to
all nearby networking devices so they will now where to send traffic to.
4. Which command is used to configure RTO synchronisation?
a.
5. Which command is used to configure a cluster name for an NSRP cluster?
b.
6. How can you ensure that two cluster members will not both try to become the master of a
cluster?
b. The preempt option allows a device to be configured as master of a VSD group by
default. When it becomes active again, it will regain master status without being
contested.
7. Which of the following properties are not propagated to other cluster members? Select
the THREE best options.

Netscreen JNCIS- FWV Study Guide v1.3-public.doc 30 Mar 2005 14:03
Page 170
a, d, e. Information that is not propagated to another cluster member includes: cluster ID,
account information, interface monitoring configuration, manage IP addresses, bandwidth
management configurations, IP tracking configurations, console settings, hostnames,
virtual router settings and SNMP settings.
8. What happens when one of the dedicated HA interfaces fails in a dual HA interface
configuration?
b. If both interfaces are gigabit ethernet, control and data messages will failover to the
second HA interface. If both interfaces are fast ethernet, only control messages will
failover. The device will not necessarily need to failover.
9. What will occur if NTP and NSRP time synchronisation are both enabled?
c. The firewall permits both forms of time synchronisation at the same time, but as NTP
works at the sub-second level, it is possible for the time to become unsynchronised. It is
recommended to disable NSRP time synchronisation if NTP is in use.
10. What type of information is included in an NSRP heartbeat message? Select the TWO
best answers.
b, d. NSRP heartbeat messages contain the following information: unit ID of the sending
device, VSD group ID, VSD group member status, device priority and RTO peer
information.
11. Which are the three types of failover monitoring?
a.
12. Which command can you issue to resynchronise configurations without requiring a
reboot?
b. The save option requires a reboot where the run option does not.
13. In an active/active cluster, if an interface for a particular VSD group member fails in a
VSD group failover, what would occur?
c. In a VSD group failover, the device does not fully failover. It fails over the VSD group
for which it deems that it cannot be active for, but continues to be active for other
configured VSD groups.
14. Which of the following weights would need to be assigned to a cluster peer member for it
to have a higher priority than the default?
c. The default priority assigned to devices is 100. For the peer to have a higher priority, it
needs to be less than 100 as the closer to 0, the higher the priority.
15. What must be taken into consideration when configuring an active/active failover? Select
the THREE best options.
a, c, d. In order to eliminate single points of failure, both firewalls should be connected to
different layer 2 devices and use two HA interfaces. It is also important to ensure that both
devices do not exceed 50% of their capacity as a peer member will not be able to facilitate
the extra load if one member fails.

Potrebbero piacerti anche