Professional Documents
Culture Documents
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.
Author: Jason Ha
jha@verisign.com
DOCUMENT CONTROL
Preparation
Action Name Date
Prepared by: Jason Ha 3-MAR-2005
Reviewed by:
Release
Change Doc Date Change By Description
Version Released
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 10/04/2005 21:55:00
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
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).
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).
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:
http://www.juniper.net/techpubs/software/screenos/screenos5x/
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.
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:
Configuring, using and understanding debug output from Flow Filters and Snoop.
5. Traffic Management:
6. Virtual Systems:
7. NSRP
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).
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.
Value
Feature
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:
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
Value
Feature
Value
Feature
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
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.
The management module provides overall management and control over the NetScreen
System and other modules and assists primarily with non-flow related tasks (tasks not
dedicated to processing packets). Both modules include a dedicated management interface,
a console port, a modem port, dual dedicated HA interfaces and a compact flash slot. The
difference between the two lies in the processor speed. The 5000-M includes an onboard
600 MHz PowerPC CPU while the 5000-M2 unleashes a dual 1GHz PowerPC CPU
configuration.
The interface modules available for the 5000 series are named Secure Port Modules
(SPMs). There are only two available, an 8 port modular hot-swappable mini-GBIC module
(8G) or a 2 non-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
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”…)
• Transparent
• Route
• NAT
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).
get interface
Output:
Output:
Interface ethernet1:
PPPoE disabled
route-deny disable
RIP disabled
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.
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.
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.
Where number corresponds to the number you would like to assigned to the
interface (eg. tunnel.1)
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
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.
First Interface:
Second Interface:
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.
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.
Assigning a Manage-IP:
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.
Zone Details
To obtain detailed information regarding the available zones, issue the command:
get zone
Output:
------------------------------------------------------------------------
------------------------------------------------------------------------
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.
Output:
interface ethernet1(0x1ab9ed0)
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).
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.
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).
• 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).
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.
get vrouter
Output:
A - AutoExport, R - RIP
To change the default virtual router for a NetScreen (root or virtual system):
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
Static routes can be network or host based. To add a static route to a virtual router:
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.
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:
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.
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:
untrust-vr (2 entries)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
trust-vr (7 entries)
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
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.
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:
--------------------------
IP address/mask: 1.1.1.1/32
preference: 20
metric: 1
tag: 0
flag: 00000040/00000008
type: static
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:
Output:
---------------------
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).
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.
In order to see all the policies configured for your NetScreen firewall, issue the command:
get policy
Output:
More detailed information can be obtained from a specific policy by issuing the command:
Output:
name:"none" (id 1), zone Trust -> Untrust,action Permit, status "enabled"
log yes, log count 0, alert no, counter yes(3) byte rate(sec/min) 0/0
No Authentication
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).
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.
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.
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..
The syntax for creating an Intrazone policy is the same as an Interzone policy:
set policy from src-zone to dst-zone src dst service action [options]
The difference being that the src-zone and the dst-zone will be the same zone.
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.
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.
3. Create custom service and/or service group (can be omitted if pre-defined services
are being used)
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.
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.
In order to configure Interface NAT, simply set an interface to NAT mode with the following
command:
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.
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
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.
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.
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.
In order to configure a DIP pool with Address Shift for a range of IP addresses or a whole
network, enter the command:
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.
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
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.
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.
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).
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 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.
In order to obtain the details regarding configured MIPs, issue the command:
get mip
Output:
To perform NAT-dst using MIPs, you must first create the MIP and then reference it in the
policy like so:
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.
get vip
Output:
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:
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:
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 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:
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.
Take note of these two terms – First Packet Processing and Fast Processing.
! They are referred to in the exam several times.
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.
• If the destination zone is a security zone, that 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 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.
(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.
Some typical operations are source address translation, VPN tunnel selection and
encryption, decryption, and packet forwarding.
1. Which command can you use to determine how long a route has been active for?
a. get route
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.
b. You have a DIP pool configured and bound to the relevant policy
a. CPU
b. RAM
d. Management ASIC
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
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?
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
12. What is the reason why you can’t assign a VLAN ID to an interface?
13. What is the correct command to make the Untrust-vr your default virtual router?
14. What command would you use to determine the route used to reach the host
200.200.200.1/32?
15. You cannot add an IP address to one of your interfaces. What is most likely the problem?
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.
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.
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.
a & d. When creating aggregate interfaces, the physical interfaces must be grouped
sequentially. It is not possible to create aggregate interfaces between different modules.
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.
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.
12. What is the reason why you can’t assign a VLAN ID to an interface?
13. What is the correct command to make the Untrust-vr your default virtual router?
14. What command would you use to determine the route used to reach the host
200.200.200.1/32?
15. You cannot add an IP address to one of your interfaces. What is most likely the problem?
c. The interface must belong to a valid Security or Function zone before an IP address
can be assigned to it.
NetScreen 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).
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).
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.
A Registration Authority (RA) typically handles digital certificate signing requests on behalf of
the CA.
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.
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:
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:
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.
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:
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:
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
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:
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)
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.
• 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
• pre-g1-des-md5
• dsa-g2-3des-sha1
• rsa-g5-aes128-md5
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
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.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.
• nopfs-esp-des-md5
• g1-ah-null-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.
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.
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
Route-based VPNs also support the exchange of dynamic routing information through the
VPN tunnels.
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:
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:
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.
We will examine a Route-based VPN packet flow, and then highlight the differences in
regards to a Policy-based VPN.
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.
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.
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.
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.
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
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.
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:
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.
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.
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.
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.
The configuration is largely the same with the following exceptions when the gateway is
being defined:
set ike gateway gw-name address remote-gw aggressive local-id local-id outgoing-
interface phy-interface preshare preshared-key proposal p1-proposal
set ike gateway gw-name address remote-gw aggressive local-id local-id 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.
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.
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.
Interfaces:
Routes:
For Site A:
Interfaces:
Address:
VPN:
Routes:
Policies:
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).
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.
Interfaces:
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.
Routes:
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:
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
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.
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:
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.
Interfaces:
Addresses:
VPNs:
Routes:
Policies:
For Site A:
Interfaces:
Routes:
Policies:
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:
VPNs:
Dynamic Routing:
ns(untrust-vr/bgp)-> exit
ns(untrust-vr)-> exit
For Site A:
Dynamic Routing:
ns(untrust-vr/bgp)-> exit
ns(untrust-vr)-> exit
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.
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:
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:
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.
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.
This entry represents the NAT IP address that Site B will use for its Policy NAT-dst.
This route entry represents the entire network assigned to Site B’s tunnel interface.
Policies:
set policy from trust to untrust SiteA-Net to siteB-NAT-IP any nat src dip-id dip-id
permit
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 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 the same zone as the source address, and intrazone
blocking is enabled.
In order to configure VPN Monitoring for a given VPN tunnel, issue the following commands:
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.
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.
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).
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.
To configure a VPN Group, issue the following commands on the device connecting to the
VPN Group (this example uses Policy-based VPNs):
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.
Where number is the number of successful or failed heartbeats before a tunnel will
be deemed as active or inactive. The default is 5.
This command is issued for each peer in the VPN group where weight is the priority
assigned to that peer.
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”
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:
Output:
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.
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:
negotiations.
<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.
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:
Output:
In order to view the output, you must issue the following command:
## 16:23:57 : IKE<1.1.1.2 > Proxy ID match: No policy exists for the proxy ID
received
! Despite its name, IKE Debug also shows IPSec negotiation messages.
Obtaining SA Information
get sa
Output:
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.
In order to obtain further information regarding a given SA, issue the following command:
get sa id id
Output:
DF bit: clear
app_sa_flags: 0x2067
anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1352 seconds
anti-replay on, last 0x0, window 0x0, idle timeout value <0>, idled 1342 seconds
The additional information provides the incoming and outgoing SPI used as well as proxy ID
information.
This error relates to a misconfigured proxy-ID. The following is a sample output containing
this error:
in the SA config.
(<192.168.1.0>/<255.255.255.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
Output:
name:"none" (id 1), zone Trust -> Untrust,action Tunnel, status "enabled", pair
policy 2
vpn VPN to Remote Site1 - Phase2, nsp tunnel 40000002, sa index 1, sa tunnel id 2
log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0
proxy id:
name:"none" (id 2), zone Untrust -> Trust,action Tunnel, status "enabled", pair
policy 1
log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0
proxy id:
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.
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:
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.
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:
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:
encap(1)<TUNNEL>, group(0)
## 17:15:01 : IKE<1.1.1.2 > proposal not acceptable, but no more proposal in payload.
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.
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 > ****** Recv packet if <ethernet3> of vsys <Root> ******
## 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
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.
To correct this issue, simply reconfigure the VPN configuration to the correct interface.
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.
c. MIPs
d. VIPs
4. Which options must be configured for VPN redundancy? Select the two best options.
a. Aggressive mode
c. TCP-SYN-Check
d. Main mode
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?
b. The recipient is using the wrong outgoing interface for the VPN.
c. The initiator is using the wrong outgoing interface for the VPN.
XAUTH status: 0
What can you determine from the presented information? Select the TWO best answers.
What can you determine from the presented information? Select the TWO best answers.
in the SA config.
(<172.16.1.1>/<255.255.255.255>, <0>,
11. What are the components required to be loaded on a NetScreen Firewall to support
digital certificates? Select the THREE best answers.
a. CRL
d. Local Certificate
e. OCSP
12. What attributes about the NHTB table are true? Select the TWO best answers.
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
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
c. The source IP and destination IP of the first packet through the VPN.
d. Any network.
a. Tunnel interface.
b. Security Policies.
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. Identities.
b. Proxy-IDs.
c. Preshared Keys.
d. Digital Certificates.
2. At which point do the end points exchange a nonce during main mode negotiations?
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.
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
What can you determine from the presented information? Select the TWO best answers.
b, c. The output from “get ike cookie” displays information relating to a Phase 1
negotiation. The active status of this output shows that the Phase 1 negotiation is
successful. The nxt-rekey field is details the number of seconds remaining before the
next rekey. Hence, we can assume that the current key has been active for 421 seconds
(28800 – 28379). As the NAT traversal map is not available, we can assume that NAT
traversal has not been enabled. By the proposal method, we can tell that this Phase 1
tunnel was established using PRESHR – Preshared Keys.
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.
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.
in the SA config.
(<172.16.1.1>/<255.255.255.255>, <0>,
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?
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.
b. Proxy-IDs are exchanged during the Phase 2 negotiation. All other options are
exchanged during the Phase 1 negotiation.
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.
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.
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
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.
In order to view the Manage IP assigned to an interface, simply view the interface properties
using the following command:
Output:
Interface ethernet1:
PPPoE disabled
route-deny disable
RIP disabled
DHCP-Relay disabled
DHCP-server disabled
In this example, we can see that manage IP address is different from the interface IP
address.
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.
In order to view the currently configured Manager-IPs, issue the following command:
Output:
In order to view the management methods that have been currently configured for an
interface, issue the command:
Output:
Interface ethernet1:
route-deny disable
RIP disabled
DHCP-Relay disabled
DHCP-server disabled
In this example, we can see that SSH, web and SSL management methods have been
enabled.
4.4.1. CLI
The Command Line Interface (CLI) is the most efficient of all the management methods (in
terms of bandwidth). Using the CLI, commands and configurations are directly issued to the
firewall. Most debugging and troubleshooting can only be performed using one of the CLI
interfaces.
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.
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:
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:
In order to configure telnet management, issue the following command for the relevant
interface:
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.
To enable web management for a given interface, issue the following command:
Once you have obtained a digital certificate, to enable web management for a given
interface, issue the following command:
To configure an administrative user with various user privileges, issue the following
command:
• Establishes and manages virtual systems, and assigns physical or logical interfaces
to them
• Creates virtual systems and assigns a virtual system administrator for each one
• Tracks statistics
• Read-only privileges in the root system, using the following four commands: enter,
exit, get, and ping
• Creates and edits auth, IKE, L2TP, XAuth, and Manual Key users
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”.
• SYN attacks
• WinNuke attacks
• IP Spoofing attacks
• LAND attacks
• ICMP floods
• Address sweeps
• Bad SPI
• Low resources
• SSH failures
• AV Scanning issues
• SMTP issues
It is important to remember what events are logged into which levels as part
! of the exam.
get event
Output:
contacted.
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
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.
As traffic logs relate to specific policies, the command issued must reference a security
policy which has the logging option enabled:
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.
To obtain the flow counters for all interfaces, issue the command:
To obtain the flow counters for individual interfaces, issue the command:
Output:
To obtain the flow counters for a specific zone, issue the command:
Output:
To obtain the Screen counters for a particular zone, issue the command:
IP sweep protection 0
Output:
To obtain policy counter statistics for a given security policy, issue the command:
Output:
PID: 22, Interval: Day, Unit: Mb/Day, End Time: 27 Feb 2005 21:13:06
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 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
To configure a NetScreen firewall to use a Syslog server, issue the following commands:
In Syslog terms, the security facility is used to log critical security events
! where the facility is used to log all other events.
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.
An SNMP read/write community member can change the following variables on the firewall:
• 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.
• 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:
• 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.
• 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.
• You can send SNMP messages through a route-based or policy-based VPN tunnel.
Configuring SNMP
Where privilege can be read-write or read-only. Where version can be v1, v2c or
any.
When an alarm is triggered, an administrator can be notified through the following methods:
• Console
• Event log
• SNMP
• Syslog
• WebTrends
• NSM
To configure a traffic alarm for a given policy, append the following options to the end of a
policy configuration:
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.
In order to be notified of traffic alarms via email, issue the following commands:
2. Which external methods can be used to monitor the status of a NetScreen device? Select
the TWO best answers.
b. SYSLOG server
c. WebTrends server
d. NSM
a. Alert
b. Critical
c. Emergency
5. What is true about manage and manager IPs? Select the TWO best options.
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. get self
d. get log
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.
11. Which of the following would not trigger a default SNMP trap or notification?
a. Power on.
b. Reboot.
d. Traffic alarm.
12. Which command could be used to determine the number of failed VLAN packets?
b. Get event
a. alarm
b. critical
c. emergency
d. debugging
14. In which event log would three failed authentication attempts appear?
a. critical
b. warning
d. Notification
15. Which command can be issued to determine the enabled management methods for a
given interface?
2. Which external methods can be used to monitor the status of a NetScreen device? Select
the TWO best answers.
c. SYN Floods and other critical attacks are recorded into the emergency event log.
b. This command allows you to view 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.
c.
10. An administrator wants traffic alarms sent to three different email address. Which of the
following options could enable this to happen?
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.
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.
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.
When you enable a particular debug, events relating to that are recorded into 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
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:
Remember that all events, including those generated by Snoop, are recorded
! in dbuf.
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
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
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 ip ip ip-address
To be more specific, you can apply a filter which looks for a given source IP address by
issuing the command:
Snooping a Port
As with hosts, ports can also be monitored with a bi-directional filter by issuing the
command:
Snooping an Interface
A filter can be added to monitor traffic inbound and outbound for a given interface by issuing
the command:
Snooping an IP-Protocol
A filter can also be added to just monitor for a specific IP-Protocol type by issuing the
command:
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 will only capture packets that contain the destination IP address AND destination port
number.
Output:
35455.0: 4(i):0010db1c5921->0010db1b44b4/0800
10.1.10.5->1.1.70.250/1, tlen=128
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.
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.
frag=0000 details whether the packet has been fragmented, and if so, the fragment
ID.
05375.0: 0(i):00b0d080b93e->0010db06eeb0/0800
10.1.10.5->2.2.2.222/6, tlen=48
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 Untrust interface then receives 1(i) an ARP reply r /0806 containing the MAC address
of the destination 0010a4a77630.
• policies applied
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
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:
In order to capture packets destined for a given destination host, create a flow filter by
issuing the following command:
In order to capture packets from a given source host, create a flow filter by issuing the
following command:
In order to capture packets destined for a given destination port, create a flow filter by
issuing the following command:
In order to capture packets from a given source port, create a flow filter by issuing the
following command:
In order to capture packets of a given protocol type, create a flow filter by issuing the
following command:
get ffilter
Output:
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.
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:
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.
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:
Output:
We can see that instead of being two separate filters with separate IDs, it is entered as a
single filter with a single ID.
• It is not possible to combine the same argument twice (i.e. src-port src-port)
• 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)
We will take a look at a general output, and then specific examples relating to different
issues.
Output:
ethernet1:192.168.1.10/1280->194.73.82.242/512,1(8/0)<Root>
Permitted by policy 3
route to 1.1.1.2
flow session id 76
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…
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.
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.
Permitted by policy 3
The outcomes over the policy lookup appear here. If the firewall finds a policy, it displays the
action. If the firewall fails to find a policy, it typically uses the implied default policy. In this
instance, the firewall has found a policy (policy ID 3) which matches the traffic with an action
of permit.
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.
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
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.
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.
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
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:
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:
When policy NAT-dst is applied, we can observe the following line in the output:
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.
Lastly, we can obtain information about traffic, or more specifically, sessions created by
traffic using the following command:
get session
Output:
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.
2. Which command allows you to see the messages stored in the debug buffer?
b. get dbuf
d. get debuffer
What can you determine regarding the session? Select the TWO best options.
4. Which commands can be used to deactivate Snoop? Select the TWO best options.
a. snoop disable
b. unset snoop
c. clear snoop
c. unset ffilter
d. clear ffilter
ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>
Permitted by policy 10
route to 10.10.10.2
What can you determine from the output? Select the THREE best options.
7. What command can be used to configure a Snoop filter to monitor bidirectional traffic
flows?
b. snoop ip ip ipaddress
d. snoop ip ipaddress
ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>
Permitted by policy 5
route to 10.10.10.2
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
9. What command can be used to determine the DIP pool used for a given traffic flow?
a. get dip
b. get event
d. get session
05375.0: 7(i):00b0d080b93e->0010db06eeb0/0800
1.1.1.100->2.2.2.200/6, tlen=48
What can you determine from the output? Select the TWO best answers.
11. Which Snoop commands could be used to capture packets from source IP 1.1.1.1 and
source port 2222?
b. snoop ip ip 1.1.1.1
d. snoop ip ip 1.1.1.1
b. clear dbuf
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
15. When would you elect to use Snoop over a flow filter?
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?
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.
ethernet2:10.1.1.1/2053->100.100.100.100/22,17<Root>
Permitted by policy 10
route to 10.10.10.2
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
a, c, d. We can observe in the output that the destination port is 22 (SSH). We know
Policy NAT-src is not being used as there is a MIP configured for the IP address (also
observed by noting the hip xlate – which only applies to MIPs and VIPs). In the routing
information, we can see that the output refers to the IP address 10.10.10.2 as the default
gateway. Remember that user defined zones must have an ID greater than 100.
7. What command can be used to configure a Snoop filter to monitor bidirectional traffic
flows?
a. This is the only command which will monitor bidirectional traffic and has the correct
syntax. Specifying the src-ip or dst-ip options limits the traffic monitoring to one way.
ethernet1:10.1.1.1/2053->20.20.20.20/80,17<Root>
Permitted by policy 5
route to 10.10.10.2
update policy out counter info. packet send out to 0003e1f92bc4 through
ethernet3
What can you determine from the output? Select the THREE best options.
b, c, e. Based on the output, we can see that no NAT has been performed on the packet
(the post addr xlation is the same as the original). The default gateway from the routing
information is 10.10.10.2 and it is a new packet (otherwise it 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
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.
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.
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.
In order to configure the maximum bandwidth for a given interface, issue the following
command:
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).
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.
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:
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.
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.
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.
It is possible to change the mapping of the NetScreen priorities to the DSCP markings by
issuing the following command:
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.
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
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
a. 6
b. 7
c. 8
d. 9
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?
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?
7. What should the total bandwidth allocated to an interface be? Select the TWO best
options.
c. No more than the total bandwidth available for the path the interface is connected
to
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
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?
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.
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).
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 guaranteed
bandwidth configuration of 10Mb?
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.
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).
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.
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.
exit
Where [ vrouter share vrouter ] is the optional command to use a shared root system
virtual router instead of a default.
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:
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:
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 and edit auth, IKE, L2TP, XAuth, and Manual Key users
The vsys also inherits all predefined services from the root system.
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.
To change the status of a virtual router to shared, issue the following command:
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
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:
Import the interface and assign it to a zone with and provide it with an IP address:
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:
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.
The process of determining the Virtual System to process the traffic can be outline in three
steps:
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.
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 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.
• 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.
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.
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:
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.
• 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.
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:
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.
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?
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
5. Which of the following statements is NOT true? Select the TWO best answers.
d. A virtual system cannot be configured to use both IP-based and VLAN based
classification at the same time
6. What is required to configure a Subinterface for a vsys? Select the THREE best options.
d. A Subinterface from the root system needs to be imported into the vsys
d. No administrators
8. Which of the following can a Virtual System read only administrator debug?
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?
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?
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?
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.
7. How many administrators would be required to enable routing between six different vsys
in route mode?
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.
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.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
• Interface monitoring
• Manage IP addresses
• IP tracking commands
• Console settings
• Hostnames
• SNMP 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.
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:
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:
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.
On the device that has the highest priority, issue the following command:
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:
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.
• 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:
• 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.
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:
If you reduce the VSD heartbeat interval, you should increase the init-hold
! value.
To change the state of a group member to ineligible, issue the following command:
• VSD group ID
• Device priority
The interval for sending VSD heartbeats is configurable and applies globally to all VSD
groups. To configure the heartbeat interval, issue the following command:
Where number can be 200, 600, 800, or 1000 milliseconds (1000 ms is the default).
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:
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.
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).
To configure active/passive failover for two NetScreen firewalls, issue the following
sequence of commands on both firewalls:
Optionally, provide authentication and encryption for cluster status traffic (such as
heartbeats):
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:
It is also possible to configure the number of gratuitous ARPs sent out should the
cluster member become the new master:
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.
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.
You can discover if one firewall’s configuration is out of sync with the other by issuing the
following command:
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:
If you need to synchronise files, issue the following command on the target firewall:
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:
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.
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
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:
To define the number of heartbeats required to deem a peer as down, changing its state
from active to set, issue the following command:
To disable RTO synchronisation from the device acting as the sender in an NSRP cluster,
issue the following command:
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:
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.
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)
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.
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:
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.
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:
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.
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.
On Firewall 1:
Configure the preempt options for this firewall (assuming that it will be master for the
default VSD Group 0):
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.
On Firewall 2:
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.
As firewall2 will be the master for the second VSD group (group 1), configure the
priority and preempt options accordingly:
For interface(s) that will be manageable, configure a manage IP address for it which
is different from the actual IP address:
Configure the Virtual Security Interfaces for the other VSD group:
Configure default gateway both the Internet facing interfaces of both VSD groups:
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:
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.
• Zones – ensuring that all physical ports as part of a zone are 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:
It is possible to modify the device/VSD group failover by issuing the following command:
Where threshold can be any value between 1 and 255 (the default).
Where weight can be any value between 1 and 255 (the default).
Where weight can be any value between 1 and 255 (the default).
Where weight can be any value between 1 and 255 (the default).
The IP address monitoring threshold is the only threshold that can be modified out of the
different monitored group thresholds. To modify the IP address monitoring threshold, issue
the following command:
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.
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?
6. How can you ensure that two cluster members will not both try to become the master of a
cluster?
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
8. What happens when one of the dedicated HA interfaces fails in a dual HA interface
configuration?
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
9. What will occur if NTP and NSRP time synchronisation are both enabled?
10. What type of information is included in an NSRP heartbeat message? Select the TWO
best answers.
a. IP address information
d. Configurations
e. Traffic
12. Which command can you issue to resynchronise configurations without requiring a
reboot?
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
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
c. 90
d. 255
15. What must be taken into consideration when configuring an active/active failover? Select
the THREE best options.
c. The load for each firewall should not exceed 50% of its total capacity
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.
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.
a.
b.
6. How can you ensure that two cluster members will not both try to become the master of a
cluster?
7. Which of the following properties are not propagated to other cluster members? Select
the THREE best options.
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.
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.