JSEC 12.a-R LGD

Junos Security
12.a
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-JSEC

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Junos Security Detailed Lab Guide, Revision 12.a
Copyright 2012, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 9.aJuly 2009
Revision 10.aMay 2010
Revision 10.b--December 2010
Revision 12.aJune 2012
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.1R1.9. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental
or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Lab 1: Configuring and Monitoring Zones (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Part 1: Logging In Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Verifying Network Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Part 3: Configuring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Part 4: Monitoring and Verifying the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Lab 2: Security Policies (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Part 1: Accessing Your Device and Monitoring the Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Part 2: Configuring Address Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Part 3: Configuring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Part 4: Monitoring Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Lab 3: Configuring Firewall Authentication (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Part 1: Configuring Firewall User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Part 2: Verifying and Monitoring Firewall User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Lab 4: Implementing Screen Options (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Part 1: Accessing Your Device and Configuring Screen Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Part 2: Verifying Screen Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Part 3: Monitoring Screen Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Lab 5: Network Address Translation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Part 1: Interface-Based Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Part 2: Pool-Based Destination NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Part 3: Pool-Based Source NAT with Overflow Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Lab 6: Implementing IPsec VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Part 1: Configuring a Route-Based IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Part 2: Verifying and Monitoring IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Lab 7: Implementing IDP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Part 1: Retrieving and Installing the Security Package and IDP License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Part 2: Installing the IDP License and Security Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Part 3: Enabling IDP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Lab 8: Implementing High Availability Techniques (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Part 1: Loading the Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Part 2: Preparing and Forming a Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Part 3: Configuring an Active/Active Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Part 4: Monitoring Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
Part 5: Disabling the Chassis Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1
www.juniper.net Contents iii

iv Contents www.juniper.net
Course Overview
This three-day course covers the configuration, operation, and implementation of SRX Series
Services Gateways in a typical network environment. Key topics within this course include security
technologies such as security zones, security policies, intrusion detection and prevention (IDP),
Network Address Translation (NAT), and high availability clusters, as well as details pertaining to
basic implementation, configuration, and management. The course includes extensive hands-on
labs, in which you configure and monitor the Junos operating system using SRX Series devices.
This course is based on Junos OS Release 12.1R1.9.
Objectives
After successfully completing this course, you should be able to perform the following:
Describe traditional routing and security and the current trends in internetworking.
Provide an overview of SRX Series devices and software architecture.
Describe the logical packet flow and session creation performed by SRX Series
devices.
Describe, configure, and monitor zones.
Describe, configure, and monitor security policies.
Describe, configure, and monitor firewall user authentication.
Describe various types of network attacks.
Configure and monitor SCREEN options to prevent network attacks.
Explain, implement, and monitor NAT, as implemented on Junos security platforms.
Explain the purpose and mechanics of IP Security (IPsec) virtual private networks
(VPNs).
Implement and monitor policy-based and route-based IPsec VPNs.
Utilize and update the IDP signature database.
Configure and monitor IDP policy with policy templates.
Describe, configure, and monitor high availability chassis clusters.
Intended Audience
The course content is aimed at operators of SRX Series devices. These operators include network
engineers, administrators, support personnel, and reseller support personnel.
Course Level
Junos Security is an intermediate-level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the Open Systems
Interconnection (OSI) reference model and the TCP/IP protocol suite. Students should also attend
the Introduction to the Junos Operating System (IJOS) course and the Junos Routing Essentials
(JRE) course, or have equivalent experience prior to attending this class.
www.juniper.net Course Overview v

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Introduction to Junos Security
Chapter 3: Zones
Lab 1: Configuring and Monitoring Zones
Chapter 4: Security Policies
Lab 2: Security Policies
Day 2
Chapter 5: Firewall User Authentication
Lab 3: Configuring Firewall Authentication
Chapter 6: Screen Options
Lab 4: Implementing Screen Options
Chapter 7: Network Address Translation
Lab 5: Network Address Translation
Day 3
Chapter 8: IPsec VPNs
Lab 6: Implementing IPsec VPNs
Chapter 9: Introduction to Intrusion Detection and Prevention
Lab 7: Implementing IDP
Chapter 10: High Availability Clustering Theory
Chapter 11: High Availability Clustering Implementation
Lab 8: Implementing High Availability Techniques
Appendix A: SRX Series Hardware and Interfaces
vi Course Agenda www.juniper.net

Document Conventions
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:

commit complete
Screen captures
Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
Menu names Configuration.conf in the
Filename text box.
Text field entry
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also
distinguishes between syntax variables where the value is already assigned (defined variables) and
syntax variables where you must assign the value (undefined variables). Note that these styles can
be combined with the input style as well.
CLI Variable Text where variable value is policy my-peers

already assigned.
GUI Variable
Click my-peers in the dialog.
CLI Undefined Text where the variables value Type set policy policy-name.
is the users discretion and text
ping 10.0.x.y
where the variables value as
GUI Undefined shown in the lab guide might Select File > Save, and type
differ from the value the user filename in the Filename field.
must input.
www.juniper.net Document Conventions vii

Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication
The Junos Security Detailed Lab Guide was developed and tested using software Release
12.1R1.9. Previous and later versions of software might behave differently so you should always
consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.net/techpubs/.
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
viii Additional Information www.juniper.net

Lab 1
Configuring and Monitoring Zones (Detailed)
Overview
In this lab, you will configure a baseline network for your pod, including interface
addressing, routing, and assigning interfaces to zones.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
The lab is also designed for modularity, where you might be directed to load a starting
configuration at the beginning of each lab part. If you are completing the lab from start to
finish, there is no need to load the starting configuration for each lab part.
By completing this lab, you will perform the following tasks:
Use the Junos operating system CLI to setup a baseline network.
Implement routing so that all networks are reachable.
Assign interfaces to security zones.
Monitor the effects of your configuration.
www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 11

12.a.12.1R1.9
Junos Security
Part 1: Logging In Using the CLI
In this lab part, you become familiar with the access details used to access the lab
equipment. Once you are familiar with the access details, you will use the CLI to log
in to your teams designated station.
Note
Depending on the class, the lab equipment
used might be remote from your physical
location. The instructor will inform you as to
the nature of your access and will provide
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.
Question: What is the management address

assigned to your student router?
Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for srxA-1, which uses 10.210.35.131 as its
management IP address. The actual management
address varies between delivery environments.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
Lab 12 Configuring and Monitoring Zones (Detailed) www.juniper.net

Junos Security
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab1-start.config from the /var/home/lab/jsec/ directory. Commit the
configuration when complete.
srxA-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxA-1> configure
Entering configuration mode
[edit]
lab@srxA-1# load override jsec/lab1-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Note
You might receive a warning message upon
committing that you have changed to MPLS
flow mode, and that you must reboot the
SRX device. If you receive this warning,
reboot your assigned SRX device and log
back in as user lab once the device
finishes rebooting.
Step 1.4
View the current configuration of your assigned device.
[edit]
lab@srxA-1# show security
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}

Junos Security
Question: Are any security zones currently
configured on your assigned device?
Answer: As shown in the output, no zone currently

exists in the configuration.
Question: What do you notice about the security

policy that is set up on your device?
Answer: As indicated by the output from srxA-1,

currently the device is in packet-based mode that
disables the flow-based security feature of Junos.
Step 1.5
Navigate to the [edit interfaces] hierarchy. Configure the IP address for the
ge-0/0/3 interface. Refer to the lab diagram for the appropriate IP address.
[edit]
lab@srxA-1# edit interfaces
[edit interfaces]
lab@srxA-1# set ge-0/0/3 unit 0 family inet address local-Internet-interface/
mask
[edit interfaces]
lab@srxA-1#
Step 1.6
Configure the lo0 loopback interface IP address. Refer to the lab diagram for the IP
address assigned to your device.
[edit interfaces]
lab@srxA-1# set lo0 unit 0 family inet address local-loopback-address
Step 1.7
Configure the ge-0/0/4 interface. Enable VLAN-tagging and configure two logical
units. Each logical unit number should match its associated VLAN-ID. Refer to the
VLAN assignments listed on the network diagram for Labs 17. Assign the IP
address shown on the lab diagram. Note that the third octet of the IP address should
also match the logical units associated VLAN-ID.
[edit interfaces]
lab@srxA-1# set ge-0/0/4 vlan-tagging
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-Juniper-unit vlan-id local-Juniper-VLAN

Junos Security
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-Juniper-unit family inet address
local-Juniper-interface/mask
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-ACME-unit vlan-id local-ACME-VLAN
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit local-ACME-unit family inet address
local-ACME-interface/mask
Question: Which VLAN-IDs are associated with your

assigned device?
Answer: The answer varies. The VLAN-IDs

associated with srxA-1 are 101 and 201.
Step 1.8
Configure a static default route that points to the IP address associated with the
remote end of the ge-0/0/3 interface for your device. Commit the configuration and
return to operational mode.
[edit interfaces]
lab@srxA-1# up
[edit]
lab@srxA-1# edit routing-options
[edit routing-options]
lab@srxA-1# set static route 0/0 next-hop remote-Internet-address
lab@srxA-1# commit and-quit
commit complete
Exiting configuration mode
lab@srxA-1>
STOP Ensure that the remote student team within your pod has finished
Part 2 before continuing.

Junos Security
Part 2: Verifying Network Connectivity
In this lab part, you verify network connectivity within your pod.
Step 2.1
Enter configuration mode, or go to the top of the configuration hierarchy if you are
already in configuration mode, and load the lab1-part2-start.config from
the /var/home/lab/jsec/ directory. Commit the configuration when complete.
[edit]
lab@srxA-1# load override jsec/lab1-part2-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 2.2
Check the status of your configured interfaces using the run show interfaces
terse command.
[edit]
lab@srxA-1# run show interfaces terse |no-more
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.35.131/26
gr-0/0/0 up up
ip-0/0/0 up up
lsq-0/0/0 up up
lt-0/0/0 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
sp-0/0/0.16383 up up inet 10.0.0.1 --> 10.0.0.16
10.0.0.6 --> 0/0
128.0.0.1 --> 128.0.1.16
128.0.0.6 --> 0/0
ge-0/0/1 up up
ge-0/0/2 up up
ge-0/0/3 up up
ge-0/0/3.0 up up inet 172.18.1.2/30
ge-0/0/4 up up
ge-0/0/4.101 up up inet 172.20.101.1/24
ge-0/0/4.201 up up inet 172.20.201.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up down
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up up
ge-0/0/10 up up
ge-0/0/11 up up
ge-0/0/12 up down
ge-0/0/13 up down
ge-0/0/14 up up
Junos Security
ge-0/0/15 up up
fxp2 up up
fxp2.0 up up tnp 0x1
gre up up
ipip up up
irb up up
lo0 up up
lo0.0 up up inet 192.168.1.1 --> 0/0
lo0.16384 up up inet 127.0.0.1 --> 0/0
lo0.16385 up up inet 10.0.0.1 --> 0/0
10.0.0.16 --> 0/0
128.0.0.1 --> 0/0
128.0.0.4 --> 0/0
128.0.1.16 --> 0/0
lo0.32768 up up
lsi up up
mtun up up
pimd up up
pime up up
pp0 up up
ppd0 up up
ppe0 up up
st0 up up
tap up up
vlan up up
Question: What is the administrative status and link

status of your configured interfaces?
Answer: As shown in the output taken from srxA-1,

the administrative status and link status of the
configured interfaces should all indicate a status of
up.
Question: What is the status of your management

interface? (Refer to the Management Network
Diagram as needed.)
Answer: The management interface is ge-0/0/0.0

and should also indicate an administrative status
and link status of up.
Step 2.3
Verify reachability to the remote peer in your pod across the Internet using the ping
command.
[edit]
lab@srxA-1# run ping remote-srx-Internet-address rapid

Junos Security
PING 172.18.2.2 (172.18.2.2): 56 data bytes
!!!!!
--- 172.18.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.973/2.169/2.438/0.156 ms
Question: Was the ping to your remote peer

successful?
Answer: As indicated by the output from srxA-1, the

ping should be successful. If the ping is not
successful, double-check your configuration and
notify your instructor.
.
Note
The next lab steps require you to log in to
the virtual router attached to your teams
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Diagram for the IP address of the vr-device.
Although you have two virtual routers
attached to your student device, you only
need to establish a single session.
Open a separate Telnet session to the virtual router attached to your team device.

Junos Security
Step 2.4
Log in to the virtual router using the login information shown in the following table:
Virtual Router Login Details
Student Device Username Password

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must use 'configure private' to configure this router.
a1@vr-device>
Step 2.5
From the Telnet session established with the virtual router, verify reachability to the
remote virtual routers connected to the device of your peers using the ping
command. Be sure to source your ping from the correct virtual-router routing
instance.
Note
Keep in mind that when working with
virtual routers and routing instances,
command syntax is different. If needed,
please reference the detailed lab guide for
sample command syntax for the individual
verification tasks performed within this lab.
a1@vr-device> ping remote-ACME-VR routing-instance local-ACME-VR rapid

PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!
--- 172.20.202.10 ping statistics ---

Junos Security
a1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid

PING 172.20.102.10 (172.20.102.10): 56 data bytes
!!!!!
--- 172.20.102.10 ping statistics ---
a1@vr-device> ping remote-ACME-VR routing-instance local-Juniper-VR rapid

PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!
--- 172.20.202.10 ping statistics ---
a1@vr-device> ping remote-Juniper-VR routing-instance local-ACME-VR rapid

PING 172.20.102.10 (172.20.102.10): 56 data bytes
!!!!!
--- 172.20.102.10 ping statistics ---
Question: Were the pings between remote

virtual-routers successful?
Answer: As indicated by the output from user a1,

the pings should be successful. If the pings are not
successful, double-check your configuration and
notify your instructor.
Part 3: Configuring Zones
In this lab part, you remove the current zone configuration and reassign your device
interfaces to various security and functional zones.
Step 3.1
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete

Junos Security
Step 3.2
Navigate to the [edit security] configuration hierarchy.
[edit]
lab@srxA-1# edit security
[edit security]
lab@srxA-1#
Step 3.3
View the [edit security] configuration stanza and answer the questions that
follow.
[edit security]
lab@srxA-1# show
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
Question: Which configured security zones are on

your assigned device and which interfaces are
associated with the configured security zones?
Answer: As indicated by the output from srxA-1,

currently no security zones are configured.
Question: Which configured functional zones are on

your assigned device and which interfaces are
associated with the configured functional zones?
Answer: As indicated by the output, the

configuration has no functional zones.
Question: Should a user be able to telnet to your

assigned device? Why or why not?
Answer: The configuration allows telnet to each

device. No policies exist that deny traffic, and telnet
is also enabled under the [edit system
services] hierarchy.

Junos Security
Step 3.4
Delete the current security policy. You will create a new policy in the next few steps.
[edit security]
lab@srxA-1# delete
Delete everything under this level? [yes,no] (no) yes
[edit security]
lab@srxA-1# show
Step 3.5
Refer to the lab diagram and configure the untrust security zone, as well as your
local Juniper and ACME security zones, as labeled on the lab diagram. Add the
appropriate network interfaces under each security zone. Be sure to configure only
the security zones associated with your assigned device.
[edit security]
lab@srxA-1# set zones security-zone Juniper-local interfaces
ge-0/0/4.local-Juniper-unit
[edit security]
lab@srxA-1# set zones security-zone ACME-local interfaces
ge-0/0/4.local-ACME-unit
[edit security]
lab@srxA-1# set zones security-zone untrust interfaces ge-0/0/3.0
[edit security]
lab@srxA-1# show
zones {
security-zone Juniper-SV {
interfaces {
ge-0/0/4.101;
}
}
security-zone ACME-SV {
interfaces {
ge-0/0/4.201;
}
}
security-zone untrust {
interfaces {
ge-0/0/3.0;
}
}
}
Step 3.6
Next, configure a functional zone and associate it with your devices management
interface.
[edit security]
lab@srxA-1# set zones functional-zone ?
Possible completions:

Junos Security
> management Host for out of band management interfaces
[edit security]
lab@srxA-1# set zones functional-zone management interfaces ge-0/0/0.0
Question: What name did you assign to the

functional zone of your device? Why?
Answer: Each student should assign a functional

zone name of management. As shown in the
output, the Junos OS predefines this name.
management is the only name the Junos OS allows
for a functional zone.
Step 3.7
Configure the functional zone so that it allows SSH, telnet, ping, traceroute, HTTP,
and SNMP local inbound traffic.
[edit security]
lab@srxA-1# edit zones functional-zone management
[edit security zones functional-zone management]

lab@srxA-1# set host-inbound-traffic system-services ssh

lab@srxA-1# set host-inbound-traffic system-services telnet

lab@srxA-1# set host-inbound-traffic system-services ping

lab@srxA-1# set host-inbound-traffic system-services traceroute

lab@srxA-1# set host-inbound-traffic system-services http

lab@srxA-1# set host-inbound-traffic system-services snmp

lab@srxA-1# show
interfaces {
ge-0/0/0.0;
}
host-inbound-traffic {
system-services {
ssh;
telnet;
ping;
traceroute;
http;
snmp;

Junos Security
}
}

lab@srxA-1#
Question: If you needed to allow all services but

telnet using the host-inbound-traffic statement,
what would be the quickest method?
Answer: You could use the system-services

all and the system-services telnet
except configuration statements to achieve this
task with the most efficiency.
Step 3.8
Commit your configuration and exit configuration mode.
commit complete
lab@srxA-1>
Part 4: Monitoring and Verifying the Configuration
In this lab part, you use show commands to monitor the zones you just created. You
will also test host inbound traffic.
Step 4.1
[edit]
load complete
[edit]
commit complete
lab@srxA-1>
Step 4.2
Issue the show security zones command and answer the following questions.

Junos Security
lab@srxA-1> show security zones
Functional zone: management

Policy configurable: No
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: ACME-SV

Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
ge-0/0/4.201
Security zone: Juniper-SV

Interfaces bound: 1
Interfaces:
ge-0/0/4.101
Security zone: untrust

Interfaces bound: 1
Interfaces:
ge-0/0/3.0
Security zone: junos-host

Interfaces bound: 0
Interfaces:
Question: Does the output list the zones and

associated interfaces you configured?
Answer: The answer should be yes. An additional

security zone named junos-host, used for
secure self traffic, appears in the list.
Question: What differences do you notice in the

output for the management zone?
Answer: The output lists the management zone as a

functional zone and security policy is not
configurable for the management zone.

Junos Security
Step 4.3
Issue the show interfaces ge-0/0/0 extensive command to view
detailed information regarding management interface of your device.
lab@srxA-1> show interfaces ge-0/0/0 extensive
Physical interface: ge-0/0/0, Enabled, Physical link is Up
Interface index: 134, SNMP ifIndex: 507, Generation: 137
Description: MGMT Interface - DO NOT DELETE
Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:26:88:e1:54:80, Hardware address: 00:26:88:e1:54:80
Last flapped : 2012-06-12 15:17:15 UTC (01:08:46 ago)
Statistics last cleared: Never
Traffic statistics:
Input bytes : 297963 536 bps
Output bytes : 0 0 bps
Input packets: 2219 0 pps
Output packets: 0 0 pps
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 0 0 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes
0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
Active alarms : None
Active defects : None
MAC statistics: Receive Transmit
Total octets 309903 0
Total packets 2256 0
Unicast packets 37 0
Broadcast packets 50 0
Multicast packets 2169 0
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0

Junos Security
Oversized frames 0
Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 0
Output packet pad count 0
Output packet error count 0
CAM destination filters: 2, CAM source filters: 0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: None, Remote fault: OK,
Link partner Speed: 1000 Mbps
Local resolution:
Flow control: None, Remote fault: Link OK
Packet Forwarding Engine configuration:
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue Bandwidth Buffer Priority
Limit
% bps % usec
0 best-effort 95 950000000 95 0 low none
3 network-control 5 50000000 5 0 low none
Interface transmit statistics: Disabled
Logical interface ge-0/0/0.0 (Index 69) (SNMP ifIndex 533) (Generation 134)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Traffic statistics:
Input bytes : 297963
Output bytes : 0
Input packets: 2219
Output packets: 0
Local statistics:
Output bytes : 0
Input packets: 2219
Output packets: 0
Transit statistics:
Security: Zone: Management
Allowed host-inbound traffic : http ping snmp ssh telnet traceroute
Flow Statistics :
Flow Input statistics :
Self packets : 0
ICMP packets : 0

Junos Security
VPN packets : 0
Multicast packets : 0
Bytes permitted by policy : 0
Connections established : 0
Flow Output statistics:
Flow error statistics (Packets dropped due to):
Address spoofing: 0
Authentication failed: 0
Incoming NAT errors: 0
Invalid zone received packet: 0
Multiple user authentications: 0
Multiple incoming NAT: 0
No parent for a gate: 0
No one interested in self packets: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No SA for incoming SPI: 0
No tunnel found: 0
No session for a gate: 0
No zone or NULL zone binding 0
Policy denied: 0
Security association not active: 0
TCP sequence number out of window: 0
Syn-attack protection: 0
User authentication errors: 0
Protocol inet, MTU: 1500, Generation: 148, Route table: 0
Flags: Sendbcast-pkt-to-re, Is-Primary
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.210.35.128/26, Local: 10.210.35.131,
Broadcast: 10.210.35.191, Generation: 142
Question: What zone details are you able to

ascertain with this output?
Answer: The security portion of the output lists

logical interface zone assignment, allowed host
inbound traffic, and flow statistics.

Junos Security
Step 4.4
Verify that you are able to telnet to the management IP address of your assigned
device. Refer to the Management Network Diagram as needed.
srxA-1 (ttyp0)
login: ^C
Question: Was the telnet attempt successful?
Answer: As shown, the telnet attempt should

succeed. If the telnet attempt is not successful,
check your configuration and notify the instructor.
STOP Tell your instructor that you have completed Lab 1.

Junos Security

Lab 2
Security Policies (Detailed)
Overview
In this lab, you will implement security policies designed to allow only necessary traffic
between zones within your pod. You will configure custom applications, a scheduler, and
security logging and monitor the effects of your changes.
Define zone address books necessary for security policy.
Implement security policies between zones within your assigned pod.
Assign schedulers to security policies.
Implement security logging to a remote syslog server.
www.juniper.net Security Policies (Detailed) Lab 21

12.a.12.1R1.9
Junos Security
Part 1: Accessing Your Device and Monitoring the Default Policy
in to your designated station. Next, you will load the starting configuration for Lab 2.
Then, you will monitor the default policy configuration that denies all traffic between
zones.
Note
assigned device.
Step 1.1

assigned to your station?
Answer: The answer varies; in this example the user

is assigned to the srxC-1 station, which uses an
IP address of 10.210.14.135.
Step 1.2
Access the CLI at your station using either the console, Telnet, or SSH as directed by
your instructor. Refer to the Management Network Diagram for the IP address
associated with your workstation. The following example is based on simple Telnet
access using the Secure CRT program.
Lab 22 Security Policies (Detailed) www.juniper.net

Junos Security
Step 1.3
the lab2-start.config from the /var/home/lab/jsec/ directory. After you have
finished loading the configuration, commit the changes and exit to operational
mode.
srxC-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxC-1> configure
[edit]
lab@srxC-1# load override jsec/lab2-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Note

Junos Security
Step 1.4
Step 1.5

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
login: c1
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>

Junos Security
Step 1.6
Attempt to ping the virtual routers attached to the remote student device within your
pod. Ensure you source the ping from the appropriate routing instance. Refer to the
lab diagram as needed.
c1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid
PING 172.20.106.10 (172.20.106.10): 56 data bytes
.....
--- 172.20.106.10 ping statistics ---
c1@vr-device> ping remote-ACME-VR routing-instance local-Juniper-VR rapid

PING 172.20.206.10 (172.20.206.10): 56 data bytes
.....
--- 172.20.206.10 ping statistics ---
c1@vr-device> ping remote-Juniper-VR routing-instance local-ACME-VR rapid

PING 172.20.106.10 (172.20.106.10): 56 data bytes
.....
--- 172.20.106.10 ping statistics ---
c1@vr-device> ping remote-ACME-VR routing-instance local-ACME-VR rapid

PING 172.20.206.10 (172.20.206.10): 56 data bytes
.....
--- 172.20.206.10 ping statistics ---
Question: Did the ping test succeed? Why or why

not?
Answer: As demonstrated in the output, the ping

test should not succeed. Your assigned device has
no configured security policy. The default security
policy action is to deny all transit traffic as shown in
the following capture:
lab@srxC-1> show security policies

Default policy: deny-all
Part 2: Configuring Address Books
In this lab part, you configure the address book entries necessary for implementing
security policies within your pod.
Step 2.1
Return to the Telnet session established with your assigned SRX device.

Junos Security
From the Telnet session established with your assigned, enter configuration mode
and configure the networks associated with the remote teams virtual routers under
the untrust zone as address book addresses. Ensure you include the entire /24
network associated with each remote virtual router and name the address book
entries after their associated virtual router names.
[edit]
lab@srxC-1# edit security zones security-zone untrust
[edit security zones security-zone untrust]

lab@srxC-1# set address-book address remote-Juniper-vrName
remote-Juniper-subnet

lab@srxC-1# set address-book address remote-ACME-vrName remote-ACME-subnet

lab@srxC-1# show address-book
address vr106 172.20.106.0/24;
address vr206 172.20.108.0/24;

lab@srxC-1#
Step 2.2
Add the remote /30 network between the Internet and the remote student device in
your pod to the untrust zone address book. Configure this address entry to use the
same name as the remote student device in your pod.
lab@srxC-1# set address-book address remote-srx-name remote-srx-Internet-subnet

address vr106 172.20.106.0/24;
address vr206 172.20.108.0/24;
address srxC-2 172.18.2.0/30;
Step 2.3
Add the Internet hosts address as an address book entry in the untrust zone. Name
this entry internet-host.
lab@srxC-1# set address-book address internet-host 172.31.15.1/32

address vr108 172.20.108.0/24;
address vr208 172.20.208.0/24;
address srxC-2 172.18.2.0/30;
address internet-host 172.31.15.1/32;

Junos Security
Step 2.4
For the virtual routers attached to your assigned device, configure the /24 network
addresses as address book entries within their respective zones. Name these
address book entries with the same name as their associated virtual routers.
lab@srxC-1# up
[edit security zones]

lab@srxC-1# set security-zone Juniper-local address-book address
local-Juniper-vrName local-Juniper-subnet

lab@srxC-1# set security-zone ACME-local address-book address local-ACME-vrName
local-ACME-subnet

lab@srxC-1# show security-zone Juniper-local
address-book {
address vr105 172.20.105.0/24;
}
interfaces {
ge-0/0/4.105;
}

lab@srxC-1# show security-zone ACME-local
address-book {
address vr205 172.20.205.0/24;
}
interfaces {
ge-0/0/4.205;
}

lab@srxC-1#
Do not proceed to the next lab part until directed by the instructor to do
STOP
so.
Part 3: Configuring Security Policies
In this lab part, you will establish and configure security policies that enable the
necessary traffic flow between the security zones.
Note
Pay close attention to the instructions
throughout this lab. Some tasks might not
be relevant to your assigned device.

Junos Security
Step 3.1
lab@srxC-1# top
[edit]
lab@srxC-1# load override jsec/lab2-part3-start.config
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Create security policies named intrazone-Juniper-local and
intrazone-ACME-local that allows all intra-zone traffic associated with your
attached virtual routers to pass through your assigned device. (Hint: Use the any
keyword to save keystrokes.)
[edit]
lab@srxC-1# edit security policies from-zone Juniper-local to-zone
Juniper-local policy intrazone-Juniper-local
[edit security policies from-zone Juniper-SV to-zone Juniper-SV policy

intrazone-Juniper-SV]
lab@srxC-1# set match source-address any

lab@srxC-1# set match destination-address any

lab@srxC-1# set match application any

lab@srxC-1# set then permit

lab@srxC-1# show
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}

Junos Security

lab@srxC-1# up 2
[edit security policies]

lab@srxC-1# edit from-zone ACME-local to-zone ACME-local policy
intrazone-ACME-local
[edit security policies from-zone ACME-SV to-zone ACME-SV policy

intrazone-ACME-SV]

intrazone-ACME-SV]

intrazone-ACME-SV]

intrazone-ACME-SV]

intrazone-ACME-SV]
lab@srxC-1# show
match {
source-address any;
application any;
}
then {
permit;
}

intrazone-ACME-SV]
lab@srxC-1#
Step 3.3
Configure security policies allowing all traffic from the virtual router zones to the
untrust zone. Name these policies internet-Juniper-local and
internet-ACME-local. For this step, match on the appropriate source address
using the associated virtual router address book entries.
intrazone-ACME-SV]
lab@srxC-1# up 2

lab@srxC-1# edit from-zone Juniper-local to-zone untrust policy
internet-Juniper-local

Junos Security
[edit security policies from-zone Juniper-SV to-zone untrust policy
internet-Juniper-SV]
lab@srxC-1# set match source-address local-Juniper-vrName




lab@srxC-1# show
match {
source-address vr105;
application any;
}
then {
permit;
}

lab@srxC-1# up 2

lab@srxC-1# edit from-zone ACME-local to-zone untrust policy
internet-ACME-local
[edit security policies from-zone ACME-SV to-zone untrust policy

internet-ACME-SV]
lab@srxC-1# set match source-address local-ACME-vrName

internet-ACME-SV]

internet-ACME-SV]

internet-ACME-SV]

internet-ACME-SV]
lab@srxC-1# show

Junos Security
match {
application any;
}
then {
permit;
}

internet-ACME-SV]
lab@srxC-1#
Step 3.4
Next define a security policy the rejects FTP connections sourced from the your local
Juniper zone that are destined to the untrust zone. Name this policy
deny-ftp-Juniper-local.
internet-ACME-SV]
lab@srxC-1# up 2

lab@srxC-1# edit from-zone Juniper-local to-zone untrust policy
deny-ftp-Juniper-local

deny-ftp-Juniper-SV]


lab@srxC-1# set match application junos-ftp

lab@srxC-1# set then reject

lab@srxC-1# show
match {
source-address any;
application junos-ftp;
}
then {
reject;
}

Junos Security
Step 3.5
Commit the configuration.
lab@srxC-1# commit
commit complete
Step 3.6
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, attempt to open an FTP
session to the remote Internet host located at 172.31.15.1. Remember to source
the FTP from the routing instance associated with the local Juniper zone. Use the
Ctrl+C key sequence to close the FTP connection.
c1@vr-device> ftp 172.31.15.1 routing-instance local-Juniper-VR
Connected to 172.31.15.1.
220 vr-device FTP server (Version 6.00LS) ready.
Name (172.31.15.1:c1): ^C
c1@vr-device>
Question: Were you able to initiate an FTP session

to the Internet host? Why or why not?
Answer: As demonstrated in the output, the FTP

session should succeed. Although you configured a
security policy explicitly rejecting this connection,
policy ordering has effectively caused the device to
ignore this policy.
Step 3.7
From the Telnet session established with assigned SRX device, reorder the policies
so that the deny-ftp-Juniper-local policy appears in the list before the
internet-Juniper-local policy. Commit your configuration.
lab@srxC-1# up
[edit security policies from-zone Juniper-SV to-zone untrust]

lab@srxC-1# show
policy internet-Juniper-SV {
match {
application any;
}
then {
permit;
}

Junos Security
}
policy deny-ftp-Juniper-SV {
match {
source-address any;
}
then {
reject;
}
}

lab@srxC-1# insert policy deny-ftp-Juniper-local before policy
internet-Juniper-local

lab@srxC-1# show
match {
source-address any;
}
then {
reject;
}
}
match {
application any;
}
then {
permit;
}
}

lab@srxC-1# commit
commit complete

lab@srxC-1#
Step 3.8
From the Telnet session established with the virtual router, try the FTP connection
again. (Note: Exit the FTP application by issuing the bye command.)

Junos Security
Note
Keep in mind that when working with
virtual routers and routing instances,
command syntax can differ. If needed,
please reference the Detailed Lab Guide for
sample command syntax for the individual
verification tasks performed within this lab.
c1@vr-device> ftp 172.31.15.1 routing-instance local-Juniper-VR

ftp: connect: Connection refused
ftp> bye
c1@vr-device>
Question: Were you able to initiate an FTP session

to the Internet host this time?
Answer: As demonstrated in the output, the FTP

session does not succeed. The reordering of
policies produces the expected behavior.
Question: Are you able to ping the Internet host?
Answer: As demonstrated in the following output, a

ping to the Internet host should succeed. If the ping
test fails, re-check your configuration and notify
your instructor.
c1@vr-device> ping 172.31.15.1 routing-instance local-Juniper-VR rapid

PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!
Step 3.9
From the Telnet session established with assigned SRX device, create a custom
application named Juniper-gizmo that uses UDP, a source port of 50000, and a
destination port of 50001.
[edit security policies from-zone Juniper to-zone untrust]
lab@srxC-1# top
[edit]
lab@srxC-1# edit applications application Juniper-gizmo
[edit applications application Juniper-gizmo]

lab@srxC-1# set source-port 50000

Junos Security

lab@srxC-1# set destination-port 50001

lab@srxC-1# set protocol udp

lab@srxC-1# show
protocol udp;
source-port 50000;
destination-port 50001;

lab@srxC-1#
Step 3.10
Create an application set named internal-apps that includes the
Juniper-gizmo, junos-telnet, and junos-ping applications.
lab@srxC-1# up
[edit applications]
lab@srxC-1# edit application-set internal-apps
[edit applications application-set internal-apps]

lab@srxC-1# set application Juniper-gizmo

lab@srxC-1# set application junos-telnet

lab@srxC-1# set application junos-ping

lab@srxC-1# show
application Juniper-gizmo;
application junos-telnet;
application junos-ping;
Step 3.11
Configure security policies that permit the internal-apps applications between
your local Juniper security zone and the remote Juniper security zones. Because the
Juniper zones are separated by the Internet, you must reference the untrust zone
when configuring the security policies. Name the policy
Juniper-remote-to-Juniper-local, where Juniper-remote matches
the zone from which traffic is sourced and Juniper-local matches the zone to
which the traffic is sent. Do not use the any option in the configuration of this policy.
lab@srxC-1# top
[edit]
lab@srxC-1# edit security policies from-zone untrust to-zone Juniper-local

Junos Security
[edit security policies from-zone untrust to-zone Juniper-SV]

lab@srxC-1# set policy Juniper-remote-to-Juniper-local match source-address
remote-Juniper-vrName

lab@srxC-1# set policy Juniper-remote-to-Juniper-local match
destination-address local-Juniper-vrName

lab@srxC-1# set policy Juniper-remote-to-Juniper-local match application
internal-apps

lab@srxC-1# set policy Juniper-remote-to-Juniper-local then permit

lab@srxC-1# show
policy Juniper-WF-to-Juniper-SV {
match {
destination-address vr105;
application internal-apps;
}
then {
permit;
}
}

lab@srxC-1#
Question: How many new policies must you define

to allow internal-apps traffic bi-directionally?
Answer: Both devices within your assigned pod

already have policies defined allowing all internal
traffic destined to the untrust zone (with the
exception of FTP traffic). For each device you must
configure one policy allowing the internal-apps
to the appropriate zone from the untrust zone.
Step 3.12
Create a scheduler named internal-apps-scheduler. The scheduler should
allow traffic between the hours of 3 a.m. and 11 p.m., Monday through Friday. Apply
the new scheduler to the Juniper-remote-to-Juniper-local security
policy.
lab@srxC-1# top

Junos Security
[edit]
lab@srxC-1# edit schedulers scheduler internal-apps-scheduler
[edit schedulers scheduler internal-apps-scheduler]

lab@srxC-1# set daily start-time 03:00:00 stop-time 23:00:00

lab@srxC-1# set saturday exclude

lab@srxC-1# set sunday exclude

lab@srxC-1# show
daily {
start-time 03:00:00 stop-time 23:00:00;
}
sunday exclude;
saturday exclude;

lab@srxC-1# top
[edit]
lab@srxC-1# edit security policies from-zone untrust to-zone Juniper-local

lab@srxC-1# set policy Juniper-remote-to-Juniper-local scheduler-name
internal-apps-scheduler

lab@srxC-1# show policy Juniper-remote-to-Juniper-local
match {
}
then {
permit;
}
scheduler-name internal-apps-scheduler;

lab@srxC-1#
Step 3.13
Apply logging to session initiations and session closes in the
Juniper-remote-to-Juniper-local policy.
lab@srxC-1# set policy Juniper-remote-to-Juniper-local then log session-init

lab@srxC-1# set policy Juniper-remote-to-Juniper-local then log session-close

Junos Security
lab@srxC-1# show
match {
}
then {
permit;
log {
session-init;
session-close;
}
}
}
Step 3.14
Commit the configuration and return to operational mode.
lab@srxC-1# commit and-quit
commit complete
lab@srxC-1>
Question: Does the commit operation succeed?
Answer: As demonstrated in the output, the commit

should succeed. If you receive an error, re-check
your configuration steps and involve your instructor
as needed.
STOP Do NOT continue to the next lab part until both teams within your
assigned pod have reached this point.
Part 4: Monitoring Security Policies
In this lab part, you monitor the results of your configuration with command outputs
and logging.
Step 4.1

Junos Security
[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 4.2
View the security policies in effect on your assigned device by issuing the
show security policies command and answer the following questions.
lab@srxC-1> show security policies
From zone: Juniper-SV, To zone: Juniper-SV
Policy: interazone-Juniper-SV, State: enabled, Index: 4, Scope Policy: 0,
Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
From zone: Juniper-SV, To zone: untrust
Policy: deny-ftp-Juniper-SV, State: enabled, Index: 7, Scope Policy: 0,
Sequence number: 1
Applications: junos-ftp
Action: reject
Policy: internet-Juniper-SV, State: enabled, Index: 6, Scope Policy: 0,
Sequence number: 2
Source addresses: vr105
Applications: any
Action: permit
From zone: ACME-SV, To zone: ACME-SV
Policy: intrazone-ACME-SV, State: enabled, Index: 5, Scope Policy: 0, Sequence
number: 1
Applications: any
Action: permit
From zone: ACME-SV, To zone: untrust
Policy: internet-ACME-SV, State: enabled, Index: 8, Scope Policy: 0, Sequence
number: 1
Applications: any
Action: permit
From zone: untrust, To zone: Juniper-SV

Junos Security
Policy: Juniper-SV-to-Juniper-WF, State: disabled, Index: 9, Scope Policy: 0,
Sequence number: 1
Destination addresses: vr105
Applications: internal-apps
Action: permit, log, scheduled
Question: What is the total number of active

security policies on your assigned device?
Answer: You should see a total of six enabled

security policies. If you do not see six enabled
security policies, review your configuration steps.
Question: What command can you use to view more

detailed information about security policies such as
the address book prefixes and application port
information?
Answer: Use the same command with the detail

option to view a more verbose output:
lab@srxC-1> show security policies ?

<[Enter]> Execute this command
application-firewall Show the information of application-firewall
count Number of policies to show (1..65535)
detail Show the detailed information
from-zone Show the policy information matching the given source zone
global Show the policy information of global policies
hit-count Show the hit count of policies
policy-name Show the policy information matching the given policy name
start Show the policies from a given position (1..65535)
to-zone Show the policy information matching the given destination
zone
zone-context Show the count of policies in each context (from-zone and
to-zone)
| Pipe through a command
lab@srxC-1> show security policies detail
Policy: interazone-Juniper-SV, action-type: permit, State: enabled, Index: 4,
Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: Juniper-SV, To zone: Juniper-SV
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Destination addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0

Junos Security
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No
Policy: deny-ftp-Juniper-SV, action-type: reject, State: enabled, Index: 7,
Scope Policy: 0
Sequence number: 1
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Policy: internet-Juniper-SV, action-type: permit, State: enabled, Index: 6,
Scope Policy: 0
Sequence number: 2
Source addresses:
vr105: 172.20.105.0/24
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: any
Policy: intrazone-ACME-SV, action-type: permit, State: enabled, Index: 5, Scope
Policy: 0
Sequence number: 1
From zone: ACME-SV, To zone: ACME-SV
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: any
Policy: internet-ACME-SV, action-type: permit, State: enabled, Index: 8, Scope
Policy: 0

Junos Security
Sequence number: 1
From zone: ACME-SV, To zone: untrust
Source addresses:
vr205: 172.20.205.0/24
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: any
Policy: Juniper-SV-to-Juniper-WF, action-type: permit, State: disabled, Index:
9, Scope Policy: 0
Sequence number: 1
From zone: untrust, To zone: Juniper-SV
Source addresses:
vr106: 172.20.106.0/24
vr105: 172.20.105.0/24
Application: internal-apps
IP protocol: udp, ALG: 0, Inactivity timeout: 60
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
ICMP Information: type=255, code=0
Session log: at-create, at-close
Scheduler name: internal-apps-scheduler
Step 4.3
Issue the show schedulers command and answer the following questions.
lab@srxC-1> show schedulers
Scheduler name: internal-apps-scheduler, State: active
Next deactivation: Mon Jun 11 23:00:00 2012
Question: Is the scheduler you configured in an

active state?
Answer: As illustrated by the output from srxC-1, the

scheduler should be in an active state. If the
scheduler is not currently active, check the time
settings on your assigned device.

Junos Security
Question: When will the scheduler deactivate?
Answer: The scheduler should deactivate at

18:00 hours. At this time, any policies associated
with this scheduler also deactivate
Step 4.4
From the Telnet session established with the virtual router, open a Telnet session
between the virtual router associated with your local Juniper zone and the virtual
router associated with the remote Juniper zone. Be sure to source the Telnet session
from the appropriate routing instance. Log in with the same username and
password as your current session.
c1@vr-device> telnet remote-Juniper-VR routing-instance local-Juniper-VR
Trying 172.20.106.10...
Escape character is '^]'.
vr-device(ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>
Step 4.5
From the Telnet session established with assigned SRX device, issue the
show security flow session command.
lab@srxC-1> show security flow session
Session ID: 24149, Policy name: Juniper-SV-to-Juniper-WF/9, Timeout: 1766,
Valid
In: 172.20.106.10/51545 --> 172.20.105.10/23;tcp, If: ge-0/0/3.0, Pkts: 27,
Bytes: 1567
Out: 172.20.105.10/23 --> 172.20.106.10/51545;tcp, If: ge-0/0/4.105, Pkts: 22,
Bytes: 1596
Session ID: 23920, Policy name: self-traffic-policy/1, Timeout: 28, Valid

In: 172.18.1.2/55672 --> 208.87.233.170/9020;udp, If: .local..0, Pkts: 1,
Bytes: 132
Out: 208.87.233.170/9020 --> 172.18.1.2/55672;udp, If: ge-0/0/3.0, Pkts: 0,
Bytes: 0

Junos Security
Session ID: 23925, Policy name: internet-Juniper-SV/6, Timeout: 1786, Valid
In: 172.20.105.10/51381 --> 172.20.106.10/23;tcp, If: ge-0/0/4.105, Pkts: 27,
Bytes: 1567
Out: 172.20.106.10/23 --> 172.20.105.10/51381;tcp, If: ge-0/0/3.0, Pkts: 22,
Bytes: 1596
Total sessions: 3
Question: What is the session ID for the Telnet

session you opened?
Answer: The answer varies, but in the output from

srxC-1, the session ID is 24149.
Step 4.6
Using the session ID, view a more detailed output of the open Telnet session and
answer the following question. Use the session ID identified in the previous step.
lab@srxC-1> show security flow session session-identifier session-id
Session ID: 24149, Status: Normal
Flag: 0x40
Policy name: Juniper-SV-to-Juniper-WF/9
Source NAT pool: Null, Application: junos-telnet/10
Dynamic application: junos:UNKNOWN,
Maximum timeout: 1800, Current timeout: 1716
Session State: Valid
Start time: 112401, Duration: 91
In: 172.20.106.10/51545 --> 172.20.105.10/23;tcp,
Interface: ge-0/0/3.0,
Session token: 0xa, Flag: 0x21
Route: 0x110010, Gateway: 172.18.1.1, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 27, Bytes: 1567
Out: 172.20.105.10/23 --> 172.20.106.10/51545;tcp,
Interface: ge-0/0/4.105,
Session token: 0x7, Flag: 0x20
Route: 0x120010, Gateway: 172.20.105.10, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 22, Bytes: 1596
Total sessions: 1
Question: How many seconds remain before the

Telnet session times out (without further activity)?
Answer: The answer varies, but in the output from

srxC-1, 1716 seconds remain. If there is no further
activity during this period, the session closes.

Junos Security
Step 4.7
From the Telnet session established with the virtual router, end the open Telnet
session by entering the exit command.
c1@vr-device> exit
Connection closed by foreign host.
c1@vr-device>
Step 4.8
From the Telnet session established with assigned SRX device, view the
configuration hierarchy associated with the syslog settings.
lab@srxC-1> show configuration system syslog
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
Question: Is your devices syslog configuration

sufficient to record security policy log actions?
Answer: Yes. Recall from the classroom discussion

that on branch security platforms running the Junos
operating system, local data plane logging is
enabled by configuring a local syslog with a facility
of user and a severity of info. Because the file
messages configuration logs any facility at any
severity, security policies that are configured with a
log action should automatically record entries in the
messages log file.
Step 4.9
View security policy log entries by issuing the show log messages | match
RT_FLOW command.

Junos Security
Note
Recall that the security policy log action
configuration was only for specific traffic
ingressing your assigned device from the
untrust zone. To see log entries, you must
ensure the other team in your pod has
initiated (and exited) the Telnet session
associated with this lab part.
lab@srxC-1> show log messages | match RT_FLOW

Nov 4 16:22:00 srxC-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
172.20.108.10/52298->172.20.107.10/23 junos-telnet 172.20.108.10/
52298->172.20.107.10/23 None None 6 Juniper-WF-to-Juniper-SV untrust
Juniper-SV 14965
Nov 4 16:22:05 srxC-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:
172.20.108.10/52298->172.20.107.10/23 junos-telnet 172.20.108.10/
52298->172.20.107.10/23 None None 6 Juniper-WF-to-Juniper-SV untrust
Juniper-SV 14965 13(828) 12(823) 2
Nov 4 16:29:40 srxC-1 mgd[64844]: UI_CMDLINE_READ_LINE: User 'lab', command
'show log messages | match RT_FLOW '
Question: Do you see the appropriate log entries

recording the opening and closing of the remote
teams Telnet session?
Answer: Provided the remote team is keeping up

with your team, the answer should be yes.
Step 4.10
Issue the show interfaces extensive command for the ge-0/0/3 interface.
lab@srxC-1> show interfaces extensive ge-0/0/3
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Interface index: 137, SNMP ifIndex: 509, Generation: 140
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Hold-times : Up 0 ms, Down 0 ms
Current address: 00:26:88:02:70:83, Hardware address: 00:26:88:02:70:83
Last flapped : 2012-06-08 18:58:16 UTC (2d 19:26 ago)
Statistics last cleared: Never
Traffic statistics:
Junos Security
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0,
FIFO errors: 0, Resource errors: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 395537 395537 0
1 expedited-fo 0 0 0
2 assured-forw 0 0 0
3 network-cont 0 0 0
Queue number: Mapped forwarding classes
0 best-effort
1 expedited-forwarding
2 assured-forwarding
3 network-control
Active alarms : None
Active defects : None
MAC statistics: Receive Transmit
Total octets 154136086 148687961
Total packets 409029 395537
Unicast packets 407893 395491
Broadcast packets 1135 46
Multicast packets 1 0
CRC/Align errors 0 0
FIFO errors 0 0
MAC control frames 0 0
MAC pause frames 0 0
Oversized frames 0
Jabber frames 0
Fragment frames 0
VLAN tagged frames 0
Code violations 0
Filter statistics:
Input packet count 0
Input packet rejects 0
Input DA rejects 0
Input SA rejects 0
Output packet count 0
Output packet pad count 0
Output packet error count 0
CAM destination filters: 2, CAM source filters: 0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: None, Remote fault: OK,
Link partner Speed: 1000 Mbps
Local resolution:
Flow control: None, Remote fault: Link OK
Packet Forwarding Engine configuration:
Destination slot: 0
CoS information:

Junos Security
Direction : Output
CoS transmit queue Bandwidth Buffer Priority
Limit
% bps % usec
0 best-effort 95 950000000 95 0 low none
3 network-control 5 50000000 5 0 low none
Interface transmit statistics: Disabled
Logical interface ge-0/0/3.0 (Index 67) (SNMP ifIndex 516) (Generation 144)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Traffic statistics:
Output bytes : 45741
Input packets: 3829
Output packets: 425
Local statistics:
Input bytes : 16796
Output bytes : 38756
Input packets: 299
Output packets: 306
Transit statistics:
Security: Zone: untrust
Flow Statistics :
Self packets : 286
ICMP packets : 291
VPN packets : 0
Address spoofing: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No tunnel found: 0
Policy denied: 0

Junos Security
Flags: Sendbcast-pkt-to-re
Destination: 172.18.1.0/30, Local: 172.18.1.2, Broadcast: 172.18.1.3,
Generation: 162
Question: What is the value of the Policy

denied counter within the interface flow
statistics?
Answer: The answer might vary, but in the output

taken from srxC-1, the value is 0. The purpose of
this question is to establish a baseline value.
Step 4.11
From the Telnet session established with the virtual router, issue a Telnet session to
the remote virtual router associated with your partner teams Juniper zone. But this
time, source the Telnet session from the virtual router associated with your local
ACME zone.
c1@vr-device> telnet remote-Juniper-VR routing-instance local-ACME-VR
Trying 172.20.106.10...
^C
c1@vr-device>
Question: Was the Telnet session successful?
Answer: The Telnet session should not be

successful. The active security policies applied to
traffic from the untrust zone on the remote teams
device do not allow this traffic.
STOP Ensure that the remote student team within your pod has finished the
previous step before proceeding.
Step 4.12
Once this has been confirmed, return to your assigned device and issue the
show interfaces extensive command for the ge-0/0/3 interface again.
lab@srxC-1> show interfaces extensive ge-0/0/3 | find "Flow Statistics"
Flow Statistics :

Junos Security
Self packets : 298
ICMP packets : 303
VPN packets : 0
Address spoofing: 0
No minor session: 0
No more sessions: 0
No NAT gate: 0
No route present: 0
No tunnel found: 0
Policy denied: 2107
Flags: Sendbcast-pkt-to-re
Destination: 172.18.1.0/30, Local: 172.18.1.2, Broadcast: 172.18.1.3,
Generation: 162
Question: Did the value of the Policy denied

counter increment?
Answer: The answer should be yes. In the output

taken from srxC-1, the value is 2107. Previously, this
value was 0.

Lab 3
Configuring Firewall Authentication (Detailed)
Overview
In this lab, you will implement firewall user authentication. You will enable FTP access
between networks and secure the access with authentication. You will test and monitor
the effects of firewall user authentication. The configuration tasks performed within this
lab and subsequent labs will build upon one another.
Define clients within an access profile.
Create a default client group and associate clients with the group.
Configure firewall user authentication parameters.
Add and alter security policies that have an extended permit action specifying
firewall user authentication.
Monitor the effects of your configuration using operational mode commands
and traceoptions.
www.juniper.net Configuring Firewall Authentication (Detailed) Lab 31

12.a.12.1R1.9
Junos Security
Part 1: Configuring Firewall User Authentication
In this lab part, you define clients within an access profile, create a default client
group and associate clients with the group, and configure firewall user
authentication parameters.
Step 1.1


lab are for srxA-1, which uses 10.210.35.131 as its
Step 1.2
Step 1.3
configuration and exit to operational mode when complete.
srxA-1 (ttyu0)
login: lab
Password:
Lab 32 Configuring Firewall Authentication (Detailed) www.juniper.net

Junos Security
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxA-1> configure
[edit]
lab@srxA-1# load override jsec/lab3-start.config
load complete
[edit]
commit complete
lab@srxA-1>
Step 1.4
Navigate to the [edit access] hierarchy.
[edit]
lab@srxA-1# edit access
[edit access]
lab@srxA-1#
Step 1.5
Create an access profile named ftp-users. Configure two clients named walter
and nancy with passwords of walter123 and nancy123, respectively.
[edit access]
lab@srxA-1# edit profile ftp-users
[edit access profile ftp-users]

lab@srxA-1# set client walter firewall-user password walter123

lab@srxA-1# set client nancy firewall-user password nancy123

lab@srxA-1# up
[edit access]
lab@srxA-1# show
profile ftp-users {
client nancy {
firewall-user {
password "$9$lJ8vLNdVYZUHKMi.PfzFcyrvX7"; ## SECRET-DATA
}
}
client walter {
firewall-user {
password "$9$a1UqfTQnApB36pBREKv4aJUk.5QF"; ## SECRET-DATA
}
}
}

Junos Security
Step 1.6
Associate all clients in the ftp-users profile with a client group named
ftp-group.
[edit access]
lab@srxA-1# set profile ftp-users session-options client-group ftp-group
[edit access]
lab@srxA-1# show
profile ftp-users {
client nancy {
firewall-user {
password "$9$lJ8vLNdVYZUHKMi.PfzFcyrvX7"; ## SECRET-DATA
}
}
client walter {
firewall-user {
password "$9$a1UqfTQnApB36pBREKv4aJUk.5QF"; ## SECRET-DATA
}
}
session-options {
client-group ftp-group;
}
}
Question: What method of associating clients with

client groups requires the least amount of
keystrokes for this scenario?
Answer: You can specify client groups individually

with each client. However when all clients within an
access profile have the same requirements, the
most efficient method would be to assign a default
client group as shown in the example.
Step 1.7
Associate the ftp-users profile with pass-through firewall user authentication.
[edit access]
lab@srxA-1# edit firewall-authentication
[edit access firewall-authentication]

lab@srxA-1# set pass-through default-profile ftp-users

lab@srxA-1# show
pass-through {
default-profile ftp-users;
}

lab@srxA-1#

Junos Security
Step 1.8
Create custom banners for FTP users. Configure your device to display Junos
Rocks! when firewall authentication users are prompted for the username and
password.
Note
The Junos operating system allows multiple
words in banners, descriptions, and
annotations by enclosing the phrase in
quotation marks.

lab@srxA-1# set pass-through ftp banner login "Junos Rocks!"

lab@srxA-1# show
pass-through {
default-profile ftp-users;
ftp {
banner {
login "Junos Rocks!";
}
}
}
Step 1.9
The nancy and walter clients need FTP access bi-directionally between your local
Juniper customer network and the remote teams Juniper customer network zones.
This access should be authenticated using pass-through firewall user authentication
and the access should be available at all times. Review the lab diagram and your
configuration and answer the question that follows.
lab@srxA-1# top
[edit]
lab@srxA-1# edit security policies

lab@srxA-1# show | no-more
from-zone Juniper-SV to-zone Juniper-SV {
policy intrazone-Juniper-SV {
match {
source-address any;
application any;
}
then {
permit;
}
}
}
from-zone ACME-SV to-zone ACME-SV {
policy intrazone-ACME-SV {

Junos Security
match {
source-address any;
application any;
}
then {
permit;
}
}
}
from-zone Juniper-SV to-zone untrust {
match {
source-address any;
}
then {
reject;
}
}
policy internet-AMCE-SV {
match {
application any;
}
then {
permit;
}
}
}
from-zone ACME-SV to-zone untrust {
policy internet-ACME-SV {
match {
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone Juniper-SV {
match {
}
then {
permit;
log {
session-init;

Junos Security
session-close;
}
}
}
}

lab@srxA-1#
Question: What security policy changes must you

make to accommodate this access?
Answer: The answer varies depending upon your

assigned device. Both devices in your pod require
two new security policies. Although a policy is
already in place for traffic destined to the untrust
zone from the Juniper-SV and Juniper-WF zones, the
current policy configuration prohibits FTP traffic.
You must define a new security policy for the FTP
traffic destined to the untrust zone. Insert the policy
before the deny-ftp policy. A policy is also in
place for traffic destined to the Juniper-SV and
Juniper-WF zones from the untrust zone, but this
policy is specific to an application set that does not
include FTP traffic.
Step 1.10
Define a security policy to allow the nancy client and walter client FTP access
from your local Juniper customer network zone to the remote student teams Juniper
customer network zone. Configure the source-address to match the address-set
for your local Juniper customer network. For your policys destination-address
match, use the existing address book entry for the remote student teams Juniper
customer network.
lab@srxA-1# edit from-zone Juniper-local to-zone untrust policy
outbound-ftp-auth

outbound-ftp-auth]
lab@srxA-1# set match source-address local-Juniper-vrName

outbound-ftp-auth]
lab@srxA-1# set match destination-address remote-Juniper-vrName

outbound-ftp-auth]
lab@srxA-1# set match application junos-ftp

Junos Security

outbound-ftp-auth]
lab@srxA-1# set then permit

outbound-ftp-auth]
lab@srxA-1# show
match {
}
then {
permit;
}
Step 1.11
Navigate to the [edit security policies from-zone Juniper-local
to-zone untrust] hierarchy. Issue the show command, review the output, and
answer the question below.

outbound-ftp-auth]
lab@srxA-1# up

lab@srxA-1# show
match {
source-address any;
}
then {
reject;
}
}
match {
application any;
}
then {
permit;
}
}
policy outbound-ftp-auth {
match {
}

Junos Security
then {
permit;
}
}
Question: Is any policy reordering necessary for the

outbound-ftp-auth security policy?
Answer: Yes. The first policy in the list denies the

FTP traffic that you want to allow.
Step 1.12
Insert the outbound-ftp-auth policy before the deny-ftp-Juniper-local
policy.
lab@srxA-1# insert policy outbound-ftp-auth before policy
deny-ftp-Juniper-local

lab@srxA-1# show
policy outbound-ftp-auth {
match {
}
then {
permit;
}
}
match {
source-address any;
}
then {
reject;
}
}
match {
application any;
}
then {
permit;
}
}

Junos Security
Step 1.13
Navigate to the [edit security policies from-zone Juniper-SV to-zone
untrust] hierarchy. Configure a policy named inbound-ftp-auth to allow the
nancy client and walter client FTP access from the remote student teams
Juniper customer network zone to your local Juniper customer network zone.
Configure the source-address to match the address-set for the remote student
teams Juniper customer network. For your policys destination-address
match, use the existing address book entry for your local Juniper customer network.
Ensure that this session authenticates using pass-through firewall authentication.
The firewall authentication should be performed only for traffic coming from the
untrust zone to avoid double authentication.
lab@srxA-1# up

lab@srxA-1# edit from-zone untrust to-zone Juniper-local policy
inbound-ftp-auth
[edit security policies from-zone untrust to-zone Juniper-SV policy

inbound-ftp-auth]
lab@srxA-1# set match source-address remote-Juniper-vrName

inbound-ftp-auth]
lab@srxA-1# set match destination-address local-Juniper-vrName

inbound-ftp-auth]
lab@srxA-1# set match application junos-ftp

inbound-ftp-auth]
lab@srxA-1# set then permit firewall-authentication pass-through client-match
ftp-group
Step 1.14
Navigate to the [edit security policies from-zone untrust to-zone
Juniper-local] hierarchy. Issue the show command, review the output, and
answer the question below.
inbound-ftp-auth]
lab@srxA-1# up

lab@srxA-1# show
match {
}
then {

Junos Security
permit;
log {
session-init;
session-close;
}
}
}
policy inbound-ftp-auth {
match {
}
then {
permit {
firewall-authentication {
pass-through {
client-match ftp-group;
}
}
}
}
}
Question: Is any policy reordering necessary for the

inbound-ftp-auth security policy?
Answer: No. The first policy under the associated

context does not match on FTP traffic. Therefore
FTP traffic passes to the next policy in the chain.
Recall that traffic matching no policies under a
given context associates with the default policy.
Step 1.15
Commit your configuration and return to operational mode.
commit complete
lab@srxA-1>
assigned pod have reached this point.

Junos Security
Part 2: Verifying and Monitoring Firewall User Authentication
In this lab part, you verify the results of your configuration through testing. You will
also monitor firewall user authentication using traceoptions and operational mode
commands.
Step 2.1
[edit]
load complete
[edit]
lab@srxA-1# commit
commit complete
Step 2.2
Note
This lab step requires you to open a
separate Telnet session to the virtual router
to emulate an external host.
Keep the current Telnet session
established with your assigned SRX device
open to monitor results.
The virtual router is a J Series Services
Router configured as several logical
devices. Refer to the Management Network

Junos Security
Step 2.3
Student Device User Name Password

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
a1@vr-device>
Step 2.4
From the Telnet session established with the virtual router, initiate an FTP session
between the virtual router associated with your local Juniper customer network zone
and the virtual router associated with the remote student teams Juniper customer
network zone. Note that the ftp command is hidden and does not auto-complete.
Remember to source the command from the appropriate routing instance. When
prompted for firewall user authentication, use the credentials you created for the
user nancy.
a1@vr-device> ftp remote-Juniper-VR routing-instance local-Juniper-VR
220 Junos Rocks!
Name (172.20.108.10:d1): nancy
331 Password Required
Password:
Authentication - Accepted (Closed connection - reconnect to server)
ftp: Login failed.
421 Service not available, remote server has closed connection.
ftp>

Junos Security
Question: Was the authentication successful? What
behavior did you observe?
Answer: Although the FTP session failed,

authentication was indeed successful. In the
Junos OS, for FTP sessions, the observed behavior
is expected. For FTP traffic only, the session needs
to be re-initiated after performing firewall
authentication.
Note
If you test the FTP connection multiple
times, the remote student device will need
to clear out the firewall authentication user
session by issuing the operational-mode
command clear security
firewall-authentication users.
Step 2.5
Note
Check with the remote team in your pod
and ensure they have completed the
previous step.
From the Telnet session established with your assigned SRX device, issue the show
security firewall-authentication users command.
lab@srxA-1> show security firewall-authentication users
Firewall authentication data:
Total users in table: 1
Id Source Ip Src zone Dst zone Profile Age Status User
3 172.20.102.10 untrust Juniper-SV ftp-user 1 Success nancy
Question: What does the output for this command

indicate?
Answer: The output indicates that nancy

successfully authenticated. Keep in mind that the
Junos OS generates this output because the remote
team attempted to establish an FTP session
through your student device to the directly attached
virtual router. If you do not see the user nancy in
the output, check with the remote team.

Junos Security
Step 2.6
From the Telnet session established with the virtual router, attempt the FTP session
again. If your previous FTP session appears to be hung up, disconnect and
reconnect to the vr-device. Log in to the FTP server using your assigned username
and password for the vr-device. If needed, refer to the table provided in Step 2.2.
(Hint: Use the FTP bye command to exit the service at the ftp> prompt.)
Note
Because the previous firewall
authentication did not result in an
established FTP session, the
authentication might have timed out. In this
case, perform the firewall authentication
again and re-initiate the FTP session
immediately thereafter.
ftp> bye

Name (172.20.102.10:root): username
331 Password required for a1.
Password:
230 User a1 logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Question: Were you able to successfully establish

an FTP session?
Answer: As shown in the output, you should now be

able to successfully establish the FTP session.
Step 2.7
Leave the current session with the vr-device open and open a second session to the
vr-device using Telnet. Refer to the Management Network Diagram as needed.
vr-device (ttyp1)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC

Junos Security
a1@vr-device>
Step 2.8
Attempt another FTP session using the same procedure. This time, use the walter
username for firewall authentication and log into the FTP server with your vr-device
credentials.
Name (172.20.102.10:a1): walter
331 Password required for walter.
Password:
530 Login incorrect.
ftp: Login failed.
ftp> bye
221 Goodbye.

Name (172.20.102.10:a1): username
331 Password required for a1.
Password:
230 User a1 logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Question: Could you successfully authenticate with

the username walter and establish an
FTP session?
Answer: If you tried to login with the username

walter, the login will fail. The FTP session is
actually successful. However no prompt for firewall
authentication occurs for this session. Recall that
as long as an authenticated session remains active,
any subsequent traffic from the same source
IP address bypasses firewall authentication.
Step 2.9
Exit both FTP sessions and close the second session you opened to the vr-device.
ftp> bye
a1@vr-device>
ftp> bye
a1@vr-device> exit
Junos Security
Step 2.10
From the Telnet session established with your assigned SRX device, clear the entries
in the firewall authentication users table, if any exist.
lab@srxA-1> clear security firewall-authentication users

Step 2.11
Note
previous step.

From the Telnet session established with the virtual router, attempt another
FTP session between your local Juniper customer zone and the remote teams
Juniper customer zone. When you are prompted for the firewall authentication, use a
username of john and a password of doe.
220 Junos Rocks!
Name (172.20.102.10:d1): john
331 Password Required
Password:
Authentication - Failed
ftp: Login failed.
421 Service not available, remote server has closed connection.
ftp>
Step 2.12
Exit the FTP session with the bye command and return to your assigned student
device.
ftp> bye
Step 2.13
Note
previous step.
security firewall-authentication users command followed by the
show security firewall-authentication history command.

Junos Security
Id Source Ip Src zone Dst zone Profile Age Status User
3 172.20.102.10 untrust Juniper- ftp-user 1 Failed john
lab@srxA-1> show security firewall-authentication history

History of firewall authentication data:
Authentications: 6
Id Source Ip Date Time Duration Status User
1 172.20.102.10 2012-06-14 03:11:21 0:10:06 Success nancy
2 172.20.102.10 2012-06-14 03:17:23 0:02:01 Success nancy
3 172.20.102.10 2012-06-14 03:22:59 0:11:58 Success walter
4 172.20.102.10 2012-06-14 03:26:02 0:01:33 Success walter
5 172.20.102.10 2012-06-01 03:27:40 0:02:08 Success walter
6 172.20.102.10 2012-06-01 03:29:55 0:01:07 Failed john
Question: Are any failed authentication attempts

listed in the outputs?
Answer: The outputs may vary, but provided the

remote team within your pod attempted an
FTP session with the username john, at least one
failed attempt should be listed.
Question: What is the source IP address of the

failed authentication attempts?
Answer: The answer varies but the failed attempts

should have a source IP address representing the
virtual router of the neighboring teamsfrom the
Juniper-SV or Juniper-WF zone.
Step 2.14
View the firewall user authentication entries in your data plane log by issuing the
show log messages | match RT_AUTH command.
Note
If the remote team has not performed the
required verification tasks, you will not see
any logs. To view log entries from the
remote device, reference the name of the
remote device instead of your devices
name in the previous sample command.

Junos Security
lab@srxA-1> show log messages | match RT_AUTH
Jun 14 03:22:24 srxA-1 RT_AUTH: FWAUTH_FTP_USER_AUTH_ACCEPTED: User nancy of
group ftp-group at 172.20.102.10 is accepted.
Jun 14 03:37:48 srxA-1 RT_AUTH: FWAUTH_FTP_USER_AUTH_FAIL: User john at
172.20.102.10 is rejected.
Jun 14 03:56:09 srxA-1 mgd[1262]: UI_CMDLINE_READ_LINE: User 'lab', command
'show log messages | match RT_AUTH '
Question: What additional information can you

derive from the data plane security log?
Answer: The security log shows the authentication

attempts were made using FTP as well as the
source address, username, and firewall
authentication action.

Junos Security

Lab 4
Implementing Screen Options (Detailed)
Overview
In this lab, you will implement the Junos operating system Screen options. You will set up
various Screens to protect your assigned device from suspicious or malicious traffic
entering your device from the untrust zone.
Define various Screen options (called ids-options).
Associate the Screen with a security zone.
Test your your implementation.
www.juniper.net Implementing Screen Options (Detailed) Lab 41

12.a.12.1R1.9
Junos Security
Part 1: Accessing Your Device and Configuring Screen Protection
in to your designated station. Then, you will load the starting configuration for Lab 4.
Then, In this lab part, you will configure Screen protection.
Note
assigned device.
Step 1.1


IP address of 10.210.14.135.
Step 1.2
Lab 42 Implementing Screen Options (Detailed) www.juniper.net

Junos Security
Step 1.3
srxC-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 1.4
Navigate to the [edit security screen] hierarchy.
[edit]
lab@srxC-1# edit security screen
[edit security screen]

lab@srxC-1#
Step 1.5
Create a Screen that blocks ICMP packets larger than 1024 bytes. Name the Screen
internet-protect.
lab@srxC-1# set ids-option internet-protect icmp large

lab@srxC-1# show
ids-option internet-protect {
icmp {
large;
}
}
Step 1.6
Within the same Screen option, configure the Screen to block ICMP fragments.
lab@srxC-1# set ids-option internet-protect icmp fragment

Junos Security
lab@srxC-1# show
icmp {
fragment;
large;
}
}
Question: Can you recall a common type of attack

blocked by this Screen from the class discussion?
Answer: Enabling protection from ICMP packets

larger than 1024 bytes and from fragmented ICMP
packets provides protection from ICMP Ping of
Death attacks. An ICMP Ping of Death attack occurs
when ping packets are sent to a host in excess of
the maximum IP packet size of 65,535 bytes. These
packets are typically fragmented.
Step 1.7
Add protection from packets that are using the IP Record Route option to the
internet-protect Screen.
lab@srxC-1# set ids-option internet-protect ip record-route-option

lab@srxC-1# show
icmp {
fragment;
large;
}
ip {
record-route-option;
}
}
Step 1.8
Add additional protection that limits the number of sessions to the same destination
IP address to a maximum of one session. Activate the configuration changes by
issuing the commit command.
lab@srxC-1#
set ids-option internet-protect limit-session destination-ip-based 1

lab@srxC-1# show

Junos Security
icmp {
fragment;
large;
}
ip {
record-route-option;
}
limit-session {
destination-ip-based 1;
}
}

lab@srxC-1# commit
commit complete
STOP Before proceeding, ensure that the remote team within your pod is
ready to continue on to Part 2.
Part 2: Verifying Screen Protection
In this lab part, you verify the results of your Screen configuration
Note
Step 2.1
lab@srxC-1# top
[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#

Junos Security
Step 2.2
Step 2.3
Log in to the vr-device using the login information shown in the following table:

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>

Junos Security
Step 2.4
Initiate a ping between the virtual router in the Juniper-local zone and the virtual
router in the Juniper-remote zone.
Note
Remember to reference the appropriate
instance name when sourcing ICMP traffic
from a virtual router. The instance names
match the names of the virtual routers
listed on the network diagram.

PING 172.20.106.10 (172.20.106.10): 56 data bytes
!!!!!
--- 172.20.106.10 ping statistics ---
Question: Was the ping successful? What size does

an ICMP echo request packet use by request?
Answer: The ping should succeed as shown in the

output. An ICMP echo request consists of a data
size of 56 bytes, plus an ICMP header size of
8 bytes. The output does not show the additional
Ethernet overhead of 20 bytes.
Step 2.5
Issue the same ping request again, but this time specify a size of 1100 bytes. This
size is larger than 1024 bytes and should trigger the ICMP large Screen option,
provided the remote team properly configured it on their device.
size 1100
PING 172.20.106.10 (172.20.106.10): 1100 data bytes
!!!!!
--- 172.20.106.10 ping statistics ---

Junos Security
Question: What is the result of the ping operation
with a specified size of 1100 bytes? Are the results
expected?
Answer: The output indicates the ping was

successful and something is amiss regarding the
Screen options configuration. The results are
expected. Although the configuration contains the
appropriate Screen options, the Screen options
have not yet been applied to a security zone.
Step 2.6
From the Telnet session established with assigned SRX device, apply the
internet-protect Screen option to the untrust security zone. Commit your
configuration and exit configuration mode.
[edit]

lab@srxC-1# set screen internet-protect

lab@srxC-1# show
address-book {
address vr108 172.20.108.0/24;
address vr208 172.20.208.0/24;
address srxC-2 172.18.2.0/30;
}
screen internet-protect;
interfaces {
ge-0/0/3.0;
}

commit complete
lab@srxC-1>

Junos Security
Step 2.7
From the Telnet session established with the virtual router, repeat the ping
command between the virtual routers associated with the Juniper-local and
Juniper-remote security zones. Once again, specify a size of 1100 bytes.
size 1100
PING 172.20.106.10 (172.20.106.10): 1100 data bytes
.....
--- 172.20.106.10 ping statistics ---
Question: What is the result of the ping operation

with a specified size of 1100 bytes? Are the results
expected?
Answer: The output indicates the ping was not

successful. This behavior is expected and
demonstrates the ICMP large Screen option is
working as designed.
Step 2.8
Determine the physical maximum transmission unit (MTU) of your virtual routers
interface (associated with the your local Juniper zone) that connects to your
assigned device by issuing the show interfaces ge-0/0/1 media |
match mtu command.
c1@vr-device> show interfaces ge-0/0/1 media | match mtu
BPDU Error: None, MAC-REWRITE Error: None,
Question: What is the physical MTU size of the

interface?
Answer: The output indicates the physical MTU is

1518 bytes.
Step 2.9
Issue another ping between the virtual routers associated with the
Juniper-local and Juniper-remote security zones. This time specify a size
of 2000 bytes, ensuring ICMP packet fragmentation occurs. Do not forget to source
the ping from the proper routing instance!
size 2000
PING 172.20.106.10 (172.20.106.10): 2000 data bytes

Junos Security
.....
--- 172.20.106.10 ping statistics ---
Question: What is the result of the ping specifying a

size of 2000 bytes? Are the results expected?

demonstrates the ICMP fragment Screen option is
working as designed.
Step 2.10
Issue another ping between the virtual routers associated with the
Juniper-local and Juniper-remote security zones. This time specify the
record-route option.
record-route
PING 172.20.106.10 (172.20.106.10): 56 data bytes
.....
--- 172.20.106.10 ping statistics ---
Question: What is the result of the ping specifying

the record-route option? Are the results
expected?

demonstrates the ICMP record route Screen option
is working as designed.
Step 2.11
Within your current vr-device Telnet session, open a new Telnet session to the
remote virtual router associated with the Juniper-local and
Juniper-remote security zones. Use the same login credentials as used for your
current vr-device Telnet session.
Note
instance name when sourcing Telnet traffic

Junos Security
Trying 172.20.108.10...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>
Question: Was the Telnet session successfully

established?
Answer: As indicated in the output, the Telnet

session should successfully establish.
Step 2.12
Open a new, separate Telnet session to the vr-device.

Junos Security
Step 2.13

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>
Step 2.14
Within the new vr-device session, attempt to open a second Telnet connection
between the virtual routers associated with the Juniper-local and
Juniper-remote security zones.
Note

Trying 172.20.108.10...
telnet: connect to address 172.20.108.10: Operation timed out
telnet: Unable to connect to remote host

Junos Security
Question: Did the second Telnet session between
the remote virtual routers successfully establish? Is
the result expected?

session is unable to establish. This result is
expected and demonstrates the destination-based
session limit is in effect.
Note
Leave both Telnet sessions opened to the
vr-device for the time being. You return to
these sessions in the next part of the lab.
STOP Before proceeding, ensure that the remote team within your pod is
ready to continue on to Part 3.
Part 3: Monitoring Screen Protection
In this lab part, you monitor the effects of Screen protection. You must coordinate
some of the monitoring efforts with the remote student team in your pod.
Step 3.1
From the Telnet session established with assigned SRX device, enter configuration
mode, or go to the top of the configuration hierarchy if you are already in
configuration mode, and load the lab4-part3-start.config from the
/var/home/lab/jsec/ directory. Commit the configuration when complete.
lab@srxC-1# top
[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Issue the run show security screen statistics zone untrust
command and review the output.
[edit]
lab@srxC-1# run show security screen statistics zone untrust

Junos Security
Screen statistics:
IDS attack type Statistics

ICMP flood 0
UDP flood 0
TCP winnuke 0
TCP port scan 0
ICMP address sweep 0
TCP sweep 0
UDP sweep 0
IP tear drop 0
TCP SYN flood 0
IP spoofing 0
ICMP ping of death 0
IP source route option 0
TCP land attack 0
TCP SYN fragment 0
TCP no flag 0
IP unknown protocol 0
IP bad options 0
IP record route option 2
IP timestamp option 0
IP security option 0
IP loose source route option 0
IP strict source route option 0
IP stream option 0
ICMP fragment 2
ICMP large packet 4
TCP SYN FIN 0
TCP FIN no ACK 0
Source session limit 0
TCP SYN-ACK-ACK proxy 0
IP block fragment 0
Destination session limit 9
Question: Do any of the listed counters show a

non-zero value?
Answer: Although the counters might vary, the IP

record route option, ICMP fragment option,
ICMP large packet option and the
destination session limit counter should
all have non-zero counters.
Step 3.3
View the Screen option entries in your log by issuing the
run show log messages | match RT_SCREEN command.
[edit]
lab@srxC-1# run show log messages | match RT_SCREEN
Nov 5 14:22:21 srxC-1 RT_IDS: RT_SCREEN_SESSION_LIMIT: Dst IP session limit!
destination: 172.20.107.10, zone name: untrust, interface name: ge-0/0/3.0

Junos Security
Nov 5 14:22:35 srxC-1 RT_IDS: RT_SCREEN_ICMP: Large ICMP packet! source:
172.20.108.10, destination: 172.20.107.10, zone name: untrust, interface
name: ge-0/0/3.0
Nov 5 14:22:53 srxC-1 RT_IDS: RT_SCREEN_ICMP: ICMP fragment! source:
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
name: ge-0/0/3.0
Nov 5 14:23:09 srxC-1 RT_IDS: RT_SCREEN_IP: Record Route IP option! source:
172.20.108.10, destination: 172.20.107.10, protocol-id: 1, zone name:
untrust, interface name: ge-0/0/3.0
Nov 5 14:23:33 srxC-1 mgd[67166]: UI_CMDLINE_READ_LINE: User 'lab', command
'run show log messages | match RT_SCREEN

Junos Security
Question: Have Screen option violations logged to
your security log?
Answer: The answer should be yes. If you do not see

any violations logged, check with the remote team
in your pod to ensure they have completed Part 2 of
the lab.
Step 3.4
Delete the Screen option internet-protect from the [edit security
zone security-zone untrust] configuration hierarchy. Commit the
configuration and return to operational mode.
[edit]

lab@srxC-1# delete screen

lab@srxC-1# show
address-book {
address vr108 172.20.108.0/24;
address vr208 172.20.208.0/24;
address srxC-2 172.18.2.0/30;
}
interfaces {
ge-0/0/3.0;
}

commit complete
lab@srxC-1>
Step 3.5
Return to the Telnet sessions established with the virtual router.
From the Telnet sessions established with the virtual router, attempt to open two
Telnet sessions between the virtual routers associated with the Juniper-local
and Juniper-remote zones again. You must re-establish sessions if any of your
sessions timed out.

Junos Security
Note

Trying 172.20.108.10...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>

Trying 172.20.108.10...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
c1@vr-device>
Question: Can you establish two Telnet sessions

between the remote virtual routers?
Answer: The answer should be yes. Now that the

Screen is no longer in place, no session limits
should be in place.
Junos Security
Step 3.6
Exit the second Telnet session between the remote virtual routers. Next exit the
second Telnet session opened to the vr-device.
c1@vr-device> exit
c1@vr-device> exit
Note
At this point, you should have only one
Telnet session opened to the vr-device.
Step 3.7
Return to the remaining Telnet session that is established with the virtual router.
From the remaining Telnet session established with the virtual router, type exit to
end the Telnet session between the remote virtual routers.
c1@vr-device> exit
c1@vr-device>
Step 3.8
Attempt to ping between the remote virtual routers associated with the
Juniper-local and Juniper-remote zones. Specify a size of 2000 bytes.
Note

size 2000
PING 172.20.106.10 (172.20.106.10): 2000 data bytes
!!!!!
--- 172.20.106.10 ping statistics ---
Question: Can you ping with a size of 2000 bytes

between the remote virtual routers?
Answer: The answer should be yes. Now that the

internet-protect Screen is no longer in place,
no limits should be in place on large or fragmented
ICMP packets.

Junos Security

Junos Security

Lab 5
Network Address Translation (Detailed)
Overview
In this lab, you will implement Network Address Translation (NAT). You will configure and
monitor both source and destination NAT, including pool-based NAT and interface-based
NAT.
Configure and monitor interface-based source NAT.
Configure and monitor pool-based destination NAT.
Configure and monitor pool-based source NAT.
Configure and verify proxy ARP.
www.juniper.net Network Address Translation (Detailed) Lab 51

12.a.12.1R1.9
Junos Security
Part 1: Interface-Based Source NAT
In this lab part, you enable interface-based source NAT. Traffic originating from the
virtual routers attached to your assigned device and destined for the Internet host
will be subject to NAT.
Step 1.1


lab are for srxD-1, which uses 10.210.14.137 as its
Step 1.2
Step 1.3
srxD-1 (ttyu0)
login: lab
Password:
Lab 52 Network Address Translation (Detailed) www.juniper.net

Junos Security
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxD-1> configure
[edit]
lab@srxD-1# load override jsec/lab5-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
[edit]
lab@srxD-1#
Step 1.4
Navigate to the [edit security nat source] hierarchy.
[edit]
lab@srxD-1# edit security nat source
[edit security nat source]

lab@srxD-1#
Step 1.5
Create a rule set named internet-bound. Associate the rule set with a from
context to match traffic from both your local Juniper and ACME customer interfaces.
Also configure the rule set with a to context to match traffic destined to the
untrust zone.
lab@srxD-1# set rule-set internet-bound from interface
ge-0/0/4.local-Juniper-unit

lab@srxD-1# set rule-set internet-bound from interface ge-0/0/4.local-ACME-unit

lab@srxD-1# set rule-set internet-bound to zone untrust
Question: What other contexts could you use for the

from statement?
Answer: You could use a from context referencing

the source security zones, but in this case, two rule
sets would be necessary. Because no configured
routing instances are on your assigned device, the
from routing-instance context is not
applicable to this step.

Junos Security
Step 1.6
Navigate to the [edit security nat source rule-set
internet-bound] configuration hierarchy. Create a NAT rule named 1. The rule
should apply interface-based NAT to all traffic with a destination address of the
Internet host as depicted on your lab diagram.
lab@srxD-1# edit rule-set internet-bound
[edit security nat source rule-set internet-bound]

lab@srxD-1# set rule 1 match destination-address 172.31.15.1/32

lab@srxD-1# set rule 1 then source-nat interface

lab@srxD-1# show
from interface [ ge-0/0/4.107 ge-0/0/4.207 ];
to zone untrust;
rule 1 {
match {
destination-address 172.31.15.1/32;
}
then {
source-nat {
interface;
}
}
}

lab@srxD-1#
Step 1.7
lab@srxD-1# commit and-quit
commit complete
lab@srxD-1>
Note
Step 1.8
Junos Security
Step 1.9

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
d1@vr-device>

Junos Security
Step 1.10
From the Telnet session established with the virtual router, initiate a Telnet session
to the Internet host device. Source the connection from the virtual routers routing
instance associated with your local Juniper customer network. Use the same login
credentials as used for your current vr-device Telnet session.
d1@vr-device> telnet 172.31.15.1 routing-instance VR-Juniper-instance
Trying 172.31.15.1...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
d1@vr-device>
Step 1.11
From the Telnet session established with your assigned SRX device, view the session
table.
lab@srxD-1> show security flow session
Session ID: 58859, Policy name: internet-Juniper-SV/10, Timeout: 1118, Valid
In: 172.20.107.10/65026 --> 172.31.15.1/23;tcp, If: ge-0/0/4.107, Pkts: 27,
Bytes: 1567
Out: 172.31.15.1/23 --> 172.18.1.2/23879;tcp, If: ge-0/0/3.0, Pkts: 22, Bytes:
1596
Total sessions: 1
Question: Do the session table results indicate

expected behavior?
Answer: Yes. As indicated by the output taken from

srxD-1, the Telnet session sources from the internal
IP address 172.20.107.10, but the return traffic has
a destination of the WAN interface address.
Step 1.12
Issue the show security nat source rule all command and answer the
question that follows.

Junos Security
lab@srxD-1> show security nat source rule all
Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 1/0
source NAT rule: 1 Rule-set: internet-bound

Rule-Id 1 :
Rule position 1 :
From interface :
ge-0/0/4.107
:
ge-0/0/4.207
To zone untrust:
Destination addresses :
172.31.15.1 - 172.31.15.1
Destination port 0 : - 0
Action : interface
Persistent NAT type : N/A
Persistent NAT mapping type : address-port-mapping
Inactivity timeout : 0
Max session number : 0
Translation hits : 1
Question: How many hits has this NAT rule

received?
Answer: The answer might vary, but the

Translation hits counter should show one hit
at a minimum.
Step 1.13
From the Telnet session established with the virtual router, exit the extra Telnet
session using the exit command.
d1@vr-device> exit
d1@vr-device>
Part 2: Pool-Based Destination NAT
In this lab part, you configure pool-based destination NAT for traffic originating from
the remote device in your assigned pod. You will use the loopback IP address of your
assigned device as a public address that will be translated to an internal address
belonging to a virtual router attached to your device.
Step 2.1
If necessary, return to your assigned SRX device.
From your assigned SRX device, enter configuration mode, or go to the top of the
configuration hierarchy if you are already in configuration mode, and load the
lab5-part2-start.config from the /var/home/lab/jsec/ directory. Commit
the configuration when complete.
Junos Security
[edit]
lab@srxD-1# load override jsec/lab5-part2-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
Step 2.2
Navigate to the [edit security nat destination] hierarchy.
[edit]
lab@srxD-1# edit security nat destination
[edit security nat destination]

lab@srxD-1#
Step 2.3
Consult your lab diagram to identify the host IP address of the virtual router
associated with your local ACME customer zone. Configure a destination NAT pool
named webserver that specifies the virtual router host address.
lab@srxD-1# set pool webserver address local-ACME-VR-host

lab@srxD-1# show
pool webserver {
address 172.20.207.10/32;
}
Step 2.4
Configure a destination NAT rule set named from-internet. The associated
context should be from the untrust zone.
lab@srxD-1# set rule-set from-internet from zone untrust
Step 2.5
Under the from-internet rule set, configure a destination NAT rule named 1.
The rule should apply destination NAT to traffic that originates from the network
associated with your remote teams ge-0/0/3 interface and that has your loopback
address as its destination. This translation should utilize the webserver pool you
configured.
lab@srxD-1# edit rule-set from-internet rule 1
[edit security nat destination rule-set from-internet rule 1]

lab@srxD-1# set match source-address remote-srx-Internet-subnet

lab@srxD-1# set match destination-address local-loopback-address

Junos Security
lab@srxD-1# set then destination-nat pool webserver

lab@srxD-1# up 2

lab@srxD-1# show
pool webserver {
address 172.20.207.10/32;
}
rule-set from-internet {
from zone untrust;
rule 1 {
match {
source-address 172.18.2.0/30;
destination-address 192.168.1.1/32;
}
then {
destination-nat pool webserver;
}
}
}
Question: Are any changes required to your security

policy configuration to allow this traffic?
Answer: Yes. Currently, no security policy exists in

the configuration that allows traffic from the untrust
zone to your local ACME customer zone.
Step 2.6
In the next two steps, you will create a security policy to allow traffic from the remote
student team destined to your local ACME customer network. Navigate to the [edit
security policy from-zone untrust to-zone ACME-local]
configuration hierarchy.
lab@srxD-1# top edit security policies from-zone untrust to-zone ACME-local
[edit security policies from-zone untrust to-zone ACME-SV]

lab@srxD-1#
Step 2.7
Configure a security policy that allows HTTP and Telnet traffic from the remote
student device in your pod to reach the virtual router associated with your local
ACME customer network. Configure the source-address to match the existing
address book entry configured under the untrust zone for the remote teams
ge-0/0/3 interface subnet. Configure the destination-address to match the
address-book entry for your local ACME customer network. Name the new security
policy webserver.

Junos Security
lab@srxD-1# top show security zones security-zone untrust address-book
address vr108 172.20.108.0/24;
address vr208 172.20.208.0/24;
address srxD-2 172.18.2.0/30;

lab@srxD-1# top show security zones security-zone zone-name address-book
address vr207 172.20.207.0/24;

lab@srxD-1# set policy webserver match source-address remote-srxName

lab@srxD-1# set policy webserver match destination-address local-ACME-vrName

lab@srxD-1# set policy webserver match application junos-telnet

lab@srxD-1# set policy webserver match application junos-http

lab@srxD-1# set policy webserver then permit

lab@srxD-1# show
policy webserver {
match {
source-address srxD-2;
application [ junos-telnet junos-http ];
}
then {
permit;
}
}
Step 2.8
commit complete
STOP Before proceeding, ensure that the remote student team within your
pod is ready to continue on to the next step.

Junos Security
Step 2.9
Note
In this step, you are initiating a Telnet
session directly from your assigned device.
When both teams in your assigned pod finish performing the above configuration,
attempt a Telnet session to the loopback IP address of your remote teams device.
Initiate this Telnet session from your assigned SRX Series device. When prompted
for a login, use the login information shown in the following table:

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
lab@srxD-1> telnet remote-loopback-address

Trying 192.168.2.1...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
d1@vr-device>

Junos Security
Question: From your observations, is destination
NAT operating correctly on your partnering teams
assigned device?
Answer: Provided the Telnet session successfully

established with the vr-device, the output indicates
traffic destined to the remote teams loopback
interface IP address is translating to the
appropriate IP address.
Question: Why did the remote teams assigned

device not respond to the Telnet request instead of
the remote virtual router?
Answer: Recall that destination NAT occurs before

routing and policy checks in the packet flow.
Step 2.10
Open a second Telnet session to your assigned device for monitoring the sessions in
progress. Log in as user lab.
srxD-1 (ttyp0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab@srxD-1>

Junos Security
Step 2.11
Issue the show security flow session command and answer the question
that follows.
In: 172.18.1.2/62411 --> 192.168.2.1/23;tcp, If: .local..0, Pkts: 27, Bytes:
1567
Out: 192.168.2.1/23 --> 172.18.1.2/62411;tcp, If: ge-0/0/3.0, Pkts: 22, Bytes:
1596

In: 10.210.14.133/61579 --> 10.210.14.137/23;tcp, If: ge-0/0/0.0, Pkts: 67,
Bytes: 3672
Out: 10.210.14.137/23 --> 10.210.14.133/61579;tcp, If: .local..0, Pkts: 45,
Bytes: 3211
Session ID: 60937, Policy name: webserver/8, Timeout: 1794, Valid

In: 172.18.2.2/55028 --> 192.168.1.1/23;tcp, If: ge-0/0/3.0, Pkts: 62, Bytes:
3413
Out: 172.20.207.10/23 --> 172.18.2.2/55028;tcp, If: ge-0/0/4.207, Pkts: 48,
Bytes: 3028
Total sessions: 3
Question: What sessions are present in the session

table?
Answer: Provided the partnering team in your

assigned pod initiated a Telnet session destined for
your loopback IP address, at least three sessions
should display. One session represents the Telnet
session initiated by your team. One session
represents the additional Telnet session opened
directly with your assigned device. One session
represents the Telnet session opened by the remote
team in your assigned pod.
Step 2.12
Issue the show security nat destination pool all command and
answer the question that follows.
lab@srxD-1> show security nat destination pool all
Total destination-nat pools: 1
Pool name : webserver

Pool id : 1
Total address : 1
Translation hits: 1

Junos Security
Address range Port
172.20.207.10 - 172.20.207.10 0
Question: Are translation hits present for your

destination NAT pool?
Answer: Provided the partnering team in your

assigned pod initiated a Telnet session destined for
your loopback IP address, the translation hits
counter should show at least one hit.
Step 2.13
Return to the initial session established with your assigned SRX device.
From the initial session established with your assigned SRX device, exit the Telnet
session opened with the remote virtual router.
d1@vr-device> exit
lab@srxD-1>
Part 3: Pool-Based Source NAT with Overflow Pool
In this lab part, you configure pool-based source NAT between the virtual routers
attached to your assigned device. You will enable an overflow pool should the source
NAT pool become exhausted.
Step 3.1
If necessary, return to your assigned SRX device.
From your assigned SRX device, enter configuration mode, or go to the top of the
configuration hierarchy if you are already in configuration mode, and load the
lab5-part3-start.config from the /var/home/lab/jsec/ directory. Commit
the configuration when complete.
[edit]
lab@srxD-1# load override jsec/lab5-part3-start.config
load complete
[edit]
lab@srxD-1# commit
commit complete
Step 3.2
Navigate to the [edit security nat source] configuration hierarchy.
[edit]
lab@srxD-1# edit security nat source

Junos Security

lab@srxD-1#
Step 3.3
Create two new source NAT address pools. Name one pool after the name shown on
the lab diagram for your local Juniper virtual router, and another pool for your local
ACME virtual router. Disable port translation for both pools. Configure each pool to
use the egress interface should the NAT pool become exhausted. Each NAT pool
should consist of an address range associated with the neighboring virtual router.
Use the address range information shown in the following table.
Note
Pay close attention to the instructions in
this step. You are creating a source NAT
pool for both virtual routers attached to
your assigned device. However, the source
address pool consists of IP addresses
belonging to the subnet of the virtual router
opposite for which you are configuring the
pool.
Proxy Arp Address Ranges
Student Device NAT Pool Range Start Range End

srxA-1 vr101 172.20.201.2 172.20.201.9
srxA-1 vr201 172.20.101.2 172.20.101.9
srxA-2 vr102 172.20.202.2 172.20.202.9
srxA-2 vr202 172.20.102.2 172.20.102.9
srxB-1 vr103 172.20.203.2 172.20.203.9
srxB-1 vr203 172.20.103.2 172.20.103.9
srxB-2 vr104 172.20.204.2 172.20.204.9
srxB-2 vr204 172.20.104.2 172.20.104.9
srxC-1 vr105 172.20.205.2 172.20.205.9
srxC-1 vr205 172.20.105.2 172.20.105.9
srxC-2 vr106 172.20.206.2 172.20.206.9
srxC-2 vr206 172.20.106.2 172.20.106.9
srxD-1 vr107 172.20.207.2 172.20.207.9
srxD-1 vr207 172.20.107.2 172.20.107.9
srxD-2 vr108 172.20.208.2 172.20.208.9
srxD-2 vr208 172.20.108.2 172.20.108.9

Junos Security
lab@srxD-1# set pool local-Juniper-VR port no-translation

lab@srxD-1# set pool local-Juniper-VR overflow-pool interface

lab@srxD-1# set pool local-Juniper-VR address range-start to range-end

lab@srxD-1# set pool local-ACME-VR port no-translation

lab@srxD-1# set pool local-ACME-VR overflow-pool interface

lab@srxD-1# set pool local-ACME-VR address range-start to range-end

lab@srxD-1# show
pool vr107 {
address {
172.20.207.2/32 to 172.20.207.9/32;
}
port no-translation;
overflow-pool interface;
}
pool vr207 {
address {
172.20.107.2/32 to 172.20.107.9/32;
}
port no-translation;
overflow-pool interface;
}
...TRIMMED...
Step 3.4
Create a source NAT rule-set that assigns a directional context from your local
Juniper zone to your local ACME zone. For example, srx1 will use a context of from
zone JUNIPER-SV and to zone ACME-SV, and srx2 will use a context of
from zone JUNIPER-WF and to zone ACME-WF.
lab@srxD-1# set rule-set rule-set-name from zone Juniper-local

lab@srxD-1# set rule-set rule-set-name to zone ACME-local

lab@srxD-1# show
...TRIMMED...
rule-set vr107 {
from zone Juniper-SV;
to zone ACME-SV;
}

Junos Security
Step 3.5
Create a source NAT rule-set that assigns a directional context from your local
ACME zone to your local Juniper zone. For example, srx1 will use a context of from
zone ACME-SV and to zone JUNIPER-SV. Srx2 will use a context of from
zone ACME-WF and to zone JUNIPER-WF.
lab@srxD-1# set rule-set rule-set-name from zone ACME-local

lab@srxD-1# set rule-set rule-set-name to zone Juniper-local

lab@srxD-1# show
...TRIMMED...
rule-set vr207 {
from zone ACME-SV;
to zone Juniper-SV;
}
Step 3.6
Within the rule set created in Step 3.4, create a rule named Juniper-to-ACME.
Configure the source address to match traffic from your local Juniper customer
network. Configure the then action statement to specify source-nat using the
appropriate configured source address pool. (Hint: the pool name matches the rule
set name under which it is configured.)
lab@srxD-1# edit rule-set rule-set-name
[edit security nat source rule-set vr107]

lab@srxD-1# set rule Juniper-to-ACME match source-address local-Juniper-subnet

lab@srxD-1# set rule Juniper-to-ACME then source-nat pool pool-name

lab@srxD-1# show
from zone Juniper-SV;
to zone ACME-SV;
rule Juniper-to-ACME {
match {
}
then {
source-nat {
pool {
vr107;
}
}
}
}

Junos Security
Step 3.7
Within the rule set created in Step 3.5, create a rule named ACME-to-Juniper.
Configure the source address to match traffic from your local ACME customer
network. Configure the then action statement to specify source-nat using the
appropriate configured source address pool. (Hint: the pool name matches the rule
set name under which it is configured.)
lab@srxD-1# up

lab@srxD-1# edit rule-set rule-set-name

lab@srxD-1# set rule ACME-to-Juniper match source-address local-ACME-subnet

lab@srxD-1# set rule ACME-to-Juniper then source-nat pool pool-name

lab@srxD-1# show
lab@srxD-1# show
from zone ACME-SV;
to zone Juniper-SV;
rule ACME-to-Juniper {
match {
}
then {
source-nat {
pool {
vr207;
}
}
}
}
Question: You configured source NAT for traffic

between the virtual routers attached to your
assigned device. Do any existing security policies
allow this traffic?
Answer: As shown in the following capture from

srxD-1, no security policies are in place for traffic
between the attached virtual routers. We configure
the appropriate security policies next.

lab@srxD-1# top show security policies from-zone Juniper-local to-zone
ACME-local

Junos Security
lab@srxD-1# top show security policies from-zone ACME-local to-zone
Juniper-local

lab@srxD-1#
Step 3.8
Navigate to the [edit security policies] hierarchy.
lab@srxD-1# top edit security policies

lab@srxD-1#
Step 3.9
Create two security policies that allow traffic matching the internal-apps
application set to flow between the virtual routers attached to your assigned device.
Name the policies using the same format as the NAT rules you just created,
Juniper-to-ACME and ACME-to-Juniper, each corresponding to the
appropriate source and destination virtual router names. Match on the appropriate
source and destination address book entries that exist within the security zone
configuration.
lab@srxD-1# edit from-zone Juniper-local to-zone ACME-local policy
Juniper-to-ACME
[edit security policies from-zone Juniper-SV to-zone ACME-SV policy

Juniper-to-ACME]
lab@srxD-1# set match source-address local-Juniper-vrName

Juniper-to-ACME]
lab@srxD-1# set match destination-address local-ACME-vrName

Juniper-to-ACME]
lab@srxD-1# set match application internal-apps

Juniper-to-ACME]
lab@srxD-1# set then permit

Juniper-to-ACME]
lab@srxD-1# up 2

lab@srxD-1# edit from-zone ACME-local to-zone Juniper-local policy
ACME-to-Juniper
[edit security policies from-zone ACME-SV to-zone Juniper-SV policy

ACME-to-Juniper]

Junos Security
lab@srxD-1# set match source-address local-ACME-vrName

ACME-to-Juniper]
lab@srxD-1# set match destination-address local-Juniper-vrName

ACME-to-Juniper]
lab@srxD-1# set match application internal-apps

ACME-to-Juniper]
lab@srxD-1# set then permit

ACME-to-Juniper]
lab@srxD-1# up 2

lab@srxD-1# show from-zone Juniper-SV to-zone ACME-SV
policy Juniper-to-ACME {
match {
}
then {
permit;
}
}

lab@srxD-1# show from-zone ACME-SV to-zone Juniper-SV
policy ACME-to-Juniper {
match {
}
then {
permit;
}
}

lab@srxD-1#
Step 3.10
commit complete

Junos Security
lab@srxD-1>
Step 3.11
Step 3.12

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC

Junos Security
d1@vr-device>
Step 3.13
between the virtual routers attached to your assigned device in either direction. Use
the same login credentials used in the previous step.
Note
d1@vr-device> telnet local-ACME-VR routing-instance local-Juniper-VR

Trying 172.20.207.10...
telnet: connect to address 172.20.207.10: Operation timed out
telnet: Unable to connect to remote host
Question: Did the Telnet session successfully

establish?

session could not establish.
Step 3.14
security flow session command and answer the questions that follow.
Session ID: 64720, Policy name: Juniper-to-ACME/13, Timeout: 8, Valid
In: 172.20.107.10/55688 --> 172.20.207.10/23;tcp, If: ge-0/0/4.107, Pkts: 5,
Bytes: 288
Out: 172.20.207.10/23 --> 172.20.207.2/55688;tcp, If: ge-0/0/4.207, Pkts: 0,
Bytes: 0
Total sessions: 1

Junos Security
Note
Because the TCP three-way handshake
does not complete, the session only shows
in the session table for a few seconds. If
you do not see the session, try issuing the
Telnet command on the vr-device,
immediately followed by the
show security flow session
command on your assigned device.
Question: What does the output of this command

indicate?
Answer: As shown in the example from srxD-1, the

output indicates a session forms and source
NAT translation performs correctly. If you do not see
the session in your session table, the session might
have timed out. Repeat the Telnet command on the
vr-device and immediately issue the command on
your assigned device.
Question: Because the flow session is populating in

your session table, can you think of a
routing-related reason why the Telnet session did
not establish?
Answer: When the remote virtual router attempts to

respond to the Telnet request, the response is
directed to an IP address belonging to the source
NAT pool. This pool consists of addresses that
belong to the interfaces directly attached subnet.
Recall from the classroom lecture that this situation
requires proxy ARP.
Step 3.15
Enter configuration mode and navigate to the [edit security nat
proxy-arp] configuration hierarchy.
[edit]
lab@srxD-1# edit security nat proxy-arp

Junos Security
[edit security nat proxy-arp]
lab@srxD-1#
Step 3.16
Under the ge-0/0/4 interface, configure both logical units attached to your virtual
routers to perform proxy ARP. Each interface should perform proxy ARP for the range
of addresses included in the source NAT pool of the adjacent virtual router. Use the
address range information shown in the following table for your assigned
SRX device:
Proxy ARP Address Ranges
Student Device Logical Unit Range Start Range End

srxA-1 101 172.20.101.2 172.20.101.9
srxA-1 201 172.20.201.2 172.20.201.9
srxA-2 102 172.20.102.2 172.20.102.9
srxA-2 202 172.20.202.2 172.20.202.9
srxB-1 103 172.20.103.2 172.20.103.9
srxB-1 203 172.20.203.2 172.20.203.9
srxB-2 104 172.20.104.2 172.20.104.9
srxB-2 204 172.20.204.2 172.20.204.9
srxC-1 105 172.20.105.2 172.20.105.9
srxC-1 205 172.20.205.2 172.20.205.9
srxC-2 106 172.20.106.2 172.20.106.9
srxC-2 206 172.20.206.2 172.20.206.9
srxD-1 107 172.20.107.2 172.20.107.9
srxD-1 207 172.20.207.2 172.20.207.9
srxD-2 108 172.20.108.2 172.20.108.9
srxD-2 208 172.20.208.2 172.20.208.9

lab@srxD-1# edit interface ge-0/0/4.local-Juniper-unit
[edit security nat proxy-arp interface ge-0/0/4.107]

lab@srxD-1# set unit address range-start to range-end

lab@srxD-1# up

lab@srxD-1# edit interface ge-0/0/4.local-ACME-unit

Junos Security
lab@srxD-1# set address range-start to range-end

lab@srxD-1# up

lab@srxD-1# show
interface ge-0/0/4.107 {
address {
172.20.107.2/32 to 172.20.107.9/32;
}
}
interface ge-0/0/4.207 {
address {
172.20.207.2/32 to 172.20.207.9/32;
}
}
Step 3.17
commit complete
lab@srxD-1>
Step 3.18
From the Telnet session established with the virtual router, attempt to establish a
Telnet session between the virtual routers once again.
Note
d1@vr-device> telnet local-ACME-VR routing-instance local-Juniper-VR

Trying 172.20.207.10...
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC

Junos Security
d1@vr-device>
Question: Did the second Telnet attempt between

the attached virtual routers successfully establish?

session did establish.
Step 3.19
Return to the terminal session connected to your assigned device and issue the
show security flow session command.
Session ID: 65071, Policy name: Juniper-to-ACME/13, Timeout: 1740, Valid
In: 172.20.107.10/65306 --> 172.20.207.10/23;tcp, If: ge-0/0/4.107, Pkts: 28,
Bytes: 1631
Out: 172.20.207.10/23 --> 172.20.207.5/65306;tcp, If: ge-0/0/4.207, Pkts: 22,
Bytes: 1596
Total sessions: 1
Question: Does the output indicate source NAT

between the attached virtual routers is operating
normally?

session established and source NAT is in place. In
this example from srxD-1, traffic from vr107 is
translating to 172.20.207.5.
Question: What IP address did your Telnet session

receive from the source NAT pool?
Answer: The answer varies. In this example from

srxD-1, the session acquired IP address
172.20.207.5.

Junos Security
Step 3.20
Issue the show security nat source summary command.
lab@srxD-1> show security nat source summary
Total port number usage for port translation pool: 0
Maximum port number for port translation pool: 16777216
Total pools: 2
Pool Address Routing PAT Total
Name Range Instance Address
vr107 172.20.207.2-172.20.207.9 default no 8
vr207 172.20.107.2-172.20.107.9 default no 8
Total rules: 3
Rule name Rule set From To Action
1 internet-bound ge-0/0/4.107 untrust interface
1 ge-0/0/4.207
Juniper-to-ACME vr107 Juniper-SV ACME-SV vr107
ACME-to-Juniper vr207 ACME-SV Juniper-SV vr207
Question: How many configured source NAT rules

are on your assigned device?
Answer: As indicated in the output, a total of three

source NAT rules are operating.
Step 3.21
Issue the show security nat source pool all command.
lab@srxD-1> show security nat source pool all
Total pools: 2
Pool name : vr107

Pool id : 4
Routing instance : default
Host address base : 0.0.0.0
Port : no translation
port overloading : 0
Overflow pool : interface
Total addresses : 8
Available addresses: 7
Address range Single Ports Twin Ports
172.20.207.2 - 172.20.207.9 0 0
Pool name : vr207

Pool id : 5
Routing instance : default
Host address base : 0.0.0.0
Port : no translation
port overloading : 0
Overflow pool : interface

Junos Security
Total addresses : 8
Available addresses: 8
Address range Single Ports Twin Ports
172.20.107.2 - 172.20.107.9 0 0
Question: How many addresses are available in

each source NAT pool displayed?
Answer: Each source NAT pool has eight available

addresses.
Step 3.22
Return to the session opened to the vr-device and exit the Telnet session between
virtual routers.
d1@vr-device> exit
d1@vr-device>

Lab 6
Implementing IPsec VPNs (Detailed)
Overview
In this lab, you will implement a route-based IPsec VPN. You will configure and monitor the
IKE phase one and phase two tunnel establishment.
Configure a route-based IPsec VPN.
Alter security policies to allow traffic between the ACME security zones.
Configure and monitor a secure tunnel interface.
Verify and monitor an IPsec VPN tunnel.
www.juniper.net Implementing IPsec VPNs (Detailed) Lab 61

12.a.12.1R1.9
Junos Security
Part 1: Configuring a Route-Based IPsec VPN
In this lab part, you configure a route-based IPsec VPN tunnel. This IPsec VPN tunnel
will be utilized for all traffic between the ACME customer security zones.
Step 1.1


lab are for srxD-1, which uses 10.210.35.137 as its
Step 1.2
Step 1.3
configuration and exit to operational mode when complete.
srxD-1 (ttyu0)
login: lab
Password:
Lab 62 Implementing IPsec VPNs (Detailed) www.juniper.net

Junos Security
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
[edit]
lab@srxD-1# load override jsec/lab6-start.config
load complete
[edit]
commit complete
lab@srxD-1>
Step 1.4
Navigate to the [edit interfaces] configuration hierarchy.
[edit]
lab@srxD-1# edit interfaces
[edit interfaces]
lab@srxD-1#
Step 1.5
Configure a secure tunnel interface. If your assigned device is srx1, configure logical
unit 0 with an IP address of 192.168.100.1. If your assigned device is srx2,
configure logical unit 0 with an IP address of 192.168.100.2.
[edit interfaces]
lab@srxD-1# set st0 unit 0 family inet address tunnel-interface-address
Step 1.6
Add the st0.0 interface to the untrust security zone, and allow the interface to
accept IKE packets.
[edit interfaces]
lab@srxD-1# top set security zones security-zone untrust interfaces st0.0
[edit interfaces]
lab@srxD-1# top set security zones security-zone untrust interfaces st0.0
host-inbound-traffic system-services ike
Step 1.7
Navigate to the [edit security ike] configuration hierarchy. Create an
Internet Key Exchange (IKE) phase 1 proposal named phase1. The proposal should
use the following parameters:
Authentication method: pre-shared-keys;
dh-group: group2;
authentication algorithm: md5;
encryption algorithm: 3des-cbc; and
lifetime: 86400.

Junos Security
[edit interfaces]
lab@srxD-1# top edit security ike
[edit security ike]

lab@srxD-1# set proposal phase1 authentication-method pre-shared-keys
[edit security ike]

lab@srxD-1# set proposal phase1 dh-group group2
[edit security ike]

lab@srxD-1# set proposal phase1 authentication-algorithm md5
[edit security ike]

lab@srxD-1# set proposal phase1 encryption-algorithm 3des-cbc
[edit security ike]

lab@srxD-1# set proposal phase1 lifetime-seconds 86400
[edit security ike]

lab@srxD-1# show proposal phase1
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}
}
[edit security ike]

lab@srxD-1#
Step 1.8
Configure an IKE phase one policy named phase1-policy. The policy should use
main mode, reference the proposal you created in the previous step, and use an
ASCII pre-shared key of juniper.
[edit security ike]
lab@srxD-1# set policy phase1-policy mode main
[edit security ike]

lab@srxD-1# set policy phase1-policy proposals phase1
[edit security ike]

lab@srxD-1# set policy phase1-policy pre-shared-key ascii-text juniper
[edit security ike]

lab@srxD-1# show policy phase1-policy
mode main;
proposals phase1;
pre-shared-key ascii-text "$9$QkE43/t1RSM87uO87-V4oz36"; ## SECRET-DATA

Junos Security
Step 1.9
Configure an IKE gateway named phase1-gateway. Reference the IKE policy you
created in the previous step. For the gateway IP address, use the IP address
associated with the ge-0/0/3 interface on the remote teams device. Use your
devices ge-0/0/3 interface as the external interface for establishing an IPsec VPN
between srx1 and srx2. Configure your device to send a dead peer detection
(DPD) request packet every 20 seconds and to consider the IKE neighbor down after
five sequences of waiting 20 seconds and sending a DPD request packet.
[edit security ike]
lab@srxD-1# set gateway phase1-gateway ike-policy phase1-policy
[edit security ike]

lab@srxD-1# set gateway phase1-gateway address remote-srx-Internet-address
[edit security ike]

lab@srxD-1# set gateway phase1-gateway dead-peer-detection interval 20
[edit security ike]

lab@srxD-1# set gateway phase1-gateway dead-peer-detection threshold 5
[edit security ike]

lab@srxD-1# set gateway phase1-gateway external-interface ge-0/0/3.0
[edit security ike]

lab@srxD-1# show gateway phase1-gateway
ike-policy phase1-policy;
address 172.18.2.2;
dead-peer-detection {
interval 20;
threshold 5;
}
external-interface ge-0/0/3.0;
Step 1.10
Navigate to the [edit security ipsec] configuration hierarchy. You define
IKE phase 2 configuration parameters at this level.
[edit security ike]
lab@srxD-1# up
[edit security]
lab@srxD-1# edit ipsec
[edit security ipsec]

lab@srxD-1#
Step 1.11
Define an IKE phase two proposal named phase2. Use the Encapsulating Security
Payload (ESP) protocol, an authentication algorithm of hmac-md5-96, an
encryption algorithm of 3des-cbc, and a lifetime value of 3200 seconds.
lab@srxD-1# set proposal phase2 protocol esp

Junos Security
lab@srxD-1# set proposal phase2 authentication-algorithm hmac-md5-96

lab@srxD-1# set proposal phase2 encryption-algorithm 3des-cbc

lab@srxD-1# set proposal phase2 lifetime-seconds 3200

lab@srxD-1# show proposal phase2
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3200;
Step 1.12
Create a phase two policy named phase2-policy. Configure Perfect Forward
Secrecy (PFS) to use Diffie-Helman Group 2 as the method the device uses to
generate the encryption key. Use the phase two proposal you created in the last
step.
lab@srxD-1# set policy phase2-policy perfect-forward-secrecy keys group2

lab@srxD-1# set policy phase2-policy proposals phase2

lab@srxD-1# show policy phase2-policy
perfect-forward-secrecy {
keys group2;
}
proposals phase2;
Step 1.13
Configure the IPsec VPN tunnel and name the VPN to-remote-SRX. Bind the
st0.0 interface to this tunnel. Associate the IKE gateway and phase two policy with
the VPN tunnel. Ensure the VPN tunnel is established without the need for a
triggering mechanism.
lab@srxD-1# set vpn to-remote-SRX bind-interface st0.0

lab@srxD-1# set vpn to-remote-SRX ike gateway phase1-gateway

lab@srxD-1# set vpn to-remote-SRX ike ipsec-policy phase2-policy

lab@srxD-1# set vpn to-remote-SRX establish-tunnels immediately

lab@srxD-1# show vpn to-remote-SRX

Junos Security
bind-interface st0.0;
ike {
gateway phase1-gateway;
ipsec-policy phase2-policy;
}
establish-tunnels immediately;
Step 1.14
All traffic between the ACME security zones will use the IPsec VPN you created.
Navigate to the [edit routing-options] configuration hierarchy. Create a
static route for the remote student teams ACME customer network. The next hop
should point to the st0.0 interface.
lab@srxD-1# top edit routing-options
lab@srxD-1# set static route remote-ACME-subnet next-hop st0.0
lab@srxD-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 172.20.208.0/24 next-hop st0.0;
}
Question: Why is this step necessary?
Answer: In a route-based VPN, traffic associates

using a route rather than a security policy. Without
this step, traffic would not use the IPsec VPN
tunnel.
Question: What are the two valid next hops for this
static route?
Answer: The st0.0 interface can be specified as the

next-hop as shown in the example. You could also
use the remote IP address of the st0 interface.
Step 1.15
Navigate to the [edit security policies] configuration hierarchy. Review
the security policies in place that allow traffic between the untrust zone and your
local ACME customer network zone.
lab@srxD-1# top edit security policies

Junos Security
lab@srxD-1# show from-zone untrust to-zone ACME-local
policy webserver {
match {
}
then {
permit;
}
}

lab@srxD-1# show from-zone ACME-local to-zone untrust
policy internet-ACME {
match {
application any;
}
then {
permit;
}
}
Question: What changes must you make to the

[edit security policies] hierarchy?
Answer: You must make a new policy for traffic

coming from the untrust zone that originates on the
remote virtual router. A security policy is already in
place to allow all traffic to the untrust zone that
originates on the local virtual router.
Step 1.16
Create a new security policy that permits traffic from the untrust zone destined to
your local ACME customer zone. Name the security policy ipsec. Configure the
source-address to match the address-book entry for the remote student teams
ACME customer network. Use the configuration option any for the destination
address and application. When finished review the configuration, and answer the
question below.
lab@srxD-1# edit from-zone untrust to-zone ACME-local

lab@srxD-1# set policy ipsec match source-address remote-ACME-vrName

lab@srxD-1# set policy ipsec match destination-address any

Junos Security
lab@srxD-1# set policy ipsec match application any

lab@srxD-1# set policy ipsec then permit

lab@srxD-1# show
policy webserver {
match {
}
then {
permit;
}
}
policy ipsec {
match {
application any;
}
then {
permit;
}
}

lab@srxD-1#
Question: Is any policy reordering necessary for this

traffic flow?
Answer: No. As shown in the output, the first policy

does not match on traffic from the remote virtual
router. Because no match occurs, traffic from the
IPsec tunnel is not evaluated until the second
policy.
Step 1.17
commit complete
lab@srxD-1>

Junos Security
assigned pod reach this point.
Part 2: Verifying and Monitoring IPsec
In this lab part, you check IKE phase one and phase two tunnel security associations
and monitor the IPsec VPN on your assigned device by initiating traffic from the
virtual router.
Step 2.1
Issue the show interfaces st0 terse command.
lab@srxD-1> show interfaces st0 terse
st0 up up
st0.0 up up inet 192.168.100.1 --> 0/0
Question: What is the status of the st0.0 interface?
Answer: As shown in the output, both the

administrative status and link status should be up.
Step 2.2
Check the state of the IKE phase 1 security association using the show security
ike security-associations command.
lab@srxD-1> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
976176 UP f347d504ef032fcc fed0a0e871ade192 Main 172.18.2.2
Question: What is the state of the IKE phase 1

security association?
Answer: As shown in the output, the state should be

up. If you do not see a security association, try
clearing the phase 1 and phase 2 security
associations on both devices within your pod.
Step 2.3
Check the state of the phase 2 security association using the show security
ipsec security-associations command.
lab@srxD-1> show security ipsec security-associations
Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/md5 768fe3ba 3106/ unlim - root 500 172.18.2.2
>131073 ESP:3des/md5 e9444a8e 3106/ unlim - root 500 172.18.2.2

Junos Security
Question: Is a phase 2 security association
present?
Answer: As shown in the output, at least one

successful phase 2 security association should be
present, represented by an inbound row and an
outbound row.
Question: What is the index number used to

represent the phase 2 security association?
Answer: The answer can vary. In the example, the

index number, represented by the ID column, is
131073.
Step 2.4
Issue the show security ipsec security-associations index
number command, where number represents the index number obtained in the
previous step.
lab@srxD-1> show security ipsec security-associations index index-number
Virtual-system: root
Local Gateway: 172.18.1.2, Remote Gateway: 172.18.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv1
DF-bit: clear
Direction: inbound, SPI: 768fe3ba, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 3042 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2464 seconds
Mode: Tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: e9444a8e, AUX-SPI: 0

, VPN Monitoring: -
Hard lifetime: Expires in 3042 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2464 seconds
Mode: Tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64

Junos Security
Question: Is anti-replay enabled for the IPsec VPN
tunnel?
Answer: The answer should be yes, as shown in the

example output.
Step 2.5
Issue the clear security ipsec statistics command followed by the
show security ipsec statistics command.
lab@srxD-1> clear security ipsec statistics
lab@srxD-1> show security ipsec statistics

ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
Encrypted packets: 0
Decrypted packets: 0
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Question: Do all the counters show a value of 0?

example output.
Step 2.6
Note
This lab step requires you to open a
separate Telnet session to the virtual router
to emulate an external host.
Keep the current Telnet session
established with your assigned SRX device
open to monitor results.
The virtual router is a J Series Services
Router configured as several logical
devices. Refer to the Management Network

Junos Security
Step 2.7

srxA-1 a1 lab123
srxA-2 a2 lab123
srxB-1 b1 lab123
srxB-2 b2 lab123
srxC-1 c1 lab123
srxC-2 c2 lab123
srxD-1 d1 lab123
srxD-2 d2 lab123
vr-device (ttyd0)
login: username
Password:
--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC
d1@vr-device>

Junos Security
Step 2.8
that traverses the IPsec tunnel. Initiate the Telnet connection to the remote teams
ACME customer network. Source the Telnet session from your virtual router that is
associated with your local ACME customer network. Use the same login credentials
as used for your current vr-device Telnet session.
Note
d1@vr-device> telnet remote-ACME-VR routing-instance local-ACME-VR

Trying 172.20.208.10...
vr-device (ttyp1)
login:
Step 2.9
From the Telnet session established with your assigned SRX device, view the flow
session table.
Session ID: 1, Policy name: N/A, Timeout: N/A, Valid
In: 172.18.2.2/33021 --> 172.18.1.2/5392;esp, If: ge-0/0/3.0, Pkts: 0, Bytes:
0
Session ID: 2, Policy name: N/A, Timeout: N/A, Valid

In: 172.18.2.2/0 --> 172.18.1.2/0;esp, If: ge-0/0/3.0, Pkts: 0, Bytes: 0

In: 10.210.35.137/123 --> 10.210.35.130/123;udp, If: .local..0, Pkts: 1,
Bytes: 76
Out: 10.210.35.130/123 --> 10.210.35.137/123;udp, If: ge-0/0/0.0, Pkts: 1,
Bytes: 76
Session ID: 865, Policy name: internet-ACME-SV/9, Timeout: 1796, Valid

In: 172.20.207.10/49161 --> 172.20.208.10/23;tcp, If: ge-0/0/4.207, Pkts: 10,
Bytes: 671
Out: 172.20.208.10/23 --> 172.20.207.10/49161;tcp, If: st0.0, Pkts: 9, Bytes:
641
Total sessions: 4

Junos Security
Question: What sessions associate with the secure
tunnel interface?
Answer: The output can vary, but Telnet sessions,

indicated by TCP port 23, that are between virtual
routers should show interface st0.0 for either the
inbound or outbound flow.
Step 2.10
Issue the show security ipsec statistics command.
lab@srxD-1> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 3496
Decrypted bytes: 1706
Encrypted packets: 32
Decrypted packets: 24
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Question: How many packets have received

encryption?
Answer: The answer varies, but both the encrypted

and decrypted packets counters should have a
non-zero value.
Step 2.11
From the Telnet session established with the virtual router, exit the virtual router
Telnet session using the exit command.
d1@vr-device> exit
d1@vr-device>

Junos Security

Lab 7
Implementing IDP (Detailed)
Overview
In this lab, you will implement intrusion detection and prevention (IDP). You will install the
security package from Juniper Networks, customize a policy template and perform
verification tasks.
Install and verify IDP licensing.
Install and verify the Juniper Networks security package, including the attack
database and IDP policy templates.
Configure and customize IDP policy using IDP policy templates.
Verify and monitor the IDP implementation.
www.juniper.net Implementing IDP (Detailed) Lab 71

12.a.12.1R1.9
Junos Security
Part 1: Retrieving and Installing the Security Package and IDP License
Then, you will download the security package normally made available by Juniper
Networks as well as the necessary IDP licensing.
Note
assigned device.
Step 1.1


is assigned to the srxC-1 station, which uses an IP
address of 10.210.35.135.
Step 1.2
Lab 72 Implementing IDP (Detailed) www.juniper.net

Junos Security
Step 1.3
srxC-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Note
This lab requires that you have root access
in the UNIX shell of the device. In the next
few steps, you change the root password of
your assigned device. Be sure to follow the
steps closely to avoid disabling access to
the device.

Junos Security
Step 1.4
Change the root password of your assigned device to lab123. Use the
set system root-authentication plain-text-password
command to make this change.
[edit]
lab@srxD-1# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
lab@srxD-1#
Step 1.5
[edit]
commit complete
lab@srxD-1>
Note
In the next series of lab steps, you obtain
an IDP license and the IDP security
package from the server within your
assigned lab rack. Because of differing lab
environments, you obtain these files
unconventionally. In a non-lab environment,
you obtain the license directly from Juniper
Networks while you download the security
package directly from Juniper Networks
using an Internet connection.
Step 1.6
Enter the UNIX shell mode of your assigned device with the start shell
command.
lab@srxD-1> start shell
%
Step 1.7
At the % prompt type su root to switch the user to the root user. This level of
permissions is necessary for the next few steps. When prompted for the new
password, use the lab123 password you just defined in the configuration.
% su root
Password:
root@srxD-1%
Step 1.8
Change your working directory to /var/tmp by entering the cd /var/tmp
command at the % prompt.

Junos Security
root@srxD-1% cd /var/tmp
root@srxD-1%
Step 1.9
At the % prompt, enter the following command to retrieve the IDP license for your
assigned device, where serverIP is the IP address of the server device and
assigned-device is the name of your assigned device. Refer to your
Management Network Diagram to determine the IP address of the server device.
When prompted to continue connecting, type yes and press the enter key. When
prompted for a RADIUS password, use lab123.
scp lab@serverIP:jsec/assigned-device.txt .
Note
Be sure to include the trailing period in the
command. The period in this command
instructs SCP to copy the remote files to
your current working directory.
root@srxD-1% scp lab@serverIP:jsec/assigned-device.txt .

The authenticity of host '10.210.14.130 (10.210.14.130)' can't be established.
DSA key fingerprint is ef:17:5e:05:13:ee:db:cd:ff:84:94:55:ae:e3:1b:e2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.210.14.130' (DSA) to the list of known hosts.
RADIUS Password:
srxD-1.txt 100% 182 0.2KB/s 00:00
root@srxD-1%
Step 1.10
Use the cd /var/db/idpd command to change your current directory to
/var/db/idpd.
root@srxD-1% cd /var/db/idpd
root@srxD-1%
Step 1.11
Issue the ls sec-download command to view the contents of the
sec-download directory.
root@srxD-1% ls sec-download
detector-capabilities.xml sub-download
Question: What does the sec-download directory

contain?
Answer: As shown in the output, the directory

contains another directory named sub-download
and no further contents. The sub-download
directory does not contain any files.
root@srxD-1% ls sec-download/sub-download
root@srxD-1%

Junos Security
Step 1.12
Use SCP to obtain the IDP security package from the server device by entering the
following command, where serverIP is the IP address of the service device on
your lab diagram. When prompted for a RADIUS password, use lab123.
scp lab@serverIP:jsec/idp.tar.tgz .
Note
Be sure to include the trailing period in the
command. The period in this command
instructs SCP to copy the remote files to
your current working directory.
root@srxD-1% scp lab@serverIP:jsec/idp.tar.tgz .

RADIUS Password:
idp.tar.tgz 100% 1717KB 858.3KB/s 00:02
root@srxD-1%
Step 1.13
Uncompress the contents of the IDP file by entering the following command:
tar xzvf idp.tar.tgz
root@srxD-1% tar xzvf idp.tar.tgz
sec-download/
sec-download/sub-download/
sec-download/sub-download/SignatureUpdate.xml
sec-download/sub-download/templates.xml
sec-download/SignatureUpdate.xml
sec-download/applications.xml
sec-download/libidp-detector.so.tgz.v
sec-download/groups.xml
sec-download/platforms.xml
sec-download/detector-capabilities.xml
root@srxD-1%
Step 1.14
Issue the ls sec-download command again to check the contents of the
directory.
root@srxD-1% ls sec-download
SignatureUpdate.xml libidp-detector.so.tgz.v
applications.xml platforms.xml
detector-capabilities.xml sub-download
groups.xml
root@srxD-1%

Junos Security
Question: What does the sec-download directory
contain?
Answer: As shown in the output, the directory now

has a series of XML files containing the contents of
the IDP security package.
Step 1.15
Exit the UNIX shell by issuing the exit command twice.
root@srxD-1% exit
exit
% exit
exit
lab@srxD-1>
Part 2: Installing the IDP License and Security Package
In this lab part, you install the license required for the IDP attack database and
policy template updates. After verifying the validity of the license, you will then
proceed with the installation of the IDP security package and policy templates.
Step 2.1
Issue the show system license command to list the installed licenses on your
assigned device.
lab@srxD-1> show system license
License usage: none
Licenses installed: none
Question: Does your system currently have any

installed licenses?
Answer: As shown in the output, currently no

licenses are installed.
Step 2.2
Install the IDP license you downloaded in the last lab part by using the
request system license add command. Specify the file as
/var/tmp/assigned-device.txt, where assigned-device represents
the hostname of your assigned device.
lab@srxD-1> request system license add /var/tmp/assigned-device.txt
JUNOS204211: successfully added
add license complete (no errors)

Junos Security
Question: Did the license successfully install?
Answer: As shown in the output, the license

installed. If you experience an error installing the
license, verify that the path and filename are
correct and that the file resides in the specified
directory. Notify your instructor if you are unable to
install the license.
Step 2.3
View the active licenses on your assigned device using the
show system license command.
Note
The output shown for this command can
vary depending on the device or license
type used in your environment.
lab@srxD-1> show system license

License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
idp-sig 0 1 0 2014-09-03
19:00:00 CDT
ax411-wlan-ap 0 2 0 permanent
Licenses installed:
License identifier: JUNOS220951
License version: 2
Valid for device: AH2909AA0068
Features:
idp-sig - IDP Signature
date-based, 2009-09-15 19:00:00 CDT - 2014-09-03 19:00:00 CDT
Question: Does the installed license reflect the

proper serial number for your assigned device?
Answer: The output varies, but the example shows a

device serial number of AH2909AA0068. By
comparing this value to the serial number reflected
in the output of the show chassis hardware
command, you can see that this license is correct. If
the numbers do not match ensure that you
obtained the correct license for your assigned
device.
lab@srxD-1> show chassis hardware

Hardware inventory:
Item Version Part number Serial number Description
Chassis AH2909AA0068 SRX240h-poe

Junos Security
Routing Engine REV 31 750-021794 AAAD8406 RE-SRX240H-POE
FPC 0 FPC
PIC 0 16x GE Base PIC
FPC 1 REV 02 750-025085 AAAN4046 FPC
PIC 0 1x Serial mPIM
Power Supply 0
Step 2.4
Install the IDP attack database using the request security idp
security-package install operational mode command.
lab@srxD-1> request security idp security-package install
Will be processed in async mode. Check the status using the status checking CLI
Question: What was the result of this operation?
Answer: As shown in the output, the install should

begin in async mode. If the output from your
device does not match this output, notify your
instructor.
Step 2.5
Check the status of your installation over the next few minutes using the
request security idp security-package install status
command. Do not continue to the next step until you receive an indication that the
installation was successful.
lab@srxD-1> request security idp security-package install status
In progress:performing DB update for an xml (groups.xml)

In progress:performing DB update for an xml (SignatureUpdate.xml)

In progress:Compiling AI signatures ...

Done;Attack DB update : successful - [UpdateNumber=1449,ExportDate=Tue Jun 23
12:45:25 2009,Detector=9.2.160090324]
Updating control-plane with new detector : successful
Updating data-plane with new attack or detector : not performed
due to no existing running policy found.
Question: Did the security package successfully

install?

example output.

Junos Security
Step 2.6
Install the IDP policy templates provided by Juniper Networks with the
request security idp security-package install
policy-templates command.
lab@srxD-1> request security idp security-package install policy-templates
Will be processed in async mode. Check the status using the status checking CLI
Step 2.7
Check the policy template installation status using the
request security idp security-package install status
command. Do not continue to the next step until you receive an indication that the
installation was successful.
Done;policy-templates has been successfully updated into internal repository
(=>/var/db/scripts/commit/templates.xsl)!
Step 2.8
The installation of the policy templates results in the creation of a Junos operating
system commit script. Enter configuration mode and enter the
set system scripts commit file templates.xsl command. Commit
the configuration to activate the commit script.
Note
The commit script, which inserts the
IDP policy templates into the active
configuration, is a large file. Expect the
commit action to take a few moments.
[edit]
lab@srxD-1# set system scripts commit file templates.xsl
[edit]
lab@srxD-1# commit
commit complete
[edit]
lab@srxD-1#
Step 2.9
Verify that the policy templates were added to your configuration. You could view the
configuration file for verification, but for a quicker check, issue the
set security idp active-policy ? configuration mode command.
[edit]
lab@srxD-1# set security idp active-policy ?
<active-policy> Set active policy
DMZ_Services
DNS_Service

Junos Security
File_Server
Getting_Started
IDP_Default
Recommended
Web_Server
[edit]
lab@srxD-1# set security idp active-policy
Question: What IDP policy templates are now

available?
Answer: The DMZ_Services, DNS_Service,

File_Server, Getting_Started,
IDP_Default, Recommended, and
Web_Server IDP policy templates should now be
available.
Part 3: Enabling IDP Policy
In this lab part, you customize the Recommended policy template and apply the
modified policy to your assigned device.
Step 3.1
Navigate to the [edit security idp] configuration hierarchy.
[edit]
lab@srxD-1# edit security idp
[edit security idp]

lab@srxD-1#
Step 3.2
Delete all of the recently added template IDP policies in your configuration except
the Recommended IDP policy template.
[edit security idp]
lab@srxD-1# delete idp-policy ?
<policy-name> IDP policy name
DMZ_Services IDP policy name
DNS_Service IDP policy name
File_Server IDP policy name
Getting_Started IDP policy name
IDP_Default IDP policy name
Recommended IDP policy name
Web_Server IDP policy name
[edit security idp]
lab@srxD-1# delete idp-policy DMZ_Services
[edit security idp]

lab@srxD-1# delete idp-policy DNS_Service
Junos Security
[edit security idp]

lab@srxD-1# delete idp-policy File_Server
[edit security idp]

lab@srxD-1# delete idp-policy Getting_Started
[edit security idp]

lab@srxD-1# delete idp-policy IDP_Default
[edit security idp]

lab@srxD-1# delete idp-policy Web_Server
Step 3.3
View the Recommended IDP policy template.
[edit security idp]
lab@srxD-1# show idp-policy Recommended | no-more
/* This template policy covers the most important vulnerabilities. Use this
template as a base line. */
rulebase-ips {
rule 1 {
/* This rule is designed to protect your networks against important TCP/
IP attacks. */
match {
from-zone any;
source-address any;
to-zone any;
application default;
attacks {
predefined-attack-groups [ "[Recommended]IP - Critical"
"[Recommended]IP - Minor" "[Recommended]IP - Major" "[Recommended]TCP -
Critical" "[Recommended]TCP - Minor" "[Recommended]TCP - Major" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 2 {
/* This rule is designed to protect your network against important ICMP
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {

Junos Security
predefined-attack-groups [ "[Recommended]ICMP - Major"
"[Recommended]ICMP - Minor" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 3 {
/* This rule is designed to protect your network against important HTTP
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]HTTP - Critical"
"[Recommended]HTTP - Major" "[Recommended]HTTP - Minor" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 4 {
/* This rule is designed to protect your network against important SMTP
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]SMTP - Critical"
"[Recommended]SMTP - Major" "[Recommended]SMTP - Minor" ];
}
}
then {
action {
recommended;
}
notification {

Junos Security
log-attacks;
}
}
}
rule 5 {
/* This rule is designed to protect your network against important DNS
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]DNS - Critical"
"[Recommended]DNS - Minor" "[Recommended]DNS - Major" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 6 {
/* This rule is designed to protect your network against important FTP
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]FTP - Critical"
"[Recommended]FTP - Minor" "[Recommended]FTP - Major" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 7 {
/* This rule is designed to protect your network against important POP3
attacks. */
match {
from-zone any;

Junos Security
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]POP3 - Critical"
"[Recommended]POP3 - Minor" "[Recommended]POP3 - Major" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 8 {
/* This rule is designed to protect your network against important IMAP
attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]IMAP - Critical"
"[Recommended]IMAP - Major" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
rule 9 {
/* This rule is designed to protect your network against common internet
malware. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {

Junos Security
predefined-attack-groups [ "[Recommended]TROJAN - Critical"
"[Recommended]TROJAN - Major" "[Recommended]TROJAN - Minor"
"[Recommended]VIRUS - Critical" "[Recommended]VIRUS - Major"
"[Recommended]VIRUS - Minor" "[Recommended]WORM - Critical"
"[Recommended]WORM - Major" "[Recommended]WORM - Minor" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
}
Question: Does the Recommended IDP policy

provide protection for HTTP?
Answer: Rule 3 protects against malicious HTTP

traffic.
Note
For specific information regarding
predefined attacks or attack groups,
consult the following link:
https://services.netscreen.com/restricted/
sigupdates/nsm-updates/HTML/
index.html
Step 3.4
Delete all of the rules, except rule 3, from the Recommended IDP policy.
[edit security idp]
lab@srxD-1# delete idp-policy Recommended rulebase-ips rule 1
[edit security idp]

[edit security idp]

[edit security idp]

[edit security idp]


Junos Security
[edit security idp]

[edit security idp]

[edit security idp]

[edit security idp]

lab@srxD-1# show idp-policy Recommended
/* This template policy covers the most important vulnerabilities. Use this
template as a base line. */
rulebase-ips {
rule 3 {
/* This rule is designed to protect your network against important
HTTP attacks. */
match {
from-zone any;
source-address any;
to-zone any;
attacks {
predefined-attack-groups [ "[Recommended]HTTP - Critical"
"[Recommended]HTTP - Major" "[Recommended]HTTP - Minor" ];
}
}
then {
action {
recommended;
}
notification {
log-attacks;
}
}
}
}
Step 3.5
Set the Recommended IDP policy as the active IDP policy on your assigned device.
[edit security idp]
lab@srxD-1# set active-policy Recommended
Step 3.6
Configure your assigned device to perform IDP services on all traffic associated with
the webserver security policy. Ensure you reference the appropriate security zone
within the policy context.
[edit security idp]
lab@srxD-1# top edit security policies from-zone untrust to-zone ACME-local

Junos Security
lab@srxD-1# set policy webserver then permit application-services idp

lab@srxD-1# show policy webserver
match {
}
then {
permit {
application-services {
idp;
}
}
}

lab@srxD-1#
Step 3.7
To avoid overwriting the IDP policy modifications on subsequent commit operations,
delete the commit script from the configuration. After you remove the commit script,
commit the configuration and return to operational mode.
lab@srxD-1# top
[edit]
lab@srxD-1# delete system scripts
[edit]
commit complete
lab@srxD-1>
Step 3.8
Issue the show security policies policy-name webserver detail
command.
lab@srxD-1> show security policies policy-name webserver detail
Policy: webserver, action-type: permit, State: enabled, Index: 12, Scope Policy:
0
Sequence number: 1
From zone: untrust, To zone: ACME-SV
Source addresses:
srxD-2: 172.18.2.0/30
vr207: 172.20.207.0/24
Application: junos-telnet

Junos Security
Application: junos-http
Intrusion Detection and Prevention: enabled
Unified Access Control: disabled
Question: Does the webserver security policy

output indicate that IDP is enabled?
Answer: Yes. IDP is listed as enabled.
Step 3.9
View the memory allocation for IDP services using the
show security idp memory command.
lab@srxD-1> show security idp memory
IDP data plane memory statistics:
Total IDP data plane memory : 196 MB

Used : 12 MB ( 12288 KB ) ( 6.12%)
Available : 184 MB ( 188416 KB ) ( 93.88%)
Question: How much data plane memory is

currently in use for IDP services?
Answer: The output varies. In the example from

srxD-1, 12 MB of memory is currently in use for
IDP services.
Step 3.10
Check the version of the attack database currently installed on your assigned device
using the show security idp security-package-version command.
lab@srxD-1> show security idp security-package-version
Attack database version:2125(Thu Apr 26 12:37:13 2012)
Detector version :12.6.160120404
Policy template version :N/A

Junos Security
Question: What version number of the attack
database is presently on your assigned device?
Answer: The answer can vary. In the example from

srxD-1, the version number is 1449.

Lab 8
Implementing High Availability Techniques (Detailed)
Overview
In this lab, you will implement high availability chassis clustering. You will work with the
remote team in your pod to combine your assigned devices into a single chassis cluster.
You will then generate traffic flows from the attached virtual routers. You will monitor the
traffic flows to determine the path taken through the chassis cluster.
Use the Junos command-line interface (CLI) to load the baseline configuration.
Build the chassis cluster.
Configure an active/active chassis cluster.
Monitor traffic flows through the chassis cluster.
Disable the chassis cluster.
www.juniper.net Implementing High Availability Techniques (Detailed) Lab 81

12.a.12.1R1.9
Junos Security
Part 1: Loading the Baseline Configuration
Note
assigned device.
Step 1.1


IP address of 10.210.14.137.
Step 1.2
Lab 82 Implementing High Availability Techniques (Detailed) www.juniper.net

Junos Security
Step 1.3
srxC-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Part 2: Preparing and Forming a Chassis Cluster
In this lab part, you adjust the configuration and enable high availability chassis
clustering. You will work with the remote team in your assigned pod to make some
configuration adjustments and then join your assigned devices into a single virtual
device using chassis clustering.
Note
Throughout this lab, you work as a team
with all the members in your assigned lab
pod. Because a chassis cluster combines
two physical devices into one logical device,
it is important to follow the steps in order
and in tandem as a team. Perform the next
several steps on the SRX1 and SRX2
devices.
Step 2.1
Navigate to the [edit interfaces] hierarchy.
[edit]
lab@srxC-1# edit interfaces
[edit interfaces]
lab@srxC-1#

Junos Security
Step 2.2
Issue the show command.
[edit interfaces]
lab@srxC-1# show
ge-0/0/0 {
description "MGMT Interface - DO NOT DELETE";
unit 0 {
family inet {
address 10.210.14.135/27;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
ge-0/0/4 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members default;
}
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
[edit interfaces]
lab@srxC-1#

Junos Security
Question: You will not be performing Layer 2
Ethernet switching with the chassis cluster. Are
there any interfaces that must be removed before
chassis cluster pairing is attempted?
Answer: The ge-0/0/4 interface must be deleted.

The interface is configured for Layer 2 Ethernet
switching, and it will cause a malfunctioning
chassis cluster if pairing is attempted without
removing it. If it were necessary to perform Layer 2
switching with the chassis cluster, we recommend
that you disable any interface that is configured for
Layer 2 Ethernet switching before you attempt the
clustering. Then, once the chassis cluster has
formed, you can prepare it for Layer 2 Ethernet
switching by adding the swfab interfaces and
enabling the interfaces there were designated for
Ethernet switching.
You should also remove the ge-0/0/0 interface.
When the chassis cluster is formed, it will be
replaced with the fxp0 interface. Leaving the
ge-0/0/0 interface configured will cause the
chassis cluster formation to fail.
Step 2.3
Remove the ge-0/0/0 and ge-0/0/4 interfaces.
[edit interfaces]
lab@srxC-1# delete ge-0/0/0
[edit interfaces]
lab@srxC-1# delete ge-0/0/4
Step 2.4
Navigate to the [edit system] hierarchy level and delete the host-name
statement.
[edit interfaces]
lab@srxC-1# up 1 edit system
[edit system]
lab@srxC-1# delete host-name
[edit system]
lab@srxC-1#

Junos Security
Step 2.5
The steps 2.5 through 2.12 will be performed only on the SRX1 device.
From the Telnet session on the SRX1 device, navigate to the [edit groups
node0] hierarchy level.
[edit system]
lab@srxC-1# top edit groups node0
[edit groups node0]

lab@srxC-1#
Step 2.6
Configure a host name of srxY-1, where Y is the letter of your pod.
[edit groups node0]
lab@srxC-1# set system host-name srxY-1
Step 2.7
Configure the fxp0 interface with the management IP address for SRX1. Please refer
to the Management Network Diagram for this address.
[edit groups node0]
lab@srxC-1# set interfaces fxp0 unit 0 family inet address address/mask
Step 2.8
Navigate to the [edit groups node1] hierarchy level.
[edit groups node0]
lab@srxC-1# up 1 edit node1
[edit groups node1]

lab@srxC-1#
Step 2.9
Configure a host name of srxY-2, where Y is the letter of your pod.
[edit groups node1]
lab@srxC-1# set system host-name srxY-2
Step 2.10
Configure the fxp0 interface with the management IP address for SRX2. Please refer
to the Management Network Diagram for this address.
[edit groups node1]
lab@srxC-1# set interfaces fxp0 unit 0 family inet address address/mask
Step 2.11
Apply the recently created groups by issuing the command top set
apply-groups ${node}.
[edit groups node1]
lab@srxC-1# top set apply-groups ${node}
[edit groups node1]

lab@srxC-1# top show groups

Junos Security
node0 {
system {
host-name srxC-1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.210.14.135/27;
}
}
}
}
}
node1 {
system {
host-name srxC-2;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 10.210.14.136/27;
}
}
}
}
}
Question: What is the purpose of these recently

configured groups?
Answer: The recently configured groups will apply a

different host name and management IP address to
each node. You will then be able to telnet or ssh to
each nodes management address.
Step 2.12
The next several steps will be performed on the SRX1 and SRX2 devices.
From the Telnet session of your assigned SRX device, commit the configuration and
exit to operational mode.
[edit groups node1]
commit complete
lab@srxC-1>

Junos Security
Step 2.13
Initiate the chassis cluster pairing by issuing the command set chassis
cluster cluster-id 1 node node-id reboot, where node-id is 0 for
SRX1 and node-id is 1 for SRX2.
lab@srxC-1> set chassis cluster cluster-id 1 node node-id reboot
Successfully enabled chassis cluster. Going to reboot now
lab@srxC-1>
*** FINAL System shutdown message from root@srxC-1 ***
System going down IMMEDIATELY
FWaiting (max 60 seconds) for system process `vnlru' to stop...done

Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done
syncing disks... All buffers synced.

Uptime: 9m23s
Rebooting...
Step 2.14
Log in to the device once it has rebooted. Use the username and password provided
by your instructor.
Note
Once the required processes start,
depending on the model of your device, you
might see syslog messages indicating that
high availability clustering is active.
srxC-1 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

{primary:node0}
lab@srxC-1>
Question: Which host name is shown in the output?
Answer: The answer will depend on which

SRX device is your assigned device. The host name
of SRX1 should be shown, whereas the host name
of SRX2 will not be shown. A configuration change
and commit must occur before the groups
configuration can be passed on to SRX2.

Junos Security
Step 2.15
Issue the command show interface fxp0 terse.
{primary:node0}
lab@srxC-1> show interfaces terse fxp0
fxp0 up up
fxp0.0 up up inet 10.210.14.137/27
Question: Is your local SRX devices management IP

address applied to the fxp0 interface?
Answer: As with the previous question, the answer

depends on which SRX device is your assigned
SRX device. The management IP address of SRX1
should be applied to the interface. The
management IP address of SRX2 will not be applied
yet.
Note
Perform the next several steps only on the
SRX1 device. Both teams should be
working only from SRX1!
Step 2.16
The next several steps will be performed on the only on the SRX1 device.
From the Telnet session of SRX1, issue the command show chassis cluster
status.
{primary:node0}
lab@srxC-1> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1

node0 1 primary no no
node1 1 secondary no no

Junos Security
Question: Are both nodes present? What statuses
are they indicating?
Answer: Yes. Both nodes should be present. Node 0

status should display primary for redundancy
group 0 and Node 1 status should display
secondary for redundancy group 0. If the status
of the nodes indicate differently please inform your
instructor.
Question: Which redundancy groups are shown in

the output?
Answer: Because no redundancy groups are

configured, only redundancy group 0 is shown in
the previous output.
Question: The output displays that Node 0 is

primary for redundancy group 0. Where else can
this information be found?
Answer: Node 0 is primary for redundancy group 0.

The information can also be found by examining the
CLI command prompt.
Step 2.17
Issue the command show chassis cluster interfaces.
{primary:node0}
lab@srxC-1> show chassis cluster interfaces
Control link status: Up
Control interfaces:
Index Interface Status
0 fxp1 Up
Fabric link status: Down
Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fab0
fab0

Junos Security
fab1
fab1
Question: What is the status of the control link?
Answer: The Control link status field should

display a value of Up.
Question: What is the status of the fabric link?
Answer: The fabric link is down and is not

operational.
Question: Which steps are needed to bring the

fabric link to the operational state?
Answer: The fab0 and fab1 interfaces must be

configured.
Step 2.18
Enter configuration mode, navigate to the [edit interfaces] hierarchy, and
configure the fab0 and fab1 interfaces that comprise the fabric link. Refer to your
Lab 8 network diagram for the appropriate member interfaces. When you are
finished, commit the configuration and return to operational mode.
Note
When chassis clustering is enabled
commits can only be issued from the top of
the configuration hierarchy.
{primary:node0}
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
{primary:node0}[edit]
{primary:node0}[edit interfaces]
lab@srxC-1# set fab0 fabric-options member-interfaces ge-0/0/2

Junos Security
lab@srxC-1# set fab1 fabric-options member-interfaces ge-5/0/2
lab@srxC-1# top
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete
{primary:node0}
lab@srxC-1>
Step 2.19
Issue the command show chassis cluster interfaces.
{primary:node0}
lab@srxC-1> show chassis cluster interfaces
Control interfaces:
0 fxp1 Up
Fabric link status: Up
Fabric interfaces:
fab0 ge-0/0/2 Up / Up
fab0
fab1
Question: What is the fabric link status?
Answer: The fabric link status should be listed as

Up.
STOP
so.

Junos Security
Part 3: Configuring an Active/Active Cluster
In this lab part, you configure redundancy group 1 and redundancy group 2 in an
active/active cluster configuration.
Step 3.1
Enter configuration mode and load the lab8-part3-start.config from the
[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 3.2
Navigate to the [edit chassis cluster] hierarchy level. Next configure
redundancy group 1 to have Node 0 with a priority of 200 and Node 1 with a
priority of 100.
lab@srxC-1# edit chassis cluster
{primary:node0}[edit chassis cluster]

lab@srxC-1# set redundancy-group 1 node 0 priority 200


lab@srxC-1#
Step 3.3
Configure redundancy group 2 to have Node 1 with a priority of 200 and
Node 0 with a priority of 100. Then configure Node 1 to automatically
reacquire primacy during a failover scenario once the original problem that caused
the failover has been fixed.


lab@srxC-1# set redundancy-group 2 preempt
Junos Security
Step 3.4
Configure the chassis cluster to perform interface monitoring for redundancy
group 2. The redundancy group should fail over to Node 0 if the ge-5/0/3 interface
goes down. Use a weight value of 255.
Note
You will configure the ge-5/0/3 interface in
a later step.

lab@srxC-1# set redundancy-group 2 interface-monitor ge-5/0/3 weight 255

lab@srxC-1# show
redundancy-group 1 {
node 0 priority 200;
}
redundancy-group 2 {
preempt;
interface-monitor {
##
## Warning: Interface must be defined before configuring monitoring
##
ge-5/0/3 weight 255;
}
}
Step 3.5
Navigate to the [edit interfaces] hierarchy level. Configure the reth0
interface to consist of interfaces ge-0/0/4 and ge-5/0/4. Next associate reth0 with
redundancy group 1.Then configure reth0 to accept and transmit 802.1Q frames,
and configure it with the proper VLAN ID and IP address. Please refer to your
network diagram for Lab 8 for the correct VLAN and IP address values.
lab@srxC-1# top edit interfaces
lab@srxC-1# set ge-0/0/4 gigether-options redundant-parent reth0
lab@srxC-1# set reth0 redundant-ether-options redundancy-group 1
lab@srxC-1# set reth0 vlan-tagging

Junos Security
lab@srxC-1# set reth0 unit reth0-vlan-id vlan-id reth0-vlan-id
lab@srxC-1# set reth0 unit reth0-vlan-id family inet address reth0-address/mask
Step 3.6
Configure the reth1 interface to consist of interfaces ge-0/0/5 and ge-5/0/5. Next
associate reth1 with redundancy group 2. Then configure reth1 to accept and
transmit 802.1Q frames, and configure it with the proper VLAN ID and IP address.
Please refer to your Lab 8 network diagram for the correct VLAN and IP address
values.
lab@srxC-1# set reth1 redundant-ether-options redundancy-group 2
lab@srxC-1# set reth1 vlan-tagging
lab@srxC-1# set reth1 unit reth1-vlan-id vlan-id reth1-vlan-id
lab@srxC-1# set reth1 unit reth1-vlan-id family inet address reth1-address/mask
Step 3.7
Configure the ge-5/0/3 interface with the 172.18.2.2/30 address. Commit the
configuration when you are finished.
lab@srxC-1# set ge-5/0/3 unit 0 family inet address 172.18.2.2/30
lab@srxC-1# show
ge-0/0/3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
ge-0/0/4 {
gigether-options {
redundant-parent reth0;
}
}
ge-0/0/5 {
gigether-options {

Junos Security
}
}
ge-5/0/3 {
unit 0 {
family inet {
address 172.18.2.2/30;
}
}
}
ge-5/0/4 {
gigether-options {
}
}
ge-5/0/5 {
gigether-options {
}
}
...
reth0 {
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
}
unit 223 {
vlan-id 223;
family inet {
address 172.20.30.1/24;
}
}
}
reth1 {
vlan-tagging;
redundant-ether-options {
redundancy-group 2;
}
unit 233 {
vlan-id 233;
family inet {
address 172.30.30.1/24;
}
}
}
lab@srxC-1# top
lab@srxC-1# commit
[edit chassis cluster]
'redundancy-group 1'
redundancy-group-id (1) cannot exceed reth-count (0)

Junos Security
error: configuration check-out failed
lab@srxC-1#
Question: Were you able to commit the

configuration?
Answer: No. The configuration will not commit

because the reth count of 0 was exceeded.
Question: Where can you increase the reth count?
Answer: You can increase the reth count under the

[edit chassis cluster] hierarchy level.
Step 3.8
Navigate to the [edit chassis cluster] hierarchy level and increase the reth
count to 2. Commit the configuration when you are finished.
lab@srxC-1# edit chassis cluster

lab@srxC-1# set reth-count 2

lab@srxC-1# top
lab@srxC-1# commit
node0:
node1:
commit complete
node0:
commit complete
Question: Why would you not want to set the reth

count to its maximum possible number?
Answer: Increasing the reth count increases the

number of reth interfaces created by the system,
which in turn uses more system resources.
Junos Security
Step 3.9
Issue the command run show chassis cluster interfaces.
lab@srxC-1# run show chassis cluster interfaces
Control interfaces:
0 fxp1 Up
Fabric interfaces:
fab0
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down 1
reth1 Down 2
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-5/0/3 255 Up 2
Question: Within which redundancy groups are

reth0 and reth1 contained?
Answer: Reth0 is contained within redundancy

group 1 and reth1 is contained within redundancy
group 2.
Step 3.10
Issue the command run show chassis cluster status.
lab@srxC-1# run show chassis cluster status
Cluster ID: 1


Junos Security

node0 100 secondary yes no
node1 200 primary yes no
Question: Which node is primary for redundancy

group 2?
Answer: Node 1 is primary for redundancy group 2.
Question: Why is Node 0 primary for redundancy

group 0?
Answer: Both nodes have the same priority value

and so Node 0 is primary because it has a lower
node ID.
Question: How would you ensure Node 0 acquires

primacy for redundancy group 0 if both nodes
reboot around the same time?
Answer: You can configure Node 1 with a higher

priority value than Node 0 for redundancy group 0.
Step 3.11
Configure Node 1 to have a higher priority value than Node 0 for redundancy
group 0. Commit the configuration when you are finished.
lab@srxC-1# set chassis cluster redundancy-group 0 node 1 priority 254
lab@srxC-1# commit
node0:
node1:
commit complete

Junos Security
node0:
commit complete
Step 3.12
Issue the command run show chassis cluster status.
Cluster ID: 1



lab@srxC-1#
Question: Which node will acquire primacy for

redundancy group 0 if both nodes reboot at the
same time?
Answer: Node 1 will have primacy for redundancy

group 0 if both nodes are rebooted at the same
time.
Question: Why is node 0 still the primary node for

redundancy group 0?
Answer: Even though Node 1 has a higher priority

value for redundancy group 0, a failover event must
occur to cause node 1 to become primary for
redundancy group 0.

Junos Security
Step 3.13
Navigate to the [edit security] hierarchy level. Then configure the systems
default-policy to allow all traffic.
Note
This lab step is for the purpose of simplicity.
You should never use a default security
policy to permit all traffic outside of a lab
environment.
lab@srxC-1# edit security
{primary:node0}[edit security]
lab@srxC-1# set policies default-policy permit-all
{primary:node0}[edit security zones]

lab@srxC-1#
Step 3.14
Navigate to the [edit security zones] hierarchy and configure the untrust
zone to contain interfaces ge-0/0/3 and ge-5/0/3. No inbound protocols or services
should be allowed on these interfaces.
{primary:node0}[edit security]
lab@srxC-1# edit zones

lab@srxC-1# set security-zone untrust interfaces ge-0/0/3

lab@srxC-1# set security-zone untrust interfaces ge-5/0/3
Step 3.15
Configure the trust zone to contain interfaces reth0 and reth1. All system services
should be allowed on these interfaces. Commit the configuration and exit to
operational mode.
Note
The reth interfaces are configured with a
different unit number than 0. Make sure to
use the correct unit number in this step.

lab@srxC-1# set security-zone trust interfaces reth0.reth0-vlan-id
host-inbound-traffic system-services all

lab@srxC-1# set security-zone trust interfaces reth1.reth1-vlan-id
host-inbound-traffic system-services all
lab@srxC-1# show
zones {
security-zone untrust {

Junos Security
interfaces {
ge-0/0/3.0;
ge-5/0/3.0;
}
}
security-zone trust {
interfaces {
reth0.223 {
system-services {
all;
}
}
}
reth1.233 {
system-services {
all;
}
}
}
}
}
}
policies {
default-policy {
permit-all;
}
}
Step 3.16
Delete the current default static route and configure two default floating static
routes through the use of the qualified-next-hop option. The route which has
a next hop of 172.18.1.1 will have a route preference of 5. The route which has a
next hop of 172.18.2.1 will have a route preference of 10. Commit the
configuration and exit to operational mode.
lab@srxC-1# top edit routing-options
{primary:node0}[edit routing-options]
lab@srxC-1# delete static route 0/0
lab@srxC-1# set static route 0/0 qualified-next-hop 172.18.1.1
lab@srxC-1# set static route 0/0 qualified-next-hop 172.18.2.1 preference 10
lab@srxC-1# top
node0:

Junos Security
node1:
commit complete
node0:
commit complete
{primary:node0}
lab@srxC-1>
Step 3.17
Issue the show route 0/0 exact command.
lab@srxC-1> show route 0/0 exact
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 1d 20:53:32

> to 172.18.1.1 via ge-0/0/3.0
[Static/10] 19:41:40
> to 172.18.2.1 via ge-5/0/3.0
Question: Is the correct routing information

displayed?
Answer: The correct output should display a default

static route with two next hops. The next hop with a
route preference of 5 directs traffic through the
ge-0/0/3 interface. The next hop with a route
preference of directs traffic through the
ge-5/0/3 interface.
Step 3.18
Check connectivity by issuing pings to both virtual router interface addresses. Next,
ping both interface addresses that belong to the ISP, and then ping the Internet
host. Use the detail option to ensure the pings are egressing the correct
interface. Please refer to your Lab 8 network diagram for these addresses.
{primary:node0}
lab@srxC-1> ping reth0-VR detail count 2
PING 172.20.30.2 (172.20.30.2): 56 data bytes
64 bytes from 172.20.30.2 via reth0.223: icmp_seq=0 ttl=64 time=1.678 ms

{primary:node0}
lab@srxC-1> ping reth1-VR detail count 2

Junos Security
PING 172.30.30.2 (172.30.30.2): 56 data bytes

{primary:node0}
lab@srxC-1> ping 172.18.1.1 detail count 2
PING 172.18.1.1 (172.18.1.1): 56 data bytes
64 bytes from 172.18.1.1 via ge-0/0/3.0: icmp_seq=0 ttl=64 time=1.974 ms

{primary:node0}
PING 172.18.2.1 (172.18.2.1): 56 data bytes

{primary:node0}
PING 172.31.15.1 (172.31.15.1): 56 data bytes

Question: Were the ping tests successful?
Answer: As shown in the output, the ping tests

should be successful.
STOP
so.

Junos Security
Part 4: Monitoring Traffic Flows
In this lab part, you generate traffic from the attached virtual routers and monitor
the traffic flows. You will also examine the path which these flows take and the
effect of asymmetric flows on the chassis cluster.
Step 4.1
Enter configuration mode and load the lab8-part4-start.config from the
[edit]
[edit]
lab@srxC-1# commit
commit complete
[edit]
lab@srxC-1#
Step 4.2
Open a separate Telnet session to the virtual router attached to your teams device.

Junos Security
Step 4.3
Student Pod Username Password

srxA a1 lab123
srxB b1 lab123
srxC c1 lab123
srxD d1 lab123
vr-device (ttyp0)
login: username
Password:
--- JUNOS 11.4R3.7 built 2012-05-14 22:22:03 UTC
d1@vr-device>
Step 4.4
Generate traffic to the Internet host from the virtual router associated with reth0 by
issuing the ping 172.31.15.1 rapid count 1000000
routing-instance reth0-VR command.
d1@vr-device> ping 172.31.15.1 rapid count 1000000 routing-instance reth0-VR
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
Step 4.5
From the Telnet session established with SRX1, issue the run monitor
interface traffic command. You must find the correct interfaces in the
output to answer the following questions. Press Ctrl + d or Ctrl + u to scroll down or
up.
Note
Examine the packets -per-second(pps)
field to see the current packets traveling
through an interface.

Junos Security
lab@srxC-1# run monitor interface traffic
srxC-1 Seconds: 56 Time: 22:18:12
Interface Link Input packets (pps) Output packets (pps)

ge-0/0/0 Up 0 (0) 0 (0)
ge-0/0/1 Up 0 (0) 0 (0)
ge-0/0/2 Up 0 (0) 2932819 (4)
ge-0/0/3 Up 3637472 (222) 3633355 (223)
ge-0/0/4 Up 1030660 (222) 1030584 (222)
ge-0/0/5 Up 51 (0) 0 (0)
...
ge-5/0/2 Up 0 (0) 2930341 (4)
ge-5/0/3 Up 4052 (0) 58 (0)
ge-5/0/4 Up 108 (0) 0 (0)
ge-5/0/5 Up 2602848 (0) 2602875 (0)
...
fab0 Up 0 (0) 2928169 (4)
fab1 Up 0 (0) 2928170 (4)
...
reth0 Up 817823 (228) 817596 (228)
reth1 Up 2602898 (0) 2602875 (0)
st0 Up 0 (0) 0 (0)
tap Up 0 0
Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
Note
Examine your Lab 8 diagram to help trace
the path of the traffic flow.
Question: Which reth interface is the traffic

traveling through?
Answer: The traffic is traveling through reth0.
Question: Which child interface of reth0 is being

used?
Answer: The ge-0/0/4 interface is being used.

Junos Security
Question: What is the next interface being used in
the path of the traffic?
Answer: The next interface being used is ge-0/0/3 .
Question: Is the fabric link being used for this traffic

flow?
Answer: No. The traffic flow is bypassing the fabric

link.
Question: When would this traffic flow use the fabric

link?
Answer: If Node 1 becomes the primary node for

redundancy group 1 the ge-5/0/4 interface would
be used to pass traffic for reth0. Then the traffic
would travel across the fabric link to reach its
destination.
Step 4.6
From the Telnet session established with the virtual router, press Ctrl + c to stop the
ping traffic.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!^C
Step 4.7
Generate traffic to the Internet host from the virtual router associated with reth1 by
issuing the ping 172.31.15.1 rapid count 1000000
routing-instance reth1-VR command.
PING 172.31.15.1 (172.31.15.1): 56 data bytes

Junos Security
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
Step 4.8
Find the correct interfaces in the output to answer the following questions. Press
Ctrl + d or Ctrl + u to scroll down or up.
Note
If you canceled the output previously, you
must restart it by issuing the monitor
interface traffic command.
ge-0/0/0 Up 0 (0) 0 (0)

ge-0/0/1 Up 0 (0) 0 (0)
ge-0/0/2 Up 0 (0) 2989317 (215)
ge-0/0/3 Up 3637472 (222) 3633355 (223)
ge-0/0/4 Up 9 (0) 17 (0)
ge-0/0/5 Up 9 (0) 0 (0)
...
ge-5/0/2 Up 0 (0) 85527 (200)
ge-5/0/3 Up 13476 (0) 7 (0)
ge-5/0/4 Up 31 (0) 0 (0)
ge-5/0/5 Up 36374 (194) 36384 (194)
...
fab0 Up 0 (0) 3139723 (219)
fab1 Up 0 (0) 3140093 (211)
fxp0 Up 779 66
fxp1 Up 1200337 2019915
fxp2 Up 0 71147
...
ge-5/0/2 Up 0 (0) 2989317 (215)
ge-5/0/3 Up 4402 (0) 63 (0)
ge-5/0/4 Up 112 (0) 0 (0)
ge-5/0/5 Up 2633482 (210) 2633345 (210)
...
reth0 Up 2190832 (0) 2190753 (0)
reth1 Up 2604412 (207) 2604125 (207)
st0 Up 0 (0) 0 (0)
tap Up 0 0

Junos Security
Question: Which reth interface is the traffic
traveling through?
Answer: The traffic is traveling through reth1.
Question: Which child interface of reth1 is being

used?
Answer: The ge-5/0/5 interface is being used.
Question: What is the next interface being used in

the path of the traffic?
Answer: The next interface being used is fab1 .
Question: Is the fabric link being used for this traffic

flow?
Answer: Yes. The traffic flow is traveling through the

fabric link.
Question: When would this traffic flow not use the

fabric link?
Answer: If Node 0 becomes the primary node for

redundancy group 2 the ge-0/0/5 interface would
be used to pass traffic for reth1. Then the traffic
would bypass the fabric link to reach its destination.

Junos Security
Step 4.9
Press the q key to exit the running output. Navigate to the [edit interfaces]
hierarchy level. Disable the ge-5/0/3 interface. When you are finished, commit
the configuration.
...
ge-0/0/8 Up 0 (0) 0 (0)
ge-0/0/9 Up 0 (0) 0 (0)
ge-0/0/10 Up 0 (0) 0 (0)
ge-0/0/11 Up 0 (0) 0 (0)
ge-0/0/12 Down 0 (0) 0 (0)
ge-0/0/13 Down 0 (0) 0 (0)
ge-0/0/14 Down 0 (0) 0 (0)
ge-0/0/15 Down 0 (0) 0 (0)
se-1/0/0 Down 0 (0) 0 (0)
ge-5/0/0 Up 0 (0) 0 (0)
ge-5/0/1 Up 0 (0) 0 (0)
lab@srxC-1# set ge-5/0/3 disable
lab@srxC-1# top
lab@srxC-1# commit
node0:
node1:
commit complete
node0:
commit complete
lab@srxC-1#
Step 4.10
Issue the run show chassis cluster interfaces command.
lab@srxC-1# run show chassis cluster interfaces
Control interfaces:
0 fxp1 Up

Junos Security
Fabric interfaces:
fab0
fab1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
reth1 Up 2
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-5/0/3 255 Down 2
Question: What is the monitoring status of the

ge-5/0/3 interface?
Answer: The Status field indicates that the

ge-5/0/3 interface is down.
Step 4.11
Issue the run show chassis cluster status command.
Cluster ID: 1




Junos Security
Question: Did disabling the ge-5/0/3 interface
cause redundancy group 2 to failover primacy?
Answer: Yes. Redundancy group 2 has failed over

primacy from Node 1 to Node 0.
Step 4.12
If the ping test is still running from the Telnet session established with the virtual
router, cancel it with the Ctrl+c key combination. Then issue the ping
172.31.15.1 rapid count 1000000 routing-instance reth1-VR
command.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!^C

PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
Step 4.13
From the Telnet session established with SRX1, issue the run monitor
interface traffic command. You must find the correct interfaces in the
output to answer the following questions. Press Ctrl + d or Ctrl + u to scroll down or
up.
lab@srxC-1# run monitor interface traffic

...
ge-0/0/2 Up 0 (0) 4304107 (4)
ge-0/0/3 Up 8006370 (231) 8000898 (231)
ge-0/0/4 Up 3365327 (0) 3365369 (0)
ge-0/0/5 Up 764832 (231) 763742 (231)
ge-0/0/6 Up 0 (0) 0 (0)
...

Junos Security
ge-5/0/3 Down 5066 (0) 602 (0)
ge-5/0/4 Up 128 (0) 0 (0)
ge-5/0/5 Up 3872438 (0) 3871958 (0)
ge-5/0/6 Up 0 (0) 0 (0)
...
fab0 Up 0 (0) 4301297 (4)
fab1 Up 0 (0) 4301297 (4)
...
reth0 Up 3365455 (0) 3365369 (0)
reth1 Up 4664221 (231) 4662735 (231)
st0 Up 0 (0) 0 (0)
tap Up 0 0
Question: Which child interface of reth1 is the

traffic traveling through?
Answer: The traffic is traveling through the

ge-0/0/5 interface.
Question: What is the next step in the path for this

traffic?
Answer: The traffic is traveling through the

ge-0/0/3 interface towards the Internet Host.
Question: Is the fabric link being used for this

traffic?
Answer: No. The traffic path does not involve the

fabric link.
Step 4.14
Remove the disable option that was placed on the ge-5/0/3 interface. Once you
are finished, commit the configuration and exit to operational mode.
lab@srxC-1# delete interfaces ge-5/0/3 disable

Junos Security
node0:
node1:
commit complete
node0:
commit complete
{primary:node0}
lab@srxC-1>
Step 4.15
Issue the show chassis cluster status command.
{primary:node0}
lab@srxC-1> show chassis cluster status
Cluster ID: 1



Question: Why did the primacy for redundancy

group 2 fail back over to node1?
Answer: The preempt command is enabled for

redundancy group 2. This command allows the
node that originally had primacy to reacquire it
when the failure condition is fixed.
Step 4.16
From the Telnet session established with the virtual router, press Ctrl + c to stop the
ping traffic. Then, log out of the vr-device.
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!^C

Junos Security
c1@vr-device> exit
Part 5: Disabling the Chassis Cluster
In this lab part, you break down the chassis cluster implementation. You will then
load the reset configuration on each node.
Step 5.1
From the Telnet session established with SRX1, issue the set chassis
cluster disable reboot command.
{primary:node0}
lab@srxC-1> set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now{primary:node0}
lab@srxC-1>
Step 5.2
Once the SRX1 device reboots, log in using the lab user account.
Note
The Amnesiac banner is displayed and
there is no host name for Node 0. Recall
that apply-groups were used to implement
the host name during chassis clustering.
SrxX-1 currently has no configured host
name.
Amnesiac (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab>
Step 5.3
Enter configuration mode and issue the load override /var/home/lab/
jsec/reset.config command to load the reset configuration. Commit the
lab> configure
[edit]
lab# load override jsec/reset.config
load complete

Junos Security
[edit]
lab# commit and-quit
commit complete
lab@srxC-1>
Step 5.4
Log in to the SRX2 device using the lab user account. Issue the set chassis
cluster disable reboot command.
srxC-2 (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC
{primary:node1}
lab@srxC-2> set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now
{primary:node1}
lab@srxC-2>

Step 5.5
Once the SRX2 device reboots, log in using the lab user account.
Note
The Amnesiac banner is displayed and
there is no host name for Node 1. Recall
that apply-groups were used to implement
the host name during chassis clustering.
SrxX-1 currently has no configured host
name.
Amnesiac (ttyu0)
login: lab
Password:
--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

lab>
Step 5.6
Enter configuration mode and issue the load override /var/home/lab/
jsec/reset.config command to load the reset configuration. Commit the
lab> configure

Junos Security
[edit]
lab# load override jsec/reset.config
load complete
[edit]
lab# commit and-quit
commit complete
lab@srxC-2>

Junos Security
Appendix A: Lab Diagrams

Junos Security
A2 Lab Diagrams www.juniper.net

Junos Security
www.juniper.net Lab Diagrams A3

Junos Security

Junos Security

Junos Security

Junos Security

Junos Security

JSEC 12.a-R LGD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

JSEC 12.a-R LGD

Transféré par

Droits d'auteur :

Formats disponibles

Junos Security

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-JSEC

Lab 2: Security Policies (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Lab 3: Configuring Firewall Authentication (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Lab 4: Implementing Screen Options (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Lab 5: Network Address Translation (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Lab 6: Implementing IPsec VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Lab 7: Implementing IDP (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Lab 8: Implementing High Availability Techniques (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Appendix A: Lab Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1

www.juniper.net Contents iii

www.juniper.net Course Overview v

vi Course Agenda www.juniper.net

CLI and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is policy my-peers

www.juniper.net Document Conventions vii

Education Services Offerings

viii Additional Information www.juniper.net

www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 11

Part 1: Logging In Using the CLI

Question: What is the management address

Answer: The answer varies. The sample hostname

Lab 12 Configuring and Monitoring Zones (Detailed) www.juniper.net

--- JUNOS 12.1R1.9 built 2012-03-24 12:12:49 UTC

www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 13

Answer: As shown in the output, no zone currently

Question: What do you notice about the security

Answer: As indicated by the output from srxA-1,

Lab 14 Configuring and Monitoring Zones (Detailed) www.juniper.net

Question: Which VLAN-IDs are associated with your

Answer: The answer varies. The VLAN-IDs

www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 15

Part 2: Verifying Network Connectivity

Question: What is the administrative status and link

Answer: As shown in the output taken from srxA-1,

Question: What is the status of your management

Answer: The management interface is ge-0/0/0.0

www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 17

Question: Was the ping to your remote peer

Answer: As indicated by the output from srxA-1, the

Lab 18 Configuring and Monitoring Zones (Detailed) www.juniper.net

Virtual Router Login Details

Student Device Username Password

--- JUNOS 11.4R1.6 built 2011-11-15 11:28:05 UTC

You must use 'configure private' to configure this router.

a1@vr-device> ping remote-ACME-VR routing-instance local-ACME-VR rapid

www.juniper.net Configuring and Monitoring Zones (Detailed) Lab 19

a1@vr-device> ping remote-Juniper-VR routing-instance local-Juniper-VR rapid

a1@vr-device> ping remote-ACME-VR routing-instance local-Juniper-VR rapid

a1@vr-device> ping remote-Juniper-VR routing-instance local-ACME-VR rapid

Question: Were the pings between remote

Answer: As indicated by the output from user a1,

Part 3: Configuring Zones