JNCIS-FWV Study Guide v1.3-Public

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


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


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 As sociations .............................................................................................................................................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


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


1. Introduction Juniper Network’s Certified Internet Specialist in Firewall and VPN (JNCIS-FWV) is a new stream of certification as part of Juniper Network’s 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 will 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 doesn’t warn you that you haven’t selected enough – silly I know), you will get that question wrong. Make sure you check at the 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:

Juniper’s NetScreen Concepts and Examples ScreenOS Reference Guide v5.0.0:

http://www.juniper.net/techpubs/software/screenos/screenos5x/


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 Network’s 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.


!

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.


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 firewall’s 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.


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 it’s 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. Don’t 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


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 interface’s 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


The tables below list the main specifications for the 5000 series:


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


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


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 differenc e 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-modular 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


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 System’s 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 wouldn’t 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 interface’s (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).


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


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.


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 if it is different to the actual physical interface’s 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 switch’s 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, it’ll 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.


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


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.


As mentioned in the interface section, an interface’s 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


Or

get zone id zone-id

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).

!

It’s 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.


“But wait… what if I want to restrict that traffic with policies and don’t 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 isn’t it strange creating a policy from and to the same zone? How does the policy know which interface I’m referring to when the policy is within a zone and not between interfaces?” The simple answer is, no, it’s not strange (especially if you’re 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.


2.5. Virtual Routers All firewalls can “route” (well, layer 3 ones anyway), but NetScreen firewalls don’t just route; they include “virtual routers” which can be configured in their own right. Let’s 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 it’s 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. Here’s the element of complexity though… as a NetScreen firewall has more than one virtual router, it is often


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 gateway’s IP address (gw-ip-address). At times, a destination will reside on an interface, even though it’s 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 didn’t 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! Don’t 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 NetScreen’s routing table:

get route

Output:

C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP

untrust-vr (2 entries)

--------------------------------------------------------------------------------


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:

--------------------------


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).


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 firewall’s 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 I’d 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


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 zone’s 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.


! 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, it’s 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 zone’s 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:


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:



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 interface’s IP address.

3. If Policy NAT-src has been configured without a specified DIP, traffic will be NATed using the egress interface’s 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.


! 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 interface’s 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


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


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-id 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 network’s 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:


set address zone address-name NAT-ip-address/mask(octet)

set vrouter vrouter route NAT-ip-address/mask(octet) interface interface

set policy from src-zone to dst-zone src address-name service nat dst ip real-ip-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 interface’s 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 zone’s 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 it’s created in, then your policy will be incorrect. Let’s 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.


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-ip-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)


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-ip-address listen-port destination-service real-ip-address

set policy from untrust to dst-zone source vip(NAT-ip-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-ip-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.


• 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.


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-id

c. get route active

d. get route id route-id

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


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?


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 can’t 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


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 route’s 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 System’s 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.


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 can’t 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.


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


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 certificate’s 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 CA’s 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 *


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 Authority’s 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 NetScreen’s 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


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



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.


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 packet’s payload. ESP supports the DES, 3DES and AES protocols for encryption. Like


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.


! 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-to-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


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


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


set ike gateway gw-name cert peer-ca CA

set ike gateway gw-name cert peer-cert-type ca-type


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.


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, let’s assume that it’s tunnel mode using ESP). The packet is appended with a new header which includes the outgoing interface’s IP address as its source IP address and the remote gateway’s IP address as the destination. The packet’s 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 (let’s presume it’s 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


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 it’s 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 recipient’s 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.


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 isn’t 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 gateway’s 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-id 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-id outgoing-interface phy-interface proposal p1-proposal

On the recipient device:


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 zone

set zone untrust vrouter untrust-vr


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




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:







Interfaces:

set interface interface-trust zone trust

set interface interface-trust ip trust-ip/mask(octet)

set interface interface-trust nat


set interface interface ip siteA-external-IP/mask(octet)



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 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).


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





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 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)


In this instance, the tunnel1-ip should be an IP address that resides on the local area network of Site A and the tunnel2-ip should be an IP address that resides on the local area network of Site B.

VPN for Site A:




set vpn SiteA-VPN proxy-id local-ip 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 vpn SiteB-VPN gateway SiteB sec-level compatible


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


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


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 peer’s 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 peer’s 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-ip vpn vpn-name

! Although it is possible to add entries into the NHTB table, it actually isn’t 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:



unset interface untrust-interface ip

unset interface untrust-interface zone


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 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 vpn SiteA-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any


set vpn SiteB-VPN gateway SiteA sec-level compatible


set vpn SiteB-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any


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


unset interface untrust-interface ip

unset interface untrust-interface zone


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 ip siteA-tunnel-IP/mask(octet)


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


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.


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 ip siteA-external-IP/mask(octet)


set interface tunnel.1 ip siteA-tunnel-IP/mask(octet)

Configure the DIP pool:

set interface tunnel.1 dip dip-id 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 B’s 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.


Routes:

set vrouter untrust-vr route siteB-Net/mask(octet) interface tunnel.1

This route entry represents the entire network assigned to Site B’s tunnel interface.

set vrouter trust-vr route siteA-NAT-IP/mask(octet) interface trust-interface

This entry is required for NAT-dst to function.


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


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 tunnel’s egress interface address as the source-interface and the destination interface’s 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 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.


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 initiator’s attempts to establish a VPN are failing.

3.12.1. IKE It’s 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:


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


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.


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>


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


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


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 it’s 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"



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




proxy id:

local 0.0.0.0/0.0.0.0, remote 192.168.2.0/255.255.255.0, proto 0, port 0


No Authentication


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"


[192.168.1.0/24, 192.168.2.0/24, 0-65535, 0-65535, 0]


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




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


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 ns208’s 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:


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.


In order to obtain 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:


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)


## 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 it’s 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!


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


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.


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.


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 recipient’s IP address is configured incorrectly.

7. Observe the following information:










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.







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



from 1.1.1.2:500 to 1.1.1.1:500 with





in the SA config.



(<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. CA’s Private Key

c. CA’s 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.


e. NHTB tables include the destination and VPN tunnel to use.


Firewall 1: VPN Group 1 – Weight 3




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.


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.


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 recipient’s IP address as the packet would not have arrived at the recipient otherwise.










XAUTH status: 0


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.








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 don’t 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.



from 1.1.1.2:500 to 1.1.1.1:500 with




in the SA config.



(<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.


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 CA’s 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.






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.


18. What must be configured on a Hub and Spoke VPN for it to be able to enforce policies? Select the TW O 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.


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 (it’s 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 interface’s 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 firewall’s 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


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:


Output:






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




RIP disabled



DHCP-Relay disabled


In this example, we can see that manage IP address is different from the interface IP address.


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-ip

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:


Output:







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




RIP disabled



DHCP-Relay 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.


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


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


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 firewall’s 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


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 self 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


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


• 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


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-id

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:


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 zone’s Screen options.

Obtaining Screen Counters

To obtain the Screen counters for a particular zone, issue the command:

get counter screen zone zone


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 |


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:


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


• sysContact - Contact information for the administrator of the firewall in case the SNMP administrator needs to contact them. This can be the administrator’s 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 defines 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.


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


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


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


d. Attack

4. Which command can be used to display an interface’s 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


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


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


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 interface’s 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.


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.


5. Troubleshooting Traffic Flows Anyone who’s ever needed to implement a firewall can testify to the pains associated with connectivity. Traffic that gets blocked for no reason, traffic that isn’t routed somewhere properly, traffic that is permitted when it shouldn’t be… the list goes on. Depending on the platform you’re 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.


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


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 ip-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


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.


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.


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:


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 we’ve 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:


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.


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 1st-argument 1st-property 2nd-argument 2nd-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:


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 can’t 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>


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. Let’s try and break each section down to get an idea of what’s happening.

! If you haven’t 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.



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).


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.


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.


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.


The firewall confirms the route it will use and the relevant ingress interface and egress interface it will use.


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 (don’t make it easy do they?), and in this instance, it is a policy search from the Trust zone to the Untrust zone.


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.


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.



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.


The firewall then attempts to lookup the service book to determine the specifics of the service.


As this is the first packet received by the firewall for this session (it must be, otherwise it wouldn’t 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.


An ARP entry already exists for the destination IP address. If it hadn’t, 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.


In order to increase processing speeds, the firewall decides to cache the MAC address of the destination.


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. Let’s 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


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


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.



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


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


ipid = 40354(9da2), @c7d3b910


ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>













existing vector list 201-218e480.


route to 10.10.10.2




flow got session.

flow session id 1874



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


ipid = 40354(9da2), @c7d3b910


ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>













route to 10.10.10.2





flow got session.





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


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?


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



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.


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.


ipid = 40354(9da2), @c7d3b910


ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>
















route to 10.10.10.2




flow got session.





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.


ipid = 40354(9da2), @c7d3b910


ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>














route to 10.10.10.2




flow got session.





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 wouldn’t 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.


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?


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.


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


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)




• 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 aren’t confused during the exam.

Changing the Default Bandwidth Management Settings


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. Th e 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.

Let’s 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 2nd, 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 vying for maximum bandwidth from the maximum bandwidth pool, the bandwidth is allocated on a round robin basis.


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.


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


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


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


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?


a. 3Mb

b. 0Mb

c. Unlimited

d. The bandwidth settings are not valid as you cannot have a guaranteed bandwidth of 0


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.


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).


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.


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 system’s 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.


! 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 can’t 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


! 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 it’s 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:


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 System’s 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:


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 vsys vsys

Ensure that there are no configurations on the interface:



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.


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.


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 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-id

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


! 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


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.


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?


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


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


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.


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, 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.


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


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 VSI’s 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.


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 wouldn’t 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.


• 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).


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 particular 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 avoid issues with digital certificates and SNMP


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


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 firewall’s 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.


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


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


8.5. HA Interfaces NetScreen Systems have dedicated HA interfaces for the purposes of connecting two firewalls together in a cluster. As Appliances don’t 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 connectivity 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, firewall2’s HA1 interface is still active (as its connectivity to the switch is still active)


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 peer’s 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.


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 isn’t 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:


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.


Assign a cluster name to the cluster:


Configure firewall2 to send RTO synchronisation information:


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:


set interface interface manage-ip manage-IPaddress

8.7. Failover Now that we’ve 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:


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


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


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


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.


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 synchronisation?

a. set nsrp rto-mirror sync

b. set nsrp sync rto

c. set nsrp sync rto-mirror


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


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


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


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.


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.

Documents

JNCIS-FWV Study Guide v1.3-Public