AJEST 12.b LGD PDF

Ativanced Junos Enterprise Security
Troubleshooting
12.b
Lab Guide
JLJn1Per NETWORKS
Worldwide Education Services
1133 Innovation Way

Sunn)Nale, CA 94089
USA
408-745-2000
www.juniper.net
Course Number: EDU-JUN-AJEST

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, the Juniper Networks logo, Junos. NetScreen. and ScreenOS are registered trademarks of Juniper Networks. Inc. in the United States and other
countries. All other trademarks, service marks, registered trademarks. or registered service marks are the property of their respective owners.
Advanced Junos Enterprise Security Troubleshooting Lab Gulde. Revision 12.b

Copyright© 2014 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 12.a-June 2013
Revision 12.b-January 2014
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.lRS.5. 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 lias
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:: Troubleshooting Security Zones and Policies ........................ 1-1
Part 1: Accessing Your Device and Verifying the Connectivity ..................................... 1-2
Part 2: Troubleshooting Zones .............................................................. 1-7
Part 3: Troubleshooting Security Policies .................•................................... 1-11
Part 4: Troubleshooting Security Policies for Host Traffic ........................................ 1-16
Lab 2:: Troubleshooting IPsec ........................................... 2-1

Part 2: Examining the IPsec Configuration and Troubleshooting IPsec VPNs ...••...••..•............ 2-4
Part 3: Troubleshooting Connectivity in IPsec VPNs ............................................ 2-14
Lab 3:: Troubleshooting Security Features ................................. 3-1

Part 2: Examining and Troubleshooting UTM ................................................... 3-7
Part 3: Examining and Troubleshooting AppSecure features ................•...•.....•...•...... 3-15
Lab 4:: Troubleshooting Chassis Clustering ................................ 4-1

Part 2: Forming and Troubleshooting a Chassis Cluster .......................................... 4-4
Part 3: Monitoring a Chassis Cluster ........................................................ 4-12
Part 4: Disabling the Chassis Cluster ..................................................•..... 4-20
www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview
This one-day course is designed to provide students with information about troubleshooting IPsec,
security zones and policies, other security features, and chassis clustering. Students will gain
experience in monitoring and troubleshooting these topics through demonstration as well as
hands-on labs. The course exposes students to common troubleshooting commands and tools
used to troubleshoot various intermediate to advanced issues.
This course uses Juniper Networks SRX Series Services Gateways for the hands-on component, but
the lab environment does not preclude the course from being applicable to other Juniper hardware
platforms running the Junos OS. This course is based on Junos OS Release 12.1R5.5.
Objectives
After successfully completing this course, you should be able to:
Troubleshoot security zones.
Troubleshoot security policies.
Troubleshoot IPsec virtual private network (VPN) problems.
Troubleshoot Internet Key Exchange (IKE) phase 1 issues.
Troubleshoot IKE phase 2 issues.
Verify and troubleshoot AppSecure.
Monitor and troubleshoot intrusion prevention systems (IPS).
Verify and troubleshoot UTM.
Verify, monitor, and troubleshoot chassis clustering issues.
Troubleshoot different chassis clustering modes.
List the general chassis components.
Identify different methods for troubleshooting major chassis components.
Troubleshoot redundant Routing Engine and Control Board communication.
lntend1�d Audience
The primary audience for this course is the following:
Individuals responsible for configuring and monitoring devices running the Junos OS.
Course Level
Advanced Junos Enterprise Security Troubleshooting is an advanced-level course.
Prerequisites
The following courses are the prerequisites for this course:
Junos Troubleshooting in the NOC (JTNOC);
Advanced Junos Security (AJSEC);
Junos Intrusion Prevention Systems (JIPS): and
Junos Unified Threat Management (JUTM).
www.juniper.net Course Overview • v

Course Agenda
Day1
Chapter 1: Course Introduction
Chapter 2: Troubleshooting Security Zones and Policies
Troubleshooting Security Zones and Policies Lab
Chapter 3: Troubleshooting IPsec
Troubleshooting IPsec Lab
Chapter 4: Troubleshooting Security Features
Troubleshooting Security Features Lab
Chapter 5: Troubleshooting Chassis Clusters
Troubleshooting Chassis Clustering Lab
Appendix A: SRX Hardware Troubleshooting
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.confin 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. Phy sical interface:fxpO,

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 already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
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 Advanced Junos Enterprise Security Troubleshooting Lab Guide was developed and tested
using software Release 12.1R5.5. 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.netjtechpubs/.
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.netjcustomers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (outside the United States).
viii • Additional Information www.juniper.net

Lab
Troubleshooting Security Zones and Policies
Overview
In this lab, you will troubleshoot security zones and policies. You will use Junos OS CLI
commands and analyze trace log files to find out the causes for the detected problems.
Next you define the solution for the issues and perform it.
By completing this lab, you will perform the following tasks:
Troubleshoot security zones.
Troubleshoot security policies.
Perform configuration corrections.
www.juniper.net Troubleshooting Security Zones and Policies • Lab 1-1

Advanced Junos Enterprise Security Troubleshooting
Part 1: Accessing Your Device and Verifying the Connectivity
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 designated station. Next, you will load the starting configuration 'or the
lab. Then, you will verify the connectivity between your assigned virtual routers and
your device.
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 device you are assigned. Check with your instructor if
necessary. 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 srxC-1, which uses 10.210.14.135 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 1-2 • Troubleshooting Security Zones and Policies www.ju11iper.net

Advanced Ju nos Enterprise Security Troubleshooting
D Show quick connect on startup [t] Save session

0 Open in a tab
I, Connect� [__ca_n_ce_l�
Step 1.3
Log in as user lab with the password labl23. Enter configuration mode and load
the labl-start. configfrom the /var/home/lab/ajestj directory.Commit the
configuration when complete.
srxC-1 (ttypO)
login: lab
Password:
--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

lab@srxC-1> configure
Entering configuration mode
[edit]
lab@srxC-1# load override ajest/labl-start.config
load complete
lab@srxC-1# commit and-quit

commit complete
Exitin9 configuration mode
lab@srxC-1>
Step 1.4
Check the status of your configured Gigabit Ethernet and loopback interfaces using
the show interfaces terse I match "ge I lo" command.
lab@srxC-1> show interfaces terse I match 11 gello 11
Interface Admin Link Proto Local Remote
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.14.135/27
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.105 up up inet 172.20.105.1/24
ge-0/0/4.205 up up inet 172.20.205.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up up
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up down
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
ge-0/0/15 up up
loo up up
loO.O up up inet 192.168.1.1 --> 0/0
lo0.16384 up up inet 127.0.0.l --> 0/0
lo0.16385 up up inet 10.0.0.l --> 0/0
lo0.32768 up up
Question: What is the administrative status and link

status of your configured interfaces?
Answer: As shown in the output, 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 1.5
Open a separate Telnet session to the virtual router attached to your team device.
Lab 1-4 • Troubleshooting Security Zones and Policies www.juniper.net

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 Diagram for the IP address of the
vr-device.
D Show quick connect on startup 0 Save session

0 Open in a tab
i Connect ij I Cancel J
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 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23

vr-device (ttypO)
login: username
Password:
--- JUNOS ll.4Rl.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.
cl@vr-device>
Step 1.6
From the Telnet session established with the virtual router, verify reachability from
virtual routers assigned to you to their respective interface on your device 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.
cl@vr-device> ping local-Juniper-address routing-instance local-Juniper-VR

count 3
PING 172.20.105.1 (172.20.105.1): 56 data bytes
64 bytes from 172.20.105.1: icmp seq=O ttl=64 time=3.610 ms
64 bytes from 172.20.105.1: icmp_seq=l ttl=64 time=3.645 ms
64 bytes from 172.20.105.1: icmp_seq=2 ttl=64 time=3.593 ms
--- 172.20.105. 1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.593/3.616/3.645/0.022 ms
cl@vr-device> ping local-ACME-address routing-instance local-ACME-VR count 3

PING 172.20.205.1 (172.20.205.1): 56 data bytes
64 bytes from 172.20.205.1: icmp seq=2 ttl=64 time=3.593 ms
--- 172.20.205.1 ping statistics ---


Question: Are the pings successful?
Answer: As indicated by the output, both pings

should be successful. If you experience different
behavior notify your instructor.
Part 2: Troubleshooting Zones
In this lab part, you will troubleshoot problems related to security zones and
interface assignment to security zones. You first experience the problem, then use
CU tools to find the problem cause and finally you define the solution and resolve
the problem.
Step 2.1
Test the connectivity from your Juniper virtual router to your SRX's loopback address.
cl@vr-d.evice> ping local-loopback routing-instance local-Juniper-VR count 3
PING 192.168.1.1 (192.168.1.1): 56 data bytes
--- 192.168.1.1 ping statistics

Note
Question: Was the ping successful?
Answer: As indicated by the output, the ping is not

successful. If you experience different behavior
notify your instructor.
Step 2.2
View the forwarding decision on your Juniper virtual router to the SRX's loopback.
cl@vr-d.evice> show route local-loopback table local-Juniper-VR.inet.O
vrlOS.inet.O: 11 destinations, 11 routes (11 active, 0 holddown, O hidden)

+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/SJ ld 07:04:57

> to 172.20.105.1 via ge-0/0/1.105

Advanced Junes Enterprise Security Troubleshooting
Note
Question: Does the virtual router make correct

forwarding decision?
Answer: As indicated by the output, the virtual

router has correct route to reach the SRXs loopback
interface as depicted in the lab diagrams. If the
route shown is incorrect notify your instructor.
Question: Based on the gathered information can

you tell which device seems to be dropping the
packets?
Answer: Because the pings are sent from the virtual

router to the SRX device and virtual router uses the
correct interface the SRX seems to be the device
discarding the packets.
Step 2.3
Return to the Telnet session established with your assigned SRX device.
From your assigned SRX device check if the loopback interface loO.O zones
assignment and if the ping is allowed in the host-inbound-traffic.
lab@srxC-1> show interfaces loO.O I find Security
Security: Zone: Null
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Default Is-Primary
Local: 192.168.l.l

Question: What can you tell from the command
output?
Answer: The loO.O interface is assigned to Null zone

and has not allowed anything in the
host-inbound-traffic. If an interface belongs to the
Null zone all traffic on that interface is dropped.
Question: What next step would you take?
Answer: An interface belonging to the Null zone

means the interface is not assigned to any zone in
the configuration. Obviously the next step is to
assigned loO.O interface to a security zone.
Step 2.4
Enter configuration mode and assign the loO.O interface to either the Juniper-SV or
Juniper-WF zone. Check if the zone host-inbound-traffic allows ping. Commit the
configuration changes and exit to operational mode.
[edit]
lab@srxC-1# set security zones security-zone Juniper-local interfaces loO.O
[edit]
lab@srxC-1# show security zones security-zone Juniper-local
address-book {
address vrl05 172.20.105.0/24;
}
host-inbound-traffic {
system-services {
all;
protocols
all;
interfaces
ge-0/0/4.105;
loO.O;
[edit]
commit complete

Exiting configuration mode
lab@srxC-1>
Question: Is ping allowed in the Juniper-local

zone?
Answer: As shown in the output, the Juniper zone

has all services and protocols allowed in the
host-inbound-traffic.
Step 2.5
Review the lo0.0 interface zone assignment and allowed services and prot,ocol in
host-in bound-traffic.
lab@srxC-1> show interfaces loO.O I find Security
Security: Zone: Juniper-SV
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp
ospf pgm pim
rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http
https ike
netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh
telnet
traceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp
Protocol inet, MTU: Unlimited
Addresses, Flags: Is-Default Is-Primary
Local: 192.168.1.1
Question: Does the loO.O interface belong to the

correct zone?
Answer: Yes, as shown in the output, the loO.O

interface belongs to the Juniper-local zone.
Step 2.6
Return to the Telnet session established with the virtual router.
From your assigned virtual router, verify your changes. Test the reachability from the
affected virtual router to the SRX's loopback address using the ping command. Be
sure to source your ping from the correct virtual-router routing instance.
cl@vr-device> ping local-loopback routing-instance local-Juniper-VR count 3
PING 192.168.1.1 (192.168.1.1): 56 data bytes

--- 192.168.1.1 ping statistics ---

Answer: Yes, as shown in the output the pings are

successful.
Part 3: Troubleshooting Security Policies
In this lab part, you will troubleshoot problems related to security policies. You first
experience the problem then use CLI tools to find the problem cause and finally you
define the solution and resolve the problem.
Step 3.1
From Telnet session established with the virtual router, verify the reachability from
your Juniper virtual router to the Internet host using telnet.
Note
Note
If the session does not establish after
couple of seconds use Ctrl+C key
combination to break the attempt.
cl@vr-device> telnet 172.31.15.1 routing-instance local-Juniper-VR

Trying 172.31.15.1...
Ac
cl@vr-device>
Question: Is the telnet connection established?
Answer: As shown in the output, the telnet is not

successful.
www.juriiper.net Troubleshooting Security Zones and Policies • Lab 1-11

Step 3.2
From your assigned SRX device, test which security policy is used to handle the
telnet connection from your Juniper virtual router to the Internet host. Utilize the
show security match-policies command and use zones from the lab
diagram. Enter any arbitrary value for the source-port from the range <1024 -
65000>.
lab@srxC-1> show security match-policies protocol tcp destination-ip
172.31.15.1 source-ip local-Juniper-VR-address from-zone Juniper-loca.£
to-zone untrust source-port port destination-port 23
Policy: Default-Policy, action-type: deny-all, State: enabled, Index: 2
Sequence number: 2
Question: Which security policy is handling the

connection and how?
Answer: As shown in the output, the Default-Policy

is handling the connection and the action executed
is deny-all.
Question: What does this tell you?
Answer: The connection is denied by the default

policy and the default policy is enforced only if there
is no match in the regular security policies or the
global policy.This means there no regular policies
in the context from-zone Juniper-local to-zone
untrust exist that matches the telnet connection.
Step 3.3
View in detail the existing policies in the context from-zone Juniper-local
to-zone untrust.
lab@srxC-1> show security policies from-zone Juniper-local to-zone untrust
detail
Policy: internet-Juniper-SV, action-type: permit, State: enabled, Index: 15,
Scope Policy: O
Policy Type: Configured
Sequence number: 1
From zone: Juniper-SV, To zone: untrust
Source addresses:
vrl05: 172.20.105.0/24
Destination addresses:
internet-host: 172.31.16.1/32
Application: any
Lab 1-12 • Troubleshooting Security Zones and Policies www.juniiper.net

IP protocol: 0, ALG: 0, Inactivity timeout: O
Source port range: [0-0]
Destination port range: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No
Question: Does the security device have any

policies in the context from-zone Juniper-local
to-zone untrust context?
Answer: As shown in the output, the policy

internet-Juniper-local exists on the
device.
Question: If yes, why is the policy not used to handle

the telnet connection?
Answer: As shown in the output, the policy

destination-address is different than the IP address
of the Internet host.
Question: What would you perform for the policy to

handle all traffic to the Internet host?
Answer: Modification of the destination address

book entry is needed for the policy to match and
treat traffic to the Internet host.
Step 3.4
Modify the address entry in the address book of the untrust zone that it will
match only the Internet host. Commit the change and exit to the operational mode.
[edit]
lab@srxC-1# edit security zones security-zone untrust
[edit security zones security-zone untrust]

lab@srxC-1# show address-book
address internet-host 172.31.16.1/32;

lab@srxC-1# replace pattern 172.31.16.1 with 172.31.15.1


lab@srxC-1# show
address-book {
address internet-host 172.31.15.1/32;
}
system-services {
all;
protocols
all;
interfaces {
ge-0/0/3.0;

commit complete
lab@srxC-1>
Step 3.5
From your assigned virtual router, test the telnet from your Juniper virtual router to
the Internet host again.
Note
Note
The Internet host is another virtual router
instance on the same device as all the
other virtual routers. For telnet use same
credentials as you use for the virtual router.
cl@vr-device> telnet 172.31.15.1 routing-instance local-Juniper-VR

Trying 172.31.15.1...
Connected to 172.31.15.1.
Escape character is ' A l'.
vr-device (ttypl)

Advanced Ju nos EnterpriseSecurity Troubleshooting
login: username
Password:
cl@vr-device>
Question: Was the telnet connection successful?
Answer: As shown in the output, the telnet is

successful. If you experience different check your
configuration and notify your instructor.
Step 3.6
From your assigned SRX device, examine the session table for telnet sessions to the
Internet host.
lab@srxC-1> show security flow session destination-port 23 destination-prefix
172.31.15.1
Session ID: 44472, Policy name: internet-Juniper-SV/15, Timeout: 1780, Valid
In: 172.20.105.10/56728 --> 172.31.15.l/23;tcp, If: ge-0/0/4.105, Pkts: 9,
Bytes: 619
Out: 172.31.15.1/23 --> 172.20.105.10/56728;tcp, If: ge-0/0/3.0, Pkts: 8,
Bytes: 589
Total sessions: 1
lab@sr:x:C-1>
Question: Are there any sessions present?
Answer: As shown in the output, a session is

present for the telnet connection from your Juniper
virtual router to the Internet host handled by the
internet-Juniper-local security policy
Step 3.7
From your assigned virtual router, exit from the established telnet session to the
Internet host.
www.juniper.net Troubleshooting Security Zonesand Policies • Lab 1-15

cl@vr-device> exit
Connection closed by foreign host.
cl@vr-device>
Part 4: Troubleshooting Security Policies for Host Traffic
In this lab part, you will troubleshoot problems related to traffic destined for the SRX
device. You first experience the problem then use CU tools to find the problem
cause and finally you define the solution and resolve the problem.
Step 4.1
From Telnet session established with the virtual router try to open a telnet session
from the Juniper virtual router to the SRX interface in the ACME-local zo e.
Note
Note
cl@vr-device> telnet local-ACME-address routing-instance local-Juniper-VR

Trying 172.20.205.1 ...
Ac
cl@vr-device>
Question: Is the telnet connection established?
Answer: As shown in the output, the telnet is not

successful.
Step 4.2
From your assigned SRX device test which security policy is used to handle the telnet
connection from your Juniper virtual router to the SRX interface in the ACME-local
zone. Utilize the show security match-policies command and use zones from the lab
diagram and enter any arbitrary value for the source-port from the range< 1024 -
65000>.
Lab 1-16 • Troubleshooting Security Zones and Policies www.jurdper.net

lab@srxC-1> show security match-policies protocol tcp destination-ip

local-ACME-address source-ip local-Juniper-VR-address from-zone
Juniper-local to-zone ACME-local source-port port destination-port 23
Policy: juniper-to-acme, action-type: permit, State: enabled, Index: 4
0
Sequence number: 1
From zone: Juniper-SV, To zone: ACME-SV
Source addresses:
vrl05: 172.20.105.0/24
vr205: 172.20.205.0/24
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0

connection and how?
Answer: As shown in the output, the

juniper- to-acme security policy is handling the
connection and the action executed is permit.
Question: What does this tell you?
Answer: The telnet connection is permitted. But

because the telnet is destined to the SRX device
itself, the device takes further processing steps
before responding to it.
Step 4.3
Verify if telnet is allowed on the SRX interface in the ACME-local zone.
lab@sr:x:C-1> show interfaces ge-0/0/4.ACME-unit extensive I find Security
Security: Zone: ACME-SV
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp
ospf pgm pim
rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http
https ike
netconf ping reverse-telnet reverse-ssh rlogin rpm rsh snmp snmp-trap ssh
telnet
tra.ceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp
Flow Statistics :
Flow In.put statistics
Self packets 3519

ICMP packets : 6472
VPN packets : 0
Question: Is the telnet among allowed

host-inbound-traffic services?
Answer: As shown in the output, the telnet service is

allowed.
Step 4.4
Enter configuration mode and enable the traceoptions for the packet flow
processing. Define flow-log as the file name and specify packet filter that only
messages destined to the interface in the ACME-local zone. Commit your
configuration and exit to the operational mode when complete.
[edit]
lab@srxC-1# set security flow traceoptions file flow-log
[edit]
lab@srxC-1# set security flow traceoptions flag basic-datapath
[edit]
lab@srxC-1# set security flow traceoptions packet-filter Fl destination-prefix
local-ACME-address/32
[edit]
lab@srxC-1# show security flow
traceoptions {
file flow-log;
flag basic-datapath;
packet-filter Fl {
destination-prefix 172.20.205.1/32;
[edit]
lab@srxC-1# coIIIIllit and-quit
commit complete
lab@srxC-1>
Step 4.5
From your assigned virtual router, try the telnet connection from your Juniper virtual
router to the SRX interface in the ACME-local zone again.

Note
Note

Trying 172.20.205.1...
Ac
cl@vr-device>
Step4.6
From your assigned SRX device, examine the flow-log trace file.
Note
For the sake of clarity and time, the
interesting lines are balded in the output.
lab@srxC-1> show log flow-log

Apr l 08:04:40 08:04:40.487868:CID-O:RT:<172.20.105.10/57916->172.20.205.1/
23;6> matched filter Fl:
Apr 1 08:04:40 08:04:40.487868:CID-0:RT:packet [64] ipid = 24785, @422e6324
Apr 1 08:04:40 08:04:40.487868:CID-0:RT:---- flow_process_pkt: (thd 3):

flow_ctxt type 15, common flag OxO, mbuf Ox422e6100, rtbl_idx = O
Apr 1 08:04:40 08:04:40.487868:CID-O:RT: flow process pak fast ifl 71 in ifp

ge-0/0/4.105
Apr 1 08:04:40 08:04:40.487868:CID-O:RT: ge-0/0/4.105:172.20.105.10/

57916->172.20.205.1/23, tcp, flag 2 syn
Apr 1 08:04:40 08:04:40.487868:CID-0:RT: find flow: table Ox4fl60b38, hash

38882(0xffff), sa 172.20.105.10, da 172.20.205.1, sp 57916, dp 23, proto 6,
tok 11
Apr 1 08:04:40 08:04:40.487868:CID-0:RT: no session found, start first path.

in_tunnel - 0, from_cp_flag - 0
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: flow first create session

Apr 1 08:04:40 08:04:40.488063:CID-0:RT: flow_first_in_dst nat: in <ge-0/0/
4.105>, out <N/A> dst_adr 172.20.205.1, sp 57916, dp 23
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: chose interface ge-0/0/4.105 as

incoming nat if.
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:flow_first rule_dst_xlate: DST

no-xlate: 0.0.0.0(0) to 172.20.205.1(23)
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:flow_first routing: vr_id 0, call

flow_route_lookup(): src ip 172.20.105.10, x_dst_ip 172.20.205.1, in ifp
ge-0/0/4.105, out ifp N/A sp 57916, dp 23, ip_proto 6, tos 10
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:Doing DESTINATION addr route-lookup
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:Changing out-ifp from .local..0 to

ge-0/0/4.205 for dst: 172.20.205.1 in vr_id:O
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: routed (x_dst_ip 172.20.205.1) from

Juniper-SV (ge-0/0/4.105 in 0) to ge-0/0/4.205, Next-hop: 172.20.205.1
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:flow_first_policy_search: policy

search from zone Juniper-SV-> zone ACME-SV (Ox0,0xe23c0017,0x17)
Apr 1 08:04:40 08:04:40.488063:CID-O:RT: app 10, timeout 1800s, curr ageout

20s
Apr 1 08:04:40 08:04:40.488063:CID-O:RT: permitted by policy

juniper-to-acme(4)
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: packet passed, Permitted by policy.
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:flow_first src_xlate: nat src_xlated:

False, nat src_xlate_failed: False
Apr 1 08:04:40 08:04:40.488063:CID-O:RT:flow_first src xlate: src nat returns

status: 0, rule/pool id: 0/0, pst_nat: False.
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: dip id 0/0, 172.20.105.10/

57916->172.20.105.10/57916 protocol O
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: choose interface ge-0/0/4.20:, as

outgoing phy if
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:is_loop_pak: Found loop on ifp ge-0/0/

4.205, addr: 172.20.205.1, rtt_idx: 0 addr_type:Ox3.
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:flow_first_loopback_check: Setting

interface: ge-0/0/4.205 as loop ifp.
Apr 1 08:04:40 08:04:40.488063:CID-0:RT:-jsf Alloc sess plugin info for

session 4294997280
Apr 1 08:04:40 08:04:40.488063:CID-0:RT: [JSF]Normal interest check. re9d

plugins 18, enabled impl mask OxO

Apr 1 08:04:40 08:04:40.488063:CID-0:RT:-jsf int check: plugin id 2, svc_req

OxO, impl mask OxO. re 4
Apr 1 08:04:40 08:04:40.488456:CID-O:RT:-jsf int check: plugin id 3, svc req

Apr 1 08:04:40 08:04:40.488477:CID-0:RT:-jsf int check: plugin id 5, svc req





Apr 1 08:04:40 08:04:40.488538:CID-0:RT:+++++++++++jsf_test_plugin_data_evh: 3






Apr 1 08:04:40 08:04:40.488583:CID-0:RT: [JSF]Plugins(OxO, count 0) enabled for

session = 2887018762, impli mask(Oxl), post_nat cnt 29984 svc req(OxO)
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:-jsf : no plugin interested for session

4294997280, free sess plugin info
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: service lookup identified service 10.
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: flow_first_final_check: in <ge-0/0/

4.105>, out <ge-0/0/4.205>
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:flow_first_complete_session, pak_ptr:

Ox4ead0ba0, nsp: Ox52d12d60, in tunnel: OxO

Apr 1 08:04:40 08:04:40.488658:CID-O:RT:construct v4 vector for nsp2
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: existing vector list 2-49c757·10.
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: Session (id:29984) created for first

pak 2
Apr 1 08:04:40 08:04:40.488658:CID-O:RT: flow first install session======>

Ox52d12d60
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: nsp Ox52d12d60, nsp2 Ox52d12de0
Apr 1 08:04:40 08:04:40.488658:CID-O:RT:flow_xlate_pak
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: post addr xlation:

172.20.105.10->172.20.205.l.
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:check self-traffic on ge-0/0/4.205,

in tunnel OxO
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:retcode: Ox1304
Apr 1 08:04:40 08:04:40.488658:CID-O:RT:pak_for_self : proto 6, dst port 23,

action Ox4
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: flow first create session
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: flow_first_in dst nat: in <ge-0/0/

4.205>, out <N/A> dst_adr 172.20.205.1, sp 57916, dp 23
Apr 1 08:04:40 08:04:40.488658:CID-O:RT: chose interface ge-0/0/4.205 as

incoming nat if.
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:flow first rule dst xlate: DST

no-xlate: 0.0.0.0(0) to 172.20.205.1(23)
Apr 1 08:04:40 08:04:40.488658:CID-O:RT:flow first_routing: vr_id 0, call

flow route lookup(): src ip 172.20.105.10, x_dst_ip 172.20.205.1, in ifp
ge-0/0/4.205, out ifp N/A sp 57916, dp 23, ip_proto 6, tos 10
Apr 1 08:04:40 08:04:40.488658:CID-0:RT:Doing DESTINATION addr route-lcokup
Apr 1 08:04:40 08:04:40.488658:CID-0:RT: routed (x_dst_ip 172.20.205.1) from

ACME-SV (ge-0/0/4.205 in 0) to .local.. O, Next-hop: 172.20.205.1
Apr 1 08:04:40 08:04:40.488658:CID-O:RT:flow_first_policy_search: policy

search from zone ACME-SV-> zone junos-host (Ox0,0xe23c0017,0x17)
Apr 1 08:04:40 08:04:40.488658:CID-O:RT: policy has timeout 900
Apr 1 08:04:40 08:04:40.488658:CID-O:RT: app 10, timeout 1800s, curr ageout

20s

Apr 1 08:04:40 08:04:40.488658:CID-0:RT: packet dropped, denied by policy
Apr 1 08:04:40 08:04:40.489065:CID-0:RT: denied by policy drop-telnet(S),

dropping pkt
Apr 1 08:04:40 08:04:40.489065:CID-0:RT: packet dropped, policy deny.
Apr 1 08:04:40 08:04:40.489065:CID-0:RT: flow find session returns error.
Apr 1 08:04:40 08:04:40.489065:CID-0:RT: flow_process_pkt re Ox7 (fp re

-1)
Question: How is the telnet connection attempt

handled and why?
Answer: As shown in the output, the security policy

juniper-to-acme permits the packet. However
because the telnet is destined for the device itself
additionally another set of policies is examined in
the from-zone ACME-1 ocal to-zone j unos -host
context. And in this context the security policy
drop-telnet denies the connection.
Step4.7
View in detail the security policies in the from-zone ACME-local to-zone
junos-host context.
lab@sr:x:C-1> show security policies from-zone ACME-local to-zone junos-host
detail
Policy: drop-telnet, action-type: deny, State: enabled, Index: 5, Scope Policy:
0
Sequence number: 1
From zone: ACME-SV, To zone: junos-host
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
any-ipv4(global): 0.0.0.0/0
any-ipv6(global): ::/0
Application: junos-telnet
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Destination port range: (23-23]

Question: What is policy doing?

is denying the telnet connections.
Question: What can be done to allow the telnet

connections?
Answer: The solution is either to change the action

to permit or to delete the security policy because
the default action for connections to the
junos-host is permit.
Step4.8
Enter configuration mode and delete the security policy in the from-zone
ACME-local to-zone junos-host context. Commit the configuration and exit to
operational mode when complete.
[edit]
lab@srxC-1# edit security policies
[edit security policies]

lab@srxC-1# edit from-zone ACME-local to-zone junos-host
[edit security policies from-zone ACME-SV to-zone junos-host]

lab@srxC-1# show
policy drop-telnet {
match {
source-address any;
destination-address any;
application junos-telnet;
}
then {
deny;

lab@srxC-1# delete policy drop-telnet

lab@srxC-1# show
## Warning: missing mandatory statement(s): 'policy'

commit complete
lab@srxC-1>
Step4.9
From your assigned virtual router, try the telnet connection from your Juniper virtual
router to the SRX interface in the ACME-1 ocal zone again.
Note
Note
Note
Use credentials for accessing your SRX
device.

Trying 1 72.20. 205 .1...
Connect,c=d to 172.20.205 .1.
A
Escape character is ' l•
srxC-1 (ttypO)
login: lab
Password:
--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC

lab@srxC-1>
Question: Is the telnet connection successful?
Answer: As shown in the output, the telnet

connection is successful. If not double-check your
configuration and notify your instructor.

Step 4.10
Use the exit command to disconnect from the established telnet session.
lab@srxC-1> exit
Connection closed by foreign host.
cl@vr-device>
Step 4.11
From your assigned SRX device, log out using the exit command.
lab@srxC-1> exit
srxC-1 (ttyuO)
login:
Tell your instructor that you have completed this lab.
Management Network Diagram

ge-0/0/0 (on all student devices)
/
m::mlJ Workstations
Management Addressing
SIXA-1 srxD-1
SIXA-2 srxD-2
Sll<B-1 vr-device
Sll<B-2 Server
srx!r1 Gateway
srx!r2 Term Server _ _ _
_
ate: Your instructor will provide address and access information.

Pod A Network Diagram: Troubleshooting

Security Zones and Policies Lab
--[fl
Host 1.72.31.15.1
V0/4.201 -- -- ge-0/0/4.102
Tagged Interface
172.20.201.0/24 (see VlAN Assignments table) 172.20.102.0/24 172.20.202.0/24
(.10)
Pod B Network Diagram: Troubleshooting

Host name VLAN-ID

srxB-1 103, 203
srxB-2 104, 204
Host 172.31.15.1
V0/4.203 -- -- ge-0/0/4.104 V0/4.204

Tagged Interface
172.20.103.0/24 172.20.203.0/24 (see VLAN Assignments table) 172.20.104.0/24 172.20.204.0/24
(.10) (10j
I I
)
,/(10
0
vr1 3
Juniper-SV Juniper-WF ACME-WF

Pod C Network Diagram: Troubleshooting

Hostname
srxC-1
srxC-2
VLAN-ID
105, 205
106, 206
--El
Host 172.31.15.1
V0/4.205 -- ge-0/0/4.106 V0/4.206

--
Tagged Interface
172.20.105.0/24 172.20.205.0/24 (see VIAN Assignments table) 172.20 106.Q/24
(. 10)
Juniper-SV
Pod D Network Diagram: Troubleshooting

A�-a Host 172.31.15.1
V0/4.207
-- --ge-0/0/4.108 (.1) V0/4.208
Tagged Interface
172.20.107.0/24 172.20.207.0/24 (see VIJ\N Assignments table} 172.20.108.0/24 172.20.208.0/24

Lab
Troubleshooting IPsec
Overview
In this lab, you will troubleshoot IPsec. You will use Junos OS CLI commands and analyze
trace log files to find out the causes for the detected problems. Next you define the
solution for the issues and perform it.
By completing this lab you will perform the following tasks:
Troubleshoot IKE phase 1.
Troubleshoot IKE phase 2.
Troubleshoot route-based IPsec VPNs.
www.juniper.net Troubleshooting IPsec • Lab 2-1

equipment. Once you are familiar with the access details, you will use the CU to log
in to your designated station. Next, you will load the starting configuration for the
lab.
Note

assigned device.
Step 1.1
Ensure you know what device you are assigned. Check with your instructor if


Step 1.2
Access the command-line interface (CU) at your station using either the console,
Lab 2-2 • Troubleshooting IPsec www.juniper.net

�-
(1.lltc��Jfi4W1,}¢;%.ti?hk'�= "'�h' �� 't""· "'>" ..,. •� ' ""•,,.y�
Protocol:
Hostname:
Port:
D Show quick connect on startup 0 Save session

0 Open in a tab
11 Co�nect .• I Cancel I
Step 1.3
the lab2-start. configfrom the /var/home/lab/ajestj directory. Commit the
srxC-1 (ttypO)
login: lab
Password:

lab@sr:x:C-1> configure
[edit]
lab@sr:x:C-1# load override ajest/lab2-start.config
load complete
lab@sr:x:C-1# commit and-quit

commit complete
Exitin9· configuration mode
lab@sr:x:C-1>
Step 1.4
From the operational mode check the status of your configured Gigabit Ethernet,
loopback interfaces and tunnel interfaces using the show interfaces terse
I match "ge I lo I stO" command.
lab@sr:x:C-1> show interfaces terse I match "gelstOlloO"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.14.135/27
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.105 up up inet 172.20.105.1/24
ge-0/0/4.205 up up inet 172.20.205.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up up
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up down
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
ge-0/0/15 up up
loo up up
loo.a up up inet 192.168.30.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
lo0.32768 up up
stO up up
stO.O up up inet 10.10.30.1/24


Part 2: Examining the IPsec Configuration and Troubleshooting IPsec VPNs
In this lab part, you will examine the existing IPsec configuration on your SFIX device
and troubleshoot problems related to IPsec VPNs. You first experience the problem
then use CLI tools to find the problem cause and finally you define the solution and
resolve the problem.
Step 2.1
Examine the existing IPsec • IKE phase 1 configuration on your SRX.
lab@srxC-1> show configuration security ike
policy policy-1 {
mode main;
proposal-set basic;
pre-shared-key ascii-text "$9$0VD91EyM87s2alK2aZU.m01R"; ## SECRET-DATA
}
policy policy-2 {
mode main;
proposal-set standard;
Lab 2-4 • Troubleshooting IPsec www.ju iper.net

gateway spoke-1 {
ike-policy policy-1;
address 192.168.30.3;
external-interface loO.O;
}
gateway spoke-2 {
address 192.168.30.4;
Question: How many IKE phase 1 configurations are

present?
Answer: As indicated by the output, there are 2 IKE

phase 1 policies and 2 IKE phase 1 gateways
configurations present. If the configuration is
missing try to load the start configuration once
more. If the configuration does still not appear
Step 2.2
Examine the existing IPsec - IKE phase 2 configuration on your SRX.
lab@srxC-1> show configuration security ipsec
policy policy-sec {
vpn srxC-1-to-spoke-l {
bind-interface stO.O;
ike {
gateway spoke-1;
ipsec-policy policy-sec;
establish-tunnels immediately;
vpn srxC-1-to-spoke-2
bind-interface stO.O;
ike {
gateway spoke-2;
ipsec-policy policy-sec;
establish-tunnels immediately;

Question: How many IKE phase 2 configurations are

listed?
Answer: As indicated by the output, there is one IKE

phase 2 policy and two IKE phase 2 VPN
configurations shown. If the configuration is
missing, try to load the start configuration once
more. If the configuration does still not appear,
Step 2.3
Restart the IPsec key management daemon. (Note: You would not typically need to
do this but we need to restart this process because of the way this troubleshooting
lab is built.)
lab@srxC-1> restart ipsec-key-management
IPSec Key Management daemon started, pid 3285
lab@srxC-1>
Step 2.4
Check if any IKE phase 1 and IKE phase 2 SAs are present on the device.
lab@srxC-1> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
243597 UP 308f83af84cll27d a774dl633604c29e Main 192.168.30.4
lab@srxC-1> show security ipsec security-associations

Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131074 ESP:3des/shal al4a385d 3551/ unlim root 500 192.168.30.4
>131074 ESP:3des/shal 2af8d64b 3551/ unlim root 500 192.168.30.4
Question: How many IKE phase 1 SAs are shown

and what is their status?
Answer: As indicated by the output, there is one IKE

phase 1 SA with UP status. If no SA is displayed,
notify your instructor. Note: you might also see the
down session to the other spoke.

Question: How many IKE phase 2 SAs are shown?
Answer: As indicated by the output, there are two

active IKE phase 2. If no SAs are displayed, notify
your instructor.
Question: How many IKE phase 1 and phase 2 SAs

would you expect considering the configuration
from previous steps?
Answer: Based on the configuration, there should

be two IKE phase 1 SAs (one to each spoke) and
four IKE phase 2 SAs (two to each spoke).
Question: Which step would you take next to find

the cause of the problem?
Answer: Logical next step would be to verify the

reachability between spokes and your SRX
loopback addresses.
Step 2.5
Verify the routing information to reach both spokes loopback addresses is correct on
your SRX. For topology refer to the lab diagram.
lab@sr:x:C-1> show route spoke-1-loO-address
inet.O: 12 destinations, 12 routes (12 active, 0 holddown, O hidden)

0.0.0.C/O *[Static/SJ 2d 04:06:41

> to 172.18.1.1 via ge-0/0/3.0
lab@sr:x:C-1> show route spoke-2-loO-address
inet.O: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/SJ 2d 04:07:15

> to 172.18.1.1 via ge-0/0/3.0

Question: Which interface and next-hop are used to
reach the loopback addresses of both spokes?
Answer: The answer varies. As indicated by the

output from srxC-1 in both cases the outgoing
interface is ge-0/0/3.0 and the next-hop is
172.18.1.1.
Step 2.6
Verify the reachability to both spokes loopback addresses using the ping utility.
Define the IP address of "external-interface" from the IKE phase 1 configuration as
the source address for the ping.
lab@srxC-1> ping spoke-1-loO-address source local-lo0.0-address count 3
PING 192.168.30.3 (192.168.30.3): 56 data bytes
64 bytes from 192.168.30.3: icmp_seq=O ttl=63 time=2.250 ms
64 bytes from 192.168.30.3: icmp_seq=l ttl=63 time=l.816 ms
64 bytes from 192.168.30.3: icmp_seq=2 ttl=63 time=l.900 ms
--- 192.168.30.3 ping statistics ---

round-trip min/avg/max/stddev = l.816/l.989/2.250/0.188 ms
lab@srxC-1> ping spoke-2-loO-address source local-lo0.0-address count 3

PING 192.168.30.4 (192.168.30.4): 56 data bytes
--- 192.168.30.4 ping statistics ---

round-trip min/avg/max/stddev = l.849/2.103/2.385/0.220 ms
Question: Were the pings successful?
Answer: Yes, as indicated by the output, both pings

were successful. If the pings are not successful

Question: What does this mean?
Answer: The pings confirm the device can reach

each other and the IKE messages can be
exchanged. The next step would be examining the
IKE phase 1 and phase 2 for negotiation details
using the traceoptions.
Step 2.7
Enter configuration mode and enable traceoptions for IKE phase 1 and IKE phase 2.
For the traceoptions configuration define flag all and use the default trace file
/var /log/kmd. Before committing the configuration clear the /var /log/kmd
file for easier examination. Commit the configuration changes and exit to
operational mode when complete.
[edit]
lab@sr:x:C-1# edit security
[edit s:ecurity]
lab@srxC-1# set ike traceoptions flag all
[edit security]
lab@srxC-1# show ike traceoptions
flag all;
[edit E:ecurity]
lab@srxC-1# set ipsec traceoptions flag all
[edit security]
lab@srxC-1# show ipsec traceoptions
flag all;
[edit security]
lab@srxC-1# run clear log kmd
[edit security]
commit complete
lab@srxC-1>

Step 2.8
Review the /var/log/kmd file.
Note
For the sake of clarity and time, the
n
i teresting lines are balded in the output.
lab@srxC-1> show log kmd

Apr 3 05:39:36 srxC-1 clear-log[l9611]: logfile cleared
Apr 3 05:39:48 IKEvl Error : No proposal chosen
Apr 3 05:39:52 Deleting existing ipsec trace cfg with key: 1
Apr 3 05:39:52 iked_ipsec_trace_flag_update: Successfully added ipsec trace

config with key
Apr 3 05:39:52 kmd_sa_cfg_free: Tunnel node for tunnel 131073 (SA:

srxC-1-to-spoke-l) not found
Apr 3 05:39:52 kmd_sa_cfg_free: Tunnel node for tunnel 131074 (SA:
srxC-l-to-spoke-2) not found
Apr 3 05:39:52 kmd_update_dependent_config: No change, returning.
Apr 3 05:39:52 kmd_diff_config_now, configuration diff complete
Apr 3 05:39:52 iked_pm_ike_spd_notify_request: Sending Initial contact
Apr 3 05:39:52 ssh_ike_connect: Start, remote_name = 192.168.30.3:500, xchg
2, flags = 00090000
Apr 3 05:39:52 ike sa allocate: Start, SA = { bd59f524 50519ce6 - 00000000
00000000 }
Apr 3 05:39:52 ike_init_isakmp_sa: Start, remote = 192.168.30.3:500, initiator
= 1
Apr 3 05:39:52 192.168.30.1:500 (Initiator) <-> 192.168.30.3:500 { bd59f524
50519ce6 - 00000000 00000000 (-1] / OxOOOOOOOO } IP; Warning: Number of
proposals != 1 in ISAKMP SA, this is against draft!
Apr 3 05:39:52 ssh ike connect: SA = { bd59f524 50519ce6 - 00000000 00000000},
nego = -1
Apr 3 05:39:52 ike_st_o_sa_proposal: Start
Apr 3 05:39:52 ike_policy_reply_isakmp_vendor_ids: Start
Apr 3 05:39:52 ike_st_o_private: Start
Apr 3 05:39:52 ike_policy_reply_private_payload_out: Start
Apr 3 05:39:52 ike_encode_packet: Start, SA = { Oxbd59f524 50519ce6 - 00000000
00000000 } I 00000000, nego = -1
Apr 3 05:39:52 ike_send_packet: Start, send SA = { bd59f524 50519ce6 - 00000000
00000000}, nego = -1, dst = 192.168.30.3:500, routing table id = O
Apr 3 05:39:52 ikev2_packet_allocate: Allocated packet a2e400 from freelist
Apr 3 05:39:52 ike sa find: Not found SA = { bd59f524 50519ce6 - c9ea459c
dc26cd65 }
Apr 3 05:39:52 ikev2_packet_st_input_vl_get_sa: Checking if unauthenticated
IKEvl notify is for an IKEv2 SA
Apr 3 05:39:52 ikev2_packet_vl_start: Passing IKE vl.O packet to IKEvl library
Apr 3 05:39:52 ike_get_sa: Start, SA = { bd59f524 50519ce6 - c9ea459c dc26cd65
} I 44b3e47a, remote = 192.168.30.3:500
Apr 3 05:39:52 ike sa find: Not found SA = { bd59f524 50519ce6 - c9ea459c
dc26cd65 }
Apr 3 05:39:52 ike sa find half: Found half SA = { bd59f524 50519ce6 - 00000000
00000000 }

Advanced Ju nos Enterprise Security Troubleshooti ng
Apr 3 05:39:52 ike_sa_upgrade: Start, SA= { bd59f524 50519ce6 - 00000000
00000000 } -> { ... - c9ea459c dc26cd65 }
Apr 3 05:39:52 ike alloc-negotiation: Start, SA= { bd59f524 50519ce6 -
c9ea459c dc26cd65}
Apr 3 05:39:52 ike_decode_packet: Start
Apr 3 05:39:52 ike_decode_packet: Start, SA= { bd59f524 50519ce6 - c9ea459c
dc26cd65} I 44b3e47a, nego= O
Apr 3 05:39:52 ike_st_i_n: Start, doi= l, protocol= l, code= No proposal
chosen (14), spi[O..16J = bdi9f524 50519ce6 ..., data[O..46J = 800c0001
00060022 ...
Apr 3 05:39:52 <none>:500 (Responder) <-> 192.168.30.3:500 { bd59f524 50519ce6
- c9,:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Notification data has attribute
list
- c9,:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Notify message version= 1
- c9,:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Error text = Could not find
acceptable proposal
- c9ea459c dc26cd65 [OJ I Ox44b3e47a } Info; Offending message id=
OxOOOOOOOO
- c9·:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Received notify err = No
proposal chosen (14) to isakmp sa, delete it
Apr 3 05:39:52 ike_st_i_private: Start
Apr 3 05:39:52 ike_send_notify: Connected, SA bd59f524 50519ce6 - c9ea459c
dc26cd65}, nego= O
Apr 3 05:39:52 ike delete negotiation: Start, SA= { bd59f524 50519ce6 -
c9ea459c dc26cd65}, neg;= 0
Apr 3 05:39:52 ike free_negotiation_info: Start, nego= O
Apr 3 05:39:52 ike free negotiation: Start, nego= 0
Apr 3 05:39:52 ike=remo;e_callback: Start, delete SA= { bd59f524 50519ce6 -
c9ea459c dc26cd65}, nego= -1
Apr 3 05:39:52 192.168.30.1:500 (Initiator) <-> 192.168.30.3:500 { bd59f524
50519ce6 - c9ea459c dc26cd65 [-lJ I OxOOOOOOOO } IP; Connection got error
14, calling callback
Apr 3 05:39:52 ikev2 fb_vl_encr_id_to_v2 id: Unknown IKE encryption identifier
-1
Apr 3 05:39:52 ikev2_fb_vl_hash_id_to_v2_prf_id: Unknown IKE hash alg
identifier -1
Apr 3 05:39:52 ikev2 fb_vl_hash_id_to_v2 integ_id: Unknown IKE hash alg
identifier -1
Apr 3 05:39:52 IKE negotiation fail for local:192.168.30.1, remote:192.168.30.3
IKEvl with status: No proposal chosen
Apr 3 05:39:52 IKEvl Error : No proposal chosen
Apr 3 05:39:52 IPSec Rekey for SPI OxO failed
Apr 3 05:39:52 IPSec SA done callback called for sa-cfg srxC-1-to-spoke-l
local:192.168.30.1, remote:192.168.30.3 IKEvl with status No proposal chosen
Apr 3 05:39:52 ike delete negotiation: Start, SA= { bd59f524 50519ce6 -
c9ea459c dc26cd65}, neg;= -1
Apr 3 05:39:52 ssh_ike_tunnel_table_entry_delete: Deleting tunnel_id: 0 from
IKE tunnel table
Apr 3 05:39:52 ssh ike tunnel table entry delete: The tunnel id: O doesn't
exist in IKE tunnel table
www.ju niper.net Troubleshooti ng IPsec • Lab 2-11

Apr 3 05:39:52 ike_sa_delete: Start, SA = { bd59f524 50519ce6 - c9ea459c

dc26cd65 }
Apr 3 05:39:52 ike_free_negotiation_isakmp: Start, nego = -1
Apr 3 05:39:52 ike_free_negotiation: Start, nego = -1
Apr 3 05:39:52 IKE SA delete called for pl sa 243603 (ref cnt 1)
local:192.168.30.1, remote:192.168.30.3, IKEvl
Apr 3 05:39:52 iked_pm_pl_sa_destroy: pl sa 243603 (ref cnt 0),
waiting_for_del OxO
Apr 3 05:39:52 ike_free_id_payload: Start, id type = 1
Apr 3 05:39:52 ike free_sa: Start
Apr 3 05:39:52 iked deferred free inactive_peer_entry: Free 1 peer_entry(s)
Question: Do the log messages indicate the

problem for the IKE negotiations?
Answer: As shown in the output, the IKE phase 1

fails with spoke-1 because of no matching
proposals.
Question: How would you fix the situation?
Answer: For the IKE phase 1 to successfully

complete both peers need to agree at least on 1
proposal, e.g. encryption algorithm, hash algorithm
and authentication method. The IKE phase 1
proposal configuration needs to be adjusted to
resolve the problem. You will adjust the
configuration non your SRX device because you
have neither the access details nor the privileges to
do it on the spoke-1 device.
Step 2.9
Enter configuration mode and change the proposal-set for the spoke-l's IKE phase 1
to standard. Commit the configuration changes and exit to operational mode when
complete.
[edit]
lab@srxC-1# edit security ike
[edit security ike]

lab@srxC-1# show
traceoptions {
flag all;

Advanced Junos Ent erpriseSecurityTr oubleshooting
policy policy-1 {
mode main;
proposal-set basic;
}
policy policy-2 {
mode main;
}
gateway spoke-1 {
address 192.168.30.3;
}
gateway spoke-2 {
address 192.168.30.4;
[edit security ike]

lab@srxC-1# set policy policy-I proposal-set standard
[edit security ike]

lab@srxC-1# show policy policy-I
mode main;
[edit security ike]

commit complete
lab@srxC-1>
Step 2.10
Verify the status of IKE phase 1 and IKE phase 2 SAs on your SRX.
lab@srxC-1> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
243606 UP 76fc7377169db6a4 57fa23262fdb5db5 Main 192.168.30.3
243597 UP 308f83af84c1127d a774d1633604c29e Main 192.168.30.4
lab@srxC-1> show security ipsec security-associations

Total active tunnels: 2
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/shal d7b87066 3565/ unlim root 500 192.168.30.3
>131073 ESP:3des/shal cd338cfd 3565/ unlim root 500 192.168.30.3
<131074 ESP:3des/shal al4a385d 3114/ unlim root 500 192.168.30.4
>131074 ESP:3des/shal 2af8d64b 3114/ unlim root 500 192.168.30.4
www.jurniper.net Troubleshooting IPsec • Lab 2-13

Question: How many IKE phase 1 SAs are shown
and what is their status?
Answer: As indicated by the output, there are two

IKE phase 1 SAs with UP status. If you experience
different output, double-check your configuration
and notify your instructor.
Question: How many IKE phase 2 SAs are shown?
Answer: As indicated by the output, there are four

active IKE phase 2 SAs. If you experience different
output, double-check your configuration and notify
your instructor.
Part 3: Troubleshooting Connectivity in IPsec VPNs
In this lab part, you will troubleshoot connectivity problems through IPsec VPNs. You
first experience the problem then use CLI tools to find the problem cause and finally
you define the solution and resolve the problem.
Step 3.1
Verify the reachability to the spoke-1 and spoke-2 host IP addresses. For the spokes'
host IP addressing details, consult the lab diagrams.
lab@srxC-1> ping spoke-I-address count 3
PING 192.171.30.3 (192.171.30.3): 56 data bytes

lab@srxC-1> ping spoke-2-address count 3

PING 192.171.30.4 (192.171.30.4): 56 data bytes

Answer: As shown in the output, the ping to the

spoke-1 address fails and the ping to spoke-2
address is successful. If you experience different
Step 3.2
Test the forwarding decision on your SRX for the spoke-1 and spoke-2 IP addresses.
lab@srxC-1> show route spoke-1-address
inet.O: 13 destinations, 13 routes (13 active, O holddown, O hidden)

192.171.30.3/32 *[Static/SJ 00:05:40

> to 10.10.30.3 via stO.O
inet.O: 13 destinations, 13 routes (13 active, O holddown, O hidden)

0.0.0.0/0 *[Static/SJ 2d 04:21:37

> to 172.18.1.1 via ge-0/0/3.0
Question: Which interfaces and next-hop IP

addresses are shown as the forwarding result?
Answer: The answer varies. As shown in the output

taken from srxC-1, traffic to spoke-1 IP address is
routed through the tunnel interface stO.O and traffic
to spoke-2 is routed through the uplink ge-0/0/3.0
interface with the next-hop 172.18.1.1.
Question: Is the forwarding correct considering the

traffic from and to both spokes must be secured?
Answer: No. Traffic to spoke-2 is not going into the

tunnel interface stO.O.

Step 3.3
Create a static route for spoke-2 traffic to use the IPsec VPN tunnel. Use the spoke-2
stO.O interface as next-hop. Commit the change and exit to the operational mode
when complete.
[edit]
lab@srxC-1# edit routing-options static
[edit routing-options static]

lab@srxC-1# set route spoke-2-address next-hop spoke-2-stO.O-address

lab@srxC-1# show
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.171.30.3/32 next-hop 10.10.30.3;
route 192.171.30.4/32 next-hop 10.10.30.4;

commit complete
lab@srxC-1>
Step 3.4
Test the forwarding to spoke-2 after the change.
inet.0: 14 destinations, 14 routes (14 active, O holddown, O hidden)

192.171.30.4/32 * [Static/SJ 00:00:41

> to 10.10.30.4 via stO.O
Question: Is the forwarding correct?
Answer: As shown by the output, the traffic to

spoke-2 is now forwarded into stO.O interface.
Step 3.5
Check the connectivity to spoke-2
PING 192.171.30.4 (192.171.30.4): 56 data bytes


3 packets transmitted, O packets received, 100% packet loss
Question: Are you able to reach spoke-2?
Answer: No, as shown in the output, you are not

able to reach spoke2.
Step 3.6
View the next-hop tunnel binding table.
lab@sr:x:C-1> show security ipsec next-hop-tunnels
Next-hop gateway interface IPSec VPN name Flag
10.10.30.3 stO.O srxC-1-to-spoke-l Auto
10.10.30.4 sto.o srxC-1-to-spoke-2 Auto
Question: Is the next-hop tunnel binding table

populated with correct entries?
Answer: Yes, as shown in the output, the next-hop

tunnel binging table is correctly populated. The flag
Auto means the entry has been placed into the
table automatically with the details exchanged
between peers during the IKE negotiations using
the NOTIFY_NS_NHTB_INFORM messages. In
addition it means the spoke device is also a Juniper
device (Junos security device or ScreenOS device)
because only Juniper devices exchange this
message. For other devices manual NHTB entry
must be created.
Step 3.7
Examine the tunnel interface stO.O statistics to see if any traffic is going into the
tunnel.
lab@srxC-1> show interfaces stO.O statistics
Logical interface stO.O (Index 70) (SNMP if Index 596)
Fla,gs: No-Multicast SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : O
Out.put packets: 9
Security: Zone: Null
Protocol inet, MTU: 9192
Flags: Send.beast-pkt-to-re
1',ddresses, Flags: Is-Preferred Is-Primary
Destination: 10.10.30/24, Local: 10.10.30.1

Question: What does the command output tell you
about the stO.O interface?
Answer: As shown in the output, only the output

statistics are increased. The input counter is 0.
Closer look at the output reveals the tunnel
interface stO.O is assigned to the null zone which
causes all packets to be dropped.
Step 3.8
Enter the configuration mode and assign the stO.O interface to the vpn zone.
Commit the change and exit to the operational mode when complete.
[edit]
lab@srxC-1# edit security zones
[edit security zones]

lab@srxC-1# set security-zone vpn interfaces stO.O
[edit security zones]

lab@srxC-1# show
functional-zone management
interfaces {
ge-0/0/0.0;
system-services {
all;
protocols
all;
security-zone Juniper-SV {
system-services {
all;
protocols
all;
interfaces {
ge-0/0/4.105;
security-zone ACME-SV {

system-services {
all;
protocols
all;
interfaces {
ge-0/0/4.205;
security-zone untrust {
system-services {
all;
protocols
all;
interfaces
ge-0/0/3.0;
loO.O;
security-zone vpn
interfaces {
stO.O;
[edit s:ecurity zones]

commit complete
lab@srxC-1>
Step3.9
Verify the tunnel interface stO.O is assigned to the correct zone.
Logical interface stO.O (Index 70) (SNMP if Index 596)
Flags: No-Multicast SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : O
Out.put packets: 9
Security: Zone: vpn
.ll.,ddresses, Flags: Is-Preferred Is-Primary

Question: Does the stO.O interface belong to vpn
zone?
Answer: As shown in the output, yes the stO.O

interface does belong to the vpn zone. If the
interface does not belong to the vpn zone double
check your configuration.
Step3.10
Test the reachability to spoke-1 and spoke-2 IP addresses again.
PING 192.171.30.3 (192.171.30.3): 56 data bytes
64 bytes from 192.171.30.3: icmp seq=2 ttl=64 time=2.611 ms
--- 192.171.30.3 ping statistics ---


PING 192.171.30.4 (192.171.30.4): 56 data bytes
--- 192.171.30.4 ping statistics ---

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

both ping are now successful. If you experience
different behavior notify your instructor.
Step3.11
Examine the tunnel interface stO.O.
Logical interface stO.0 (Index 70) (SNMP ifIndex 596)
Flags: No-Multicast SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 6
Output packets: 15
Security: Zone: vpn

Addresses, Flags: Is-Preferred Is-Primary
Question: Do the stO.O statistics increase?
Answer: As shown in the output taken from srxC-1,

both input and output statistics for the stO.O
interface increase.
Step3.12
Log out using the exit command.
lab@srxC-1> exit
srxC-1 (ttyuO)
login:

Ea' A? Workstations
I srxA-1 srx0-1
I:
srx0-2
2
srxA-
srx.lH
1:::
I
Server
Gateway
SO<C- Term Server ___ _
_
2
Server Note: Your instructor will provide address and access information.
Pod A Network Diagram:

Spoke 1 A-1 Spoke 1A-2

stO: 10.10.10.3/24 stO: 10.10.10.6/24
loO: 192.168.10.3 loO: 192.168.10.6
Spoke2A-2
stO: 10.1010.7/24
loO: 192.168.10. 7
srxA-1 srxA-2
stO: 10.10.10.1/24 stO: 10.10.10.2/24
loO: 192.168.10.1 loO: 192.168.10.2
Unlpe Woddwld&""1:,t",;;;ij�� Services

"'k,� �--
www,um""'

Pod B Network Diagram:

Spoke 1 B-1 Spoke 1 B-2

stO: 10.10.20.3/24 O: 10.10.20.6/24
loO: 192.168.20.3 O: 192.168.20.6
Pod C Network Diagram:

srxC-1
stO: 10.10.30.1/24
loO: 192.168.30.1

Pod D Network Diagram:

Spoke 1 D-1 Spoke 1 D-2

stO: 10.10.40.3/24 stO 10.10 .40.6/24
loO: 192.168.40.3 loO: 192.168.40.6
Spoke2 D-1
stO: 10.10.40.4/24
loO: 192.168.40.4
.Z;,<
e,,·.ze.<o
-o_,,o_,,.(.Jo
srxD-1 r.,,;�---s-rx_ _2__... ,
D-
stO: 10.10.40.1/24 stO: 10.10.402/24
loO: 192.168.40.1 loO: 192.168.40.2

Lab
Troubleshooting Security Features
Overview
In this lab, you will troubleshoot security features - AppSecure and UTM. You will use
Junos OS CLI commands and analyze log file to determine the reason for experienced
behavior.
Troubleshoot UTM.
Troubleshoot AppSecure features.
www.juniper.net Troubleshooting Security Features • Lab 3-1

in to your designated station. Next, you will load the starting configuration for Lab 5.
Then, you will verify the connectivity between your assigned virtual routers and your
device.
Note
assigned device.
Step 1.1
Ensure that you know to which device you are assigned. Check with your instructor if


Step 1.2
Access the command-line interface (CU) at your station using either the console,
Lab 3-2 • Troubleshooting Security Features www.juniper.net

D S ho1N quick connect on startup B Save session

0 Open in a tab
Connect Cancel
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
the lab3-start. configfrom the /var/home/lab/ajestj directory. Commit the
srxC-1 (ttypO)
login: lab
Password:
--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

[edit]
lab@sr:x:C-1# load override ajest/lab3-start.config
load complete
lab@sr:x:C-1# commit and-quit

commit complete
lab@sr:x:C-1>
Step 1.4
From the operational mode check the status of your configured Gigabit Ethernet and
loopback interfaces using the show interfaces terse I match "ge I lo"
command.
lab@sr:x:C-1> show interfaces terse I match "gelloO"
ge-0/0/0 up up
ge-0/0/0.0 up up inet 10.210.14.135/27
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.105 up up inet 172.20.105.1/24
ge-0/0/4.205 up up inet 172.20.205.1/24
ge-0/0/4.32767 up up
ge-0/0/5 up up
ge-0/0/6 up up
ge-0/0/7 up up
ge-0/0/8 up up
ge-0/0/9 up down
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
ge-0/0/15 up up
loo up up
loo.a 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
lo0.32768 up 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 1.5
Open a separate Telnet session to the virtual router attached to your team device.

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 Diagram for the IP address of the
vr-device.
D Show quick connect on startup [2] Save session

0 Open in a lab
l Connect. • I
•
Cancel J
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 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23

Adva nced Ju nos Enterprise Security Troubleshooting
vr-device (ttypO)
login: username
Password:
cl@vr-device>
Step 1.6
From the Telnet session established with the virtual router, verify reachability from
virtual routers assigned to you to their respective interface on your device using the
ping command. Be sure to source your ping from the correct virtual-router routing
instance.
Note
cl@vr-device> ping local-Juniper-address routing-instance local-Juniper-·VR

count 3
PING 172.20.105.1 (172.20.105.1): 56 data bytes
--- 172.20.105.1 ping statistics ---

round-trip min/avg/max/stddev = 3.343/ll.415/26.430/10.627 ms
cl@vr-device> ping local-ACME-address routing-instance local-ACME-VR count 3

PING 172.20.205.1 (172.20.205.1): 56 data bytes
--- 172.20.205.1 ping statistics ---

Lab 3-6 • Troubleshooti ng Security Features www.juniper.net

Advanced JunosEnterpriseSecuritTroub
y leshooting
Question: Were the pings successful?
Answer: As indicated by the output, both pings

should be successful. If you experience different
Part 2: Examining and Troubleshooting UTM
In this lab part, you will examine and troubleshoot UTM to determine the reason of
experienced traffic processing.
Step 2.1
Establish an ftp connection from your Juniper virtual router to your SRX's interface in
the ACME zone. Use the same credentials as for logging in to your SRX device.
Note
cl@vr-device> ftp local-ACME-address routing-instance local-Juniper-VR

Connected to 172.20.205.l.
220 srxC-1 FTP server (Version 6.00LS) ready.
Name (172.20.205.1:cl): lab
331 Password required for lab.
Password:
230 User lab logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Step 2.2
Try to download the labl-start. configfile from the ajest folder.
ftp> ge,t ajest\labl-start.config
local: ajestlabl-start.config remote: ajestlabl-start.config
200 PORT command successful.
550 172.20.205.1:21->172.20.105.10:56091 Requested action not taken and the
request is dropped for Content Filtering file extension block list.
ftp>
Question: Were you able to download the file?
Answer: No, the download was not successful.
www.juniper.net Troubleshooting Security Features • Lab 3- 7

Question: Did the message you received describe
the reason for not allowing the file download?
Answer: As indicated by the output, the message

indicates the content filtering did not allow the file
download.
Step 2.3
From your assigned SRX device, find the session in the session table for your ftp
connection.
lab@srxC-1> show security flow session destination-port 21
Session ID: 1516, Policy name: app-service-policy/9, Timeout: 1702, Valid
Resource information : FTP ALG, 1, O
In: 172.20.105.10/56091 --> 172.20.205.l/2l;tcp, If: ge-0/0/4.105, Pkts: 36,
Bytes: 1694
Out: 172.20.205.1/21 --> 172.20.105.10/56091;tcp, If: .local..0, Pkts: 18,
Bytes: 1233
Total sessions: 1
Question: What session ID does your ftp connection

have?

taken from srxC-1, the session ID is 1516.

session?

app-service-policy is handling the session.
Step 2.4
Display the details about your ftp session. Use session ID from the previous step and
execute the show security flow session session-identifie,r
session-id command.
lab@srxC-1> show security flow session session-identifier session-id
Session ID: 1516, Status: Normal
Flag: Ox500042
Policy name: app-service-policy/9
Source NAT pool: Null, Application: junos-ftp/1
Dynamic application: junos:FTP,
Application firewall rule-set: Allowed-services, Rule: ftp
Maximum timeout: 1800, Current timeout: 1684
Session State: Valid
Start time: 10066, Duration: 187
Client: FTP ALG, Group: 1, Resource: O
In: 172.20.105.10/56091 --> 172.20.205.l/2l;tcp,
Interface: ge-0/0/4.105,
Session token: Ox9, Flag: Ox2621
Route: OxaOOlO, Gateway: 172.20.105.10, Tunnel: O
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 36, Bytes: 1694
Out: 172.20.205.1/21 --> 172.20.105.10/5609l;tcp,
Interface: .local..0,
Route: Oxfffb0006, Gateway: 172.20.205.1, Tunnel: O
FIN state: o,
Total sessions: 1
Question: What is the dynamic application name?
Answer: As shown in the output, the dynamic

application a result from application identification is
junos:FTP.
Question: What is the name of the application

firewall rule-set and rule handling this session?
Answer: As shown in the output, the application

firewall rule-set is Allowed-services and rule is ftp.
Step 2.5
View the details of the security policy handling the session.

lab@srxC-1> show security policies policy-name app-service-policy detail
Policy: app-service-policy, action-type: permit, State: enabled, Index: 9,
Scope Policy: o
Sequence number: 1
From zone: Juniper-SV, To zone: ACME-SV
Source addresses:

Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [ O-OJ
Intrusion Detection and Prevention: disabled
Unified Access Control: disabled
Unified Threat Management: Ox06000003
Application firewall:Allowed-services
Session log: at-create, at-close
Question: Does the policy generate any logs?
Answer: Yes, as shown in the output, the policy has

logging enabled and creates logs at the beginning
as well as at the end of the session.
Question: Does the policy have any of the security

features-application firewall, IDP and UTM,
enabled?
Answer: Yes, as shown in the output, the policy has

application firewall and UTM enabled.
Question: Can you tell the name of the referenced

UTM policy?
Answer: No, as shown in the output, there is only an

identifier displayed for the UTM policy instead of the
name.
Question: What is the zone context of the security

policy?
Answer: The answer varies depending on the device

you are working on. As shown in the output taken
from srxC-1, the zone context is from-zone
Juniper-SV to-zone ACME-SV.

Step 2.6
Check the security policy configuration. Use policy name and the zone context from
the previous steps.
lab@srxC-1> show configuration security policies from-zone Juniper-local
to-�:one ACME-loacl policy app-service-policy
match {
source-address any;
destination-address any;
application any;
}
then {
permit
application-services
utm-policy UTM-check;
application-firewall {
rule-set Allowed-services;
session-init;
session-close;
Question: Can you tell the name of the referenced

UTM policy now?
Answer: Yes, as shown in the output, the referenced

UTM policy is UTM-check.
Step 2.7
Check the referenced UTM policy configuration.
lab@srxC-1> show configuration security utm utm-policy UTM-check
content-filtering {
ftp {
upload-profile denied-content;
download-profile denied-content;

Question: What is the UTM policy doing?
Answer: As shown in the output, the referenced

UTM policy is doing content filtering on ftp upload
and download. To tell more details the content
filtering profile denied-content must be examined.
Step 2.8
Examine the content filtering feature profile from the previous step.
lab@srxC-1> show configuration security utm feature-profile content-filtering
profile denied-content
block-extension Deny-extensions;
Question: What is the UTM content filtering feature

profile doing?
Answer: As shown in the output, the referenced

UTM content filtering profile denied-content denies
files with extension defined in the custom object
called Deny-extensions.
Step 2.9
Examine the referenced custom object from the previous step.
lab@srxC-1> show configuration security utm custom-objects filename-extension
Deny-extensions {
value config;
Question: Which file extensions are defined in the

custom object called Deny-extensions?
Answer: As shown in the output, there is only one

file extension defined - "config". This is the reason
why the download of the lab1-start.config file was
denied - the referenced UTM policy denies FTP
upload or download of the files with "config"
extension.
Lab 3-12 • Troubleshooting Security Features www.ju iper.net

Step2.10
Check the UTM status and sessions using the show security utm status
and show security utm session commands.
lab@srx:C-1> show security utm status
UTM service status: Running
lab@srxC-1> show security utm session

UTM session info:
Maximum sessions: 4000
Total allocated sessions: 2
Total freed sessions: 1
Active sessions: 1
Question: What is the UTM status?
Answer: As shown in the output, the UTM service is

running.
Question: How many UTM sessions are active at this

moment?
Answer: As shown in the output, one UTM session is

active.
Step 2.1'.L
View the UTM content filtering statistics using the show security utm
content-filtering statistics command.
lab@srxC-1> show security utm content-filtering statistics
Content-filtering-statistic: Blocked
Base on command list: 0
Base on mime list: 0
Base on extension list: 1
ActiveX plugin: 0
Java applet: 0
EXE files: 0
ZIP files: 0
HTTP cookie: 0

Question: Did any of the options listed above block
traffic?
Answer: As shown in the output, the extension list

was used to block traffic.
Step 2.12
From your assigned virtual router, close the ftp connection.
ftp> bye
221 Goodbye.
cl@vr-device>
Step 2.13
From your assigned SRX device, view the last 10 lines of the RF-FLOW log file.
Note
The RT-FLOW log file is a custom file
receiving messages generated from the
data plane, such as security policy logging.
lab@srxC-1> show log RT-FLOW I last 10

Apr 6 00:30:33 srxC-1 RT_FLOW: RT_FLOW SESSION_CREATE: session created
172.20.105.10/50704->172.20.205.l/21 junos-ftp 172.20.105.10/
50704->172.20.205.1/21 None None 6 app-service-policy Juniper-SV ACME-SV
1646 N/A(N/A) ge-0/0/4.105
Apr 6 00:30:52 srxC-1 RT_UTM: CONTENT_FILTERING_BLOCKED_MT: Content Filtering:
ftp traffic (ftp) from 172.20.105.10 is blocked due to file extension block
list username N/A roles N/A
Apr 6 00:30:58 srxC-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:
172.20.105.10/50704->172.20.205.l/21 junos-ftp 172.20.105.10/
1646 21(962) 12(742) 25 FTP UNKNOWN N/A(N/A) ge-0/0/4.105 No
Apr 6 00:30:58 srxC-1 RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed
TCP FIN: 172.20.105.10/50704->172.20.205.l/21 junos-ftp FTP UNKNOWN
172.20.105.10/50704->172.20.205.l/21 None None 6 app-service-policy
Juniper-SV ACME-SV 1646 21(962) 12(742) 25 N/A N/A N/A

Question: Does the file contain any messages

related your ftp session?
Answer: As shown in the output, the file contains

session creation and session close messages for
the ftp connection. In addition it contains also
notification about the UTM feature blocking the file
download and a message from AppTrack about the
session.
Part 3: Examining and Troubleshooting AppSecure features
In this lab part, you will examine and troubleshoot application identification and
application firewall to determine the reason of experienced traffic processing.
Step 3.1.
From your assigned virtual router, establish an ssh connection from your Juniper
virtual router to your SRX's interface in the ACME zone. Use the same credentials as
for logging in to your SRX device.
Note

cl@vr-device> ssh lab@local-ACME-address routing-instance local-Juniper-VR

lab@l72.20.205.l's password:
--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC
lab@srxC-1>
Step 3.2:
From your assigned SRX device, find the session for your ssh connection.
lab@srxC-1> show security flow session destination-port 22
In: 172.20.105.10/50554 --> 172.20.205.l/22;tcp, If: ge-0/0/4.105, Pkts: 10,
Bytes: 2001
Bytes: 2005
Total sessions: 1

Question: What session ID does your SSH

connection have?


session?

app-service-policy is handling the session. It is the
same security policy as for the ftp connection
before.
Step 3.3
Display the details about your ssh session. Use session ID from the previous step
and execute the show security flow session session-identifier
session-id command.
Session ID: 1683, Status: Normal
Flag: Ox500040
Source NAT pool: Null, Application: junos-ssh/22
Dynamic application: junos:SSH,
Application firewall rule-set: Allowed-services, Rule: ssh
In: 172.20.105.10/50554 --> 172.20.205.l/22;tcp,
FIN state: o,
Out: 172.20.205.1/22 --> 172.20.105.10/50554;tcp,
Interface: .local ..0,
Route: Oxfffb0006, Gateway: 172.20.205.1, Tunnel: 0
FIN state: o,
Total sessions: 1

Adva nced Ju nos Enterprise Security Troubleshooti ng

junos:SSH.


firewall rule-set is Allowed-service and rule is ssh.
Step 3.4
From your assigned virtual router, execute the show system uptime and show system
users commands and then close the ssh connection.
lab@srxC-1> show system uptime
Current: time: 2013-04-06 00:32:00 UTC
System booted: 2013-04-05 21:28:31 UTC (03:03:29 ago)
Protocols started: 2013-04-05 21:30:56 UTC (03:01:04 ago)
Last configured: 2013-04-06 00:27:18 UTC (00:04:42 ago) by lab
12:32AM up 3:03, 4 users, load averages: 0.16, 0.16, 0.15
lab@srxC-1> show system users

USER TTY FROM LOGIN@ IDLE WHAT
lab uO Fri09PM 22 -cli (cli)
lab pO 10.210.14.158 FrilOPM - -cli (cli)
lab pl 10.210.14.158 FrilOPM - telnet 172.20.
lab p2 172.20.105.10 12:31AM - -cli (cli)
lab@srxC-1> exit
Connection to 172.20.205.1 closed.
Step 3.5
From your assigned SRX device, view the last 10 lines of the RF-FLOW log file.
172.20.105.10/52965->172.20.205.1/22 junos-ssh 172.20.105.10/
1663 14(2353) 13(2293) 8 SSH UNKNOWN N/A(N/A) ge-0/0/4.105 No
www.juniper.net Troubleshooti ng Security Features • Lab 3-17

Apr 6 00:31:38 srxC-1 RT_FLOW: APPTRACK_SESSION CLOSE: AppTrack session closed

TCP FIN: 172.20.105.10/52965->172.20.205.l/22 junos-ssh SSH UNKNOWN
Apr 6 00:31:42 srxC-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
172.20.105.10/50554->172.20.205.l/22 junos-ssh 172.20.105.10/
50554->172.20.205.1/22 None None 6 app-service-policy Juniper-SV ACME··SV
1668 N/A(N/A) ge-0/0/4.105
172.20.105.10/50554->172.20.205.l/22 junos-ssh 172.20.105.10/
50554->172.20.205.1/22 None None 6 app-service-policy Juniper-SV ACME··SV
1668 65(6669) 55(7565) 40 SSH UNKNOWN N/A(N/A) ge-0/0/4.105 No
Apr 6 00:32:22 srxC-1 RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed
TCP FIN: 172.20.105.10/50554->172.20.205.l/22 junos-ssh SSH UNKNOWN

related your SSH session?

the ssh connection. In addition it contains also
AppTrack session close message.
Step 3.6
View the application system cache (ASC) using the show services
application-identification application-system-cache command.
lab@srxC-1> show services application-identification application-system-cache
Application System Cache Configurations:
application-cache: on
nested-application-cache: on
cache-unknown-result: on
cache-entry-timeout: 3600 seconds
pie: 0/0
Logical system name: 0
IP address: 172.20.205.1 Port: 22 Protocol: TCP
Application: SSH Encrypted: No
Logical system name: O

IP address: 172.20.205.1 Port: 21 Protocol: TCP
Application: FTP Encrypted: No

Question: Does the ASC contain any cached
information?
Answer: As shown in the output, the ASC contains

cached information about IP addresses and port for
the ftp and ssh services.
Step 3.7
From your assigned virtual router, establish a telnet connection from your Juniper
virtual router to your SRX's interface in the ACME zone. Use the same credentials as
for logging in to your SRX device.
Note

Trying 172.20.205.1 ...
Connected to 172.20.205.1.
Escape character is • Al •
srxC-1 (ttyp2)
login: lab
Password:
--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

lab@srxC-1>
Step 3.8
From your assigned SRX device, find the session for your telnet connection.
lab@srxC-1> show security flow session destination-port 23 destination-prefix
local-ACME-address
In: 172.20.105.10/50447 --> 172.20.205.l/23;tcp, If: ge-0/0/4.105, Pkts: 30,
Bytes: 1724
Bytes: 1446
Total sessions: 1

Question: What session ID does your telnet

connection have?


session?

app-service-policy is handling the session. It is the
same security policy as for the ftp and ssh
connections before.
Step 3.9
Display the details about your telnet session. Use session ID from the previous step
and execute the show security flow session session-identifier
session-id command.
Session ID: ·1746, Status: Normal
Flag: Ox500042
Source NAT pool: Null, Application: junos-telnet/10
Dynamic application: PENDING,
Application firewall rule-set: Allowed-services, Rule: PENDING
In: 172.20.105.10/50447 --> 172.20.205.l/23;tcp,
FIN state: 0,
Out: 172.20.205.1/23 --> 172.20.105.10/50447;tcp,
Interface: .local..0,
Route: Oxfffb0006, Gateway: 172.20.205.1, Tunnel: O
FIN state: 0,
Total sessions: 1


PENDING. This means the application identification
has not yet come to final result for identifying the
application.


firewall rule-set is Allowed-service and rule is
PENDING.
Step 3.10
View the application firewall statistics using the show security application-firewall
rule-set all command.
lab@srxC-1> show security application-firewall rule-set all
Rule-set: Allowed-services
Rule: ftp
Dynamic Applications: junos:FTP
Action:permit
Number of sessions matched: 1
Rule: ssh
Dynamic Applications: junos:SSH
Action:permit
Default rule:deny
Number of sessions matched: O
Number of sessions with appid pending: 1
Question: Is there currently any session without

identified application?
Answer: As shown in the output, there is one

session for which the application identification has
not been finished. It is listed in this line: Number
of sessions with appid pending: 1

Step3.11
From your assigned virtual router, execute the show system uptime and show system
users commands and then close the telnet connection.
lab@srxC-1> show system uptime
Current time: 2013-04-06 00:39:07 UTC
System booted: 2013-04-05 21:28:31 UTC (03:10:36 ago)
Protocols started: 2013-04-05 21:30:56 UTC (03:08:11 ago)
Last configured: 2013-04-06 00:27:18 UTC (00:11:49 ago) by lab
lab@srxC-1> show
Question: Were you able to execute both command?
Answer: As shown in the output, the first command

is performed but when trying to enter the second
command the session gets stuck.
Step3.12
Terminate the stuck telnet session by hitting the CTRL+] key combination and
entering the quit command.
telnet> quit
Connection closed.
cl@vr-device>
Step3.13
From your assigned SRX device, view the application firewall statistics using the
show security application- firewall rule-set all command again.
lab@srxC-1> show security application-firewall rule-set all
Rule-set: Allowed-services
Rule: ftp
Dynamic Applications: junos:FTP
Action:permit
Rule: ssh
Dynamic Applications: junos:SSH
Action:permit
Default rule:deny
Number of sessions with appid pending: O

AdvancedJunos Enterprise Security Troubleshooting
Question: Is there currently any session without
identified application?
Answer: As shown in the output, there are no

session for which the application identification has
not been finished. It is listed in this line: Number
of sessions with appid pending: O
Question: Which counted did increase comparing to

the previous command output?
Answer: As shown in the output, the default rule

counter has increased by 1.
Step 3.14
View the last 15 lines of the RF-FLOW log file.
Apr 6 00:38:04 srxC-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
172.20.105.10/50447->172.20.205.l/23 junos-telnet 172.20.105.10/
1746 N/A(N/A) ge-0/0/4.105
Apr 6 00:39:04 srxC-1 RT_FLOW: APPTRACK_SESSION_VOL_UPDATE: AppTrack volume
update: 172.20.105.10/50447->172.20.205.l/23 junos-telnet TELNET UNKNOWN
Apr 6 00:39:28 srxC-1 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
172.20.105.10/50447->172.20.205.l/23 junos-telnet 6(0) app-service-policy
Juniper-SV ACME-SV UNKNOWN UNKNOWN N/A(N/A) ge-0/0/4.105 No
Apr 6 00:39:28 srxC-1 RT FLOW: RT FLOW SESSION CLOSE: session closed
application failure or action: l72.20.l05.l0/50447->l72.20.205.l/23
junos-telnet 172.20.105.10/50447->172.20.205.l/23 None None 6
app-service-policy Juniper-SV ACME-SV 1746 55(3042) 38(2546) 84 UNKNOWN
UNKNOWN N/A(N/A) ge-0/0/4.105 No
Apr 6 00:39:28 srxC-l RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed
application failure or action: 172.20.105.10/50447->172.20.205.l/23
junos-telnet TELNET UNKNOWN l72.20.l05.10/50447->l72.20.205.l/23 None None 6
app-service-policy Juniper-SV ACME-SV 1746 55(3042) 38(2546) 84 N/A N/A N/A
www.juniper.
net Troubleshooting Security Features • Lab3-23

related your telnet session?

the telnet connection. In addition it contains also
App Track session close message and a session
deny message.
Question: Based on the available information can

you tell why the telnet session has been initially
allowed but then dropped?
Answer: The security policy handling the telnet

session has the application firewall allowed which
allows only SSH and FTP applications and denies all
other applications. When the telnet session was
initiated the application identification process has
started but for correctly identifying the application
couple of messages had to be exchanged between
the client and the server. This was the reason for
the first executed command in the telnet session to
be successful performed because the application
identification process has not yet been done. But
during the second command the identification
processes finished and because the application
was not allowed the connection was dropped.
Step 3.15
Log out of your assigned device using the exit command.
lab@srxC-1> exit
srxC-1 (ttyuO)
login:
0 Tell your instructor that you have completed this lab.


_,.... _,.... _ /
0
ge-0/0/0 (on all student dev,ces)
•...· .·.I.· -···..,· ----®

.,,.... srxA-1
_,.... Management
� Netwml<
:J
.- Serial Console
, , '-,
Terminal \:\
Server \ '
'- Connections srxA-2 �
&c:1111: Workstations
'-
\' ' '�

r�:-- -
\ '\ Management Addressing
\ '\ 'iI,
'
\ '- srxD-2 ----�-"""i
srxD-1
\ srxD-2
\ 1�2 vr-device
' sncB-1
\ I S<XB-2 Server
\D
I =1 Gateway
Tenn Server
Server Note: Your instructor will provide address and access information.
�tio� Services WWWJumper.net

(=:):-�
Hostname VLAN·ID
s r xA1
- 101, 201
s r xA2
- 102, 202
Host 172.31.15.1
V0/4.201 -- --- ge-0/0/4.102 (..1) V0/4.202

Tagged Interface
172.20.201.0/24 (see VI.AN Assignments table) 172.20.102.0/24 172.20.202.0/24
µ� µ�
Juniper-WF ACME-WF

(?)
�
Hostname
srxB-1
srxB-2
1D
Host l72.3L15.1
lcO: 192.168.2.1
�lJ
V0/4_203 -- ___.., ge-0/0/4- V0/4-204
Tagged Interface / ,.
172_20.203.0/24 (see VLAN Assignments table) 172.20.104.0/24 172.20.204.0/24
(.10) (.10)
Juniper-WF AC M EWF
-

--iEJ
Host name VLAN-10
srxC-1 105, 205
srxC-2 106, 206
Host 1.72.31.15.1
lcO: 192.168.2.1
��
V0/4_205 -- ___... ge-0/0/4_1 0/4-206
Tagged Interface / \.J-J '\.- -.
172.20_205_0/24 (see VIAN Assignments table) 172.20.106.0/24 172_20.206.0/24
(.10) (.10)
..._Virtual Routers -- Juniper-WF
Lab 3-26 • Troubleshooting Security Features www.juniper_net


Host .172.31.15.l
ge-0/0/4.107 i.1) e-0/0/4207 -- --ge-0/0/4.108 (.1)

Tagged Interface
172.20.107.0/24 172.20.207.0/24 (see VLAN Assignments table) 172.20.208.0/24
(.10)
Juniper-SV ACME-SV --Virtual Routers -- Juniper-WF AC M EWF

-


Lab
Troubleshooting Chassis Clustering
Overview
In this lab, you will troubleshoot chassis clustering. You will work with the remote team in
your pod to combine your assigned devices into a single chassis cluster. You will use
Junos OS CLI commands and analyze trace log files to find out the causes for the
detected problem. Next you define the solution for the issues and perform it.
Build the chassis cluster.
Troubleshoot chassis cluster using Junos CLI command and trace file.
Monitor and verify the chassis cluster status.
www.juniper.net Troubleshooting Chassis Clustering • Lab 4-1

in to your designated station. Next, you will load the starting configuration for the
lab. Then, you will verify the connectivity between your assigned virtual routers and
your device.
Note

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.


Step 1.2
Access the command-line interface (CU) at your station using either the console to
maintain connectivity even during device reboot.
Lab 4-2 • Troubleshooting Chassis Clustering www.juniper.net

-�·
Q!!j'l£,��01,,&;-, , ,,pg{ ,,', i 'pg•, cillm'0 ,wAlHJ�
Protocol:
Hostname:
Por:t
D Show quick connecton star u

t p 0 Save se ssion
0 Open ina tab
Connect � l�_C_an_cl _e
.· �
Step 1.3
the lab4-start. configfrom the /var/home/lab/ajest/ directory. Commit the
srxC-1 (ttypO)
login: lab
Password:

[edit]
lab@srxC-1# load override ajest/lab4-start.config
load complete

commit complete
lab@srxC-1>

Part 2: Forming and Troubleshooting a Chassis Cluster
In this lab part, you enable and troubleshoot 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.You will troubleshoot problems related to chassis clustering.You
first experience the problem then use CLI tools to find the problem cause and finally
you define the solution and resolve the problem.
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
Clear the j srpd log file to simplify the troubleshooting process later in the lab.
lab@srxC-1> clear log jsrpd
Step 2.2
Initiate the chassis cluster pairing by issuing the command set chassis cluster
cluster-id 1 node node-id reboot, where node-id is O 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
AWaiting (max 60 seconds) for system process 'vnlru_mem' to stop...done

Waiting (max 60 seconds) for system process 'vnlru' 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 0 done
syncing disks... All buffers synced.

Uptime: 20m56s
Rebooting...
Step 2.3
Log in to the device once it has rebooted. Use the username and password provided
by your instructor.

srxC-1 (ttyuO)
login: lab
Password:

{hold:nodeO}
lab@srxC-1>
Question: What state of the node does the CLI

indicate?
Answer: As indicated by the output, the node is in

the hold state.
Step 2.4
Check the chassis cluster status using the show chassis cluster status
command.
{hold:nodeO}
lab@srxC-1> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: O , Failover count: O

nodeO 1 hold no no
nodel 0 lost n/a n/a
{hold:nodeO}
lab@srxC-1>
Question: What are the states of both nodes?
Answer: The answer will depend on which SRX

device is your assigned device. As indicated by the
output from srxC-1, the node O is in the hold state
and the node 1 is I the lost state.
Step 2.5
View the chassis cluster statistics using the show chassis cluster
statisticsand s how chassis cluster control-plane statistics
command.
{hold:nodeO}
lab@srxC-1> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 0
Heartbeat packets received: O
Heartbeat packet errors: 0
Fabric link statistics:
Child link O
Probes sent: O
Probes received: O
Child link 1
Probes sent: O
Probes received: O
error: usp_ipc_client_open: failed to connect to the server after 1 retries
{hold:nodeo}
lab@srxC-1> show chassis cluster control-plane statistics
Control link 0:
Heartbeat packets received: O
Heartbeat packet errors: 0
Child link O
Probes sent: 0
Probes received: O
Child link 1
Probes sent: 0
Probes received: 0
{hold:nodeO}
lab@srxC-1>
Question: Which of the statistics are increased?
Answer: As indicated by the output, none of the

statistics are increased.
Question: Where would you look next?
Answer: Based on the statistics values the problem

might be associated with chassis cluster interfaces
- control and data links, the cluster does not receive
nor is it able to send any heartbeats or probes. The
next step would be check the control and data link
status.
Step 2.6
Check the chassis cluster interfaces using the show chassis cluste:r::
interfaces command.
{hold:nodeO}
lab@srxC-1> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 fxpl Down
Fabric link status: Down
Fabric interfaces:
Name Child-interface Status
(Physical/Monitored)
fabO
fabO
{hold:nodeO}
lab@srxC-1>
Question: What is the state of the control and fabric

link?
Answer: As indicated by the output, both links are

Down.
Step 2.7
Check all the fxp interfaces status.
{hold:nodeO}
lab@srxC-1> show interfaces terse I match fxp
fxpO up up
fxpl up up
fxp2 up up
{hold:nodeO}
lab@srxC-1>
Question: What is the state of the fxp interfaces?
Answer: As indicated by the output, all the fxp

interfaces are up.
www.juniper.net Troubleshooting Chassis Clustering • Lab 4- 7

Question: Are there any details shown for the fxp
interfaces?
Answer: As indicated by the output, no other

information is displayed for the fxp interfaces.
Question: Is this an expected output?
Answer: No, the cluster configures the fxp1 and

fxp2 interfaces with specific parameters, e.g. IP
addresses, for its communication purposes.
Step 2.8
View chassis cluster details using the show chassis cluster information
command.
{hold:nodeO}
lab@srxC-1> show chassis cluster information detail
error: Could not connect to nodeO : No route to host
Question: What does the command output display?
Answer: As indicated by the output, an error about

connectivity problem to node O is displayed.
Step 2.9
Examine the j srpd log file.
{hold:nodeo}
lab@srxC-1> show log jsrpd
Apr 5 18:08:35 successfully set default traceoptions cfg
Apr 5 18:08:37 JSRPD release 12.lRS.5 built by builder on 2013-01-17 07:43:20
UTC starting, pid 1041
Apr 5 18:08:37 node id nodeO, cluster-id 1 in kernel
Apr 5 18:08:37 Unable to read data link status blob No such file or directory
Apr 5 18:08:37 printing fpc_num O
Apr 5 18:08:37 printing fpc_num 1
Apr 5 18:08:37 Interface fxpl is down. devflags: Ox3, ifdm_flags: Ox8

Apr 5 18:08:37 printing fpc_num
Apr 5 18:08:37 last message repeated 2 times
Apr 5 18:08:37 printing fpc_num p

Apr 5 18:08:37 printing fpc_num
Apr 5 18:08:37 printing fpc_num e
Apr 5 18:08:37 printing fpc_num d
Apr 5 18:08:37 printing fpc_num n
Apr 5 18:08:37 IP Monitoring infrastructure initialized
Apr 5 18:08:37 Control interface is not present yet, retry later
Apr 5 18:08:37 Setting the control link[O] as fxpl with ifl index -1
Apr 5 18:08:37 jsrpd pid (1041) wrote successfully using sysctl
Apr 5 18:08:37 Socket setup for sending ctrl heartbeat
Apr 5 18:08:37 successfully set default traceoptions cfg
Apr 5 18:08:37 reading the cluster part of the config
Apr 5 18:08:37 reading the cluster member list
Apr 5 18:08:37 reading the cluster attributes
Apr 5 18:08:37 change in heartbeat interval: new value: 1000, old value: 0.
resetting timer
Apr 5 18:08:37 change in heartbeat threshold : new value: 3 old value: O
Apr 5 18:08:37 jsrpd hb attrib (3000) wrote successfully using sysctl
Apr 5 18:08:37 failed to sync hb attrib to PFE
Apr 5 18:08:37 initial hold set to: 30
Apr 5 18:08:37 fabric to_child_mapping: O uspipc to pfe O ifstate download
0
Apr 5 18:08:37 fabric monitoring is enabled
Apr 5 18:08:37 hardware monitoring is enabled
Apr 5 18:08:37 RG-0 failover for HW errors is enabled
Apr 5 18:08:37 Failover for loopback error is disabled
Apr 5 18:08:37 Failover for fabric nexthop error is disabled
Apr 5 18:08:37 Failover for mbuf error is disabled
Apr 5 18:08:37 Unable to read data-plane mode for cluster O from ssam, error 2
Apr 5 18:08:37 data plane mode is active-active
Apr 5 18:08:37 fwdd monitoring is enabled
Apr 5 18:08:37 fabric time out is set to O
Apr 5 18:08:37 control link recovery is disabled
Apr 5 18:08:37 Reading redundancy-group config
Apr 5 18:08:37 reading the RG entries config
Apr 5 18:08:37 deleting all RGs
Apr 5 18:08:37 reading the RG entries config
Apr 5 18:08:37 creating RGO
Apr 5 18:08:37 unable to set priority, for RG-0, fsm context uninitialized
Apr 5 18:08:37 Setting hold-down interval to 300 for RG-0
Apr 5 18:08:37 Set IP monitoring global weight to O global threshold to O for
rg-0
Apr 5 18:08:37 Set IP monitoring retry interval to O retry count to O for rg-0
Apr 5 18:08:37 All global IP monitoring parameters are set to O because all IPs
are deleted for rg-0
Apr 5 18:08:37 fabric to child_mapping: O uspipc to pfe : O ifstate download :
0
Apr 5 18:08:37 failed to read rg_info from ssam for RG-0, error 2
Apr 5 18:08:37 read the default state from kernel, state (0) failover-cnt O
RG-0
Apr 5 18:08:37 LED color changed from : Off to Red, reason Peer node: nodel is
not present
Apr 5 18:08:37 Current threshold for rg-0 is 255. Failures: none
Apr 5 18:08:37 Ctrl-link (0) timer started
Apr 5 18:08:37 Ctrl-link (1) timer started
Apr 5 18:08:37 tnp address from PIC entry for pfe: OxllOOOOl

Apr 5 18:08:37 SNMP subagent initialized
Apr 5 18:08:45 Interface fxpl is up. devflags: Ox3, ifdm_flags: OxO
Apr 5 18:08:45 Flowd Up handler called. Ignoring event because RGO is not yet
initialized
Apr 5 18:08:45 printing fpc num O
Apr 5 18:08:45 jsrpd_ifd_msg_handler: Interface fxpO is up
Apr 5 18:08:45 Error getting IFF for fxpO inreface
Apr 5 18:09:07 Control ifl -1 is still not valid, restarting hold timer for rg
0
Question: Does the log contain anything about the

fxp interfaces?
Answer: As indicated by the output, the logs states

the fxpO and fxpl interfaces are up, but the
protocol family information (IFF - Interface Family)
could not be retrieved for fxpO. The devices used in
the lab are SRX240 model - a branch model. The
control interfaces are predefined and fixed - ge-0/
0/0 becomes fxpO and ge-0/0/1 becomes fxpl. If
any configuration is present in the configuration file
for these interface when the cluster is created the
software is not able to configure them as needed
and therefore the cluster does not form correctly.
Step 2.10
Check if any configuration is present for the ge-0/0/0 or ge-0/0/1 interfaces.
{hold:nodeo}
lab@srxC-1> show configuration interfaces ge-0/0/0
description "MGMT Interface - DO NOT DELETE";
unit O {
family inet
address 10.210.14.135/27;
{hold:nodeo}
lab@srxC-1> show configuration interfaces ge-0/0/1
{hold:nodeO}
lab@srxC-1>

Question: Is there any configuration present for

those interfaces?
Answer: As indicated by the output, the

configuration for ge-0/0/0 interface is in the
configuration file.
Question: What action would you take next?
Answer: The next step is to remove the

configuration for ge-0/0/0 interface and reboot the
node.
Step 2.1:1
Remove the ge-0/0/0 configuration. Commit and exit to the operational mode when
complete.
{hold:nodeo}
warning: Clustering enabled; using private edit
error: shared configuration database modified
Please temporarily use 'configure shared' to commit

outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'
lab@srxC-1> configure shared

The configuration has been changed but not committed
{hold:nodeo} [edit]
lab@srxC-1# delete interfaces ge-0/0/0
{hold:nodeO} [edit]
[edit ":ecurity zones functional-zone management]
'interfaces ge-0/0/0.0'
Interface ge-0/0/0.0 must be configured under interfaces
error: configuration check-out failed
{hold:nodeO} [edit]
lab@srxC-1# delete security zones functional-zone management interfaces ge-0/0/
0.0
{hold:nodeO} [edit]
nodeO:

commit complete
{hold:nodeO}
lab@srxC-1>
Step 2.12
Reboot the node.
{primary:nodeO}
lab@srxC-1> request system reboot
Reboot the system ? [yes, no] (no) yes
Shutdown NOW!
[pid 1681]
{primary:nodeO}
lab@srxC-1>
*** FINAL System shutdown message from lab@srxC-1 ***
Part 3: Monitoring a Chassis Cluster
In this lab part, you will monitor the chassis cluster status using the CLI tools.
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 3.1
Log in to your assigned device once it has rebooted.
Boot media /dev/daO does not have dual root support
Fri Apr 5 18:29:28 UTC 2013
srxC-1 (ttyuO)
login: lab
Password:

{hold:nodeo}
lab@srxC-1>

Step 3.2
Check all the fxp interfaces status.
{second.ary:nod.eO}
lab@sr:x:C-1> show interfaces terse I match fxp
fxpO up up
fxpl up up
fxpl.O up up inet 129.16.0.1/2
fxp2 up up
fxp2.0 up up tnp O:x:1100001
Question: What is the state of the fxp interfaces?
Answer: As indicated by the output, all the fxp

interfaces are up.
Question: Are there any details shown for the fxp

interfaces?
Answer: As indicated by the output, an IP address is

displayed for fxpl and a TNP address is displayed
for fxp2 interface.
Step 3.3
View the chassis cluster status.
{primary:nodeO}
lab@sr:x:C-1> show chassis cluster status
Cluster ID: 1
Redundancy group: O , Failover count: 1

nod.ea 1 primary no no
nod.el 1 secondary no no
{primary:nodeO}
lab@sr:x:C-1>
Question: What are the states of the cluster nodes?
Answer: As indicated by the output from srxC-1,

nodeO is primary and node 1 is secondary.

Step 3.4
View the chassis cluster control plane-statistics using the show chassis
cluster control-plane statistics command.
{primary:nodeO}
lab@srxC-1> show chassis cluster control-plane statistics
Control link 0:
Heartbeat packets received: 105
Heartbeat packet errors: O
Child link O
Probes sent: 0
Probes received: O
Child link 1
Probes sent: O
Probes received: O
{primary:nodeO}
lab@srxC-1>
Question: Are any of the counters increased?
Answer: As indicated by the output, the both - sent

and received - control link heartbeat counters have
increased.
Step 3.5
Check the fabric interfaces status using the show interfac es terse I
match fab command.
{primary:nodeO}
lab@srxC-1> show interfaces terse I match fab
fabO up down
fabO. 0 up down inet 30.17.0.200/24
fabl up down
fabl.O up down inet 30.18.0.200/24
swfabO up down
swfabl up down
Question: What is the state of the fabric interfaces?
Answer: As indicated by the output, all fxp

interfaces are administratively up and link status is
down.

Question: Can you think of any reason why is the
fabric interface status down?
Answer: The fabric interface have not been yet

configured.
Step 3.6
Check the cluster interfaces status using the show chassis cluster
interfaces command.
{primary:nodeO}
Control link status: Up
Control interfaces:
Index Interface Status
O fxpl Up
Fabric link status: Down
Fabric interfaces:
fabO
fabO
fabl
fabl
Question: What is the state of the fabric link?
Answer: As indicated by the output, the fabric link

status is down.
Note
Perform the next step ONLY on the SRX1
device.
Step 3.7
Enter configuration mode and load the lab6-p3s8. configfrom the /var I
home/lab/aj est/ directory. Commit the configuration when complete.
{primary:nodeO}
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
{primary:nodeO} [edit]
lab@srxC-1# load override ajest/lab6-p3s8.config
load complete
{primary:nodeO} [edit]
nodeO:
configuration check succeeds
nodel:
commit complete
nodeO:
commit complete
{primary:nodeO}
lab@srxC-1>
Step 3.8
View the control and fabric interfaces status using the show i nterfaces terse
I match "fxp I fab" command.
{primary:nodeO}
lab@srxC-1> show interfaces terse I match "fxplfab"
ge-0/0/2.0 up up aenet --> fabO.O
ge-5/0/2.0 up up aenet --> fabl.O
fabO up up
fabO.O up up inet 30.17.0.200/24
fabl up up
fabl.O up up inet 30.18.0.200/24
fxpO up up
fxpO.O up up inet 10.210.34.135/26
fxpl up up
fxpl.O up up inet 129.16.0.1/2
fxp2 up up
fxp2.0 up up tnp OxllOOOOl
swfabO up down
swfabl up down
Question: What is the state of the control and fabric

interfaces?
Answer: As indicated by the output, all control and

fabric interfaces are administratively up and have
link status up.
Step 3.9
Display the cluster status using the show chassis cluster status
command.

{primary:nodeo}
lab@srxC-1> show chassis cluster status
Cluster ID: 1
Redundancy group: 0 Failover count: 1

nodeO 1 primary no no
nodel 254 secondary no no

nodeO 200 primary no no
nodel 100 secondary no no

nodeO 100 secondary yes no
nodel 200 primary yes no
{primary:nodeO}
lab@srxC-1>
Question: How many redundancy groups are

present?
Answer: As indicated by the output, three

redundancy groups are present - RGO, RG1 and
RG2.
Question: Has any redundancy group the option

preempt enabled?
Answer: As indicated by the output, RG2 has

preempt enabled.
Step 3.10
View the chassis cluster interfaces using the show chassis cluster
interfaces command.
{primary:nodeO}
Control link status: Up
Control interfaces:
Ind.ex Interface Status
0 fxpl Up
Fabric link status: Up

Fabric interfaces:
fabO ge-0/0/2 Up I Up
fabO
fabl ge-5/0/2 Up I Up
fabl
Redundant-ethernet Information:
Name Status Redundancy-group
rethO Up 1
rethl Up 2
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-5/0/3 255 Up 2
{primary:nodeo}
lab@srxC-1>
Question: What is the status of the control and

fabric links?
Answer: As indicated by the output, both the control

and the data links are Up.
Question: Which interfaces are used for fabric link?
Answer: As indicated by the output, the ge-0/0/2

and ge-5/0/2 interfaces are used for the fabric link.
Question: Is any interface being monitored? If so,

for which redundancy group?
Answer: As indicated by the output, the ge-5/0/3

interface is being monitored for redundancy group
2.

Question: Would the interface failure cause the

redundancy group failover?
Answer: Yes, it would because the interface weight

is 255 which is also the failover threshold for
redundancy groups.
Step 3.1:1
Displaydetailed information the show chassis cluster information
command.
{primary:nodeo}
lab@srxC-1> show chassis cluster information
nodeO:
Redundancy mode:
Configured mode: active-active
Operational mode: active-active
Redundancy group: 0, Threshold: 255, Monitoring failures: none

Events:
Apr 5 18:30:07.031 hold->secondary, reason: Hold timer expired
Apr 5 18:30:33.069 secondary->primary, reason: Better priority (1/1)

Events:
Apr 5 18:46:07.163 hold->secondary, reason: Hold timer expired
Apr 5 18:46:07.190 secondary->primary, reason: Better priority (200/
100)

Events:
Apr 5 18:46:07.167 : hold->secondary, reason: Hold timer expired
nodel:
Redundancy mode:
Configured mode: active-active
Operational mode: active-active

Events:

Events:

Events:

Apr 5 18:41:17.405 : secondary->primary, reason: Better priority (200/
100)
{primary:nodeO}
lab@srxC-1>
Question: Based the command output why is the

redundancy group2 primary on node 1?
Answer: As indicated by the output, the reason that

redundancy group2 is primary on node 1 is
"Better priority (200/100)".
Question: What is the cluster scenario in this case?
Answer: The cluster scenario is Active/Active,

because RG 1 is primary on node O and RG is
primary on node 1.
Part 4: Disabling the Chassis Cluster
In this lab part, you break down the chassis cluster implementation. You will then
load the Lab 1 starting configuration on each node.
Step 4.1
Issue the set chassis cluster disable reboot command.
{primary:nodeO}
lab@srxC-1> set chassis cluster disable reboot
Successfully disabled chassis cluster. Going to reboot now{primary:nodeO}
lab@srxC-1>
*** FINAL System shutdown message from root@srxC-1 ***
Step 4.2
Once your device reboots, log in with the credentials provide by your instructor. Enter
configuration mode and load the labl-start. configfrom the /var/home/
lab/ajest/ directory. Commit the configuration and return to operational mode
when complete.
Boot media /dev/daO does not have dual root support
Fri Apr 5 21:30:39 UTC 2013
Amnesiac (ttyuO)
login: lab
Password:

lab> co:nfigure
Enterin3 configuration mode
[edit]
lab# load override ajest/labl-start.config
load complete
[edit]
1 ab# co,[llll\it and-quit
commit complete
lab@srxC-1>
Step4.3
Log out of your assigned device using the exit command.
lab@srxC-1> exit
srxC-1 (ttyuO)
login:


-$/ ge-0/0/0 (on all student devices)
•c•••-· ----e� � �Lr

.,....
.,.... .,.... s r xA 1
-
.,.... n
a agement
' _J-m::D]fi2ir2:i_·
c:1
�Networn
• Serial Console
Terminal\:"\, Connections s r xA2
- . Student
Server \ I Workstations
C
'
��,' .
\\ \. \. '®'
\ \.
�
\ \.Cl
\ \. srxD-2
::: �
srx,H srxD-1
\ vr-device srxB-2 Server

\ srxC-1 Gateway
'{]
srxG-2 Term Server -----
Server Note: Your instructor will provide address and access information

Untrust Zone
Cluster-ID 1
fxp1
rethO Network reth1 Network

172.20.10.0/24 172.30.10.0/24
VIAN 221 VLAN231


Untrust Zone
Cluster-ID 1
fxpl
rethO Network rethl Network

17220.20.0/24 TrustZone 172.30.20.0/24
VLAN222 VLAN232
vr222 vr232

Untrust Zone
Cluster-ID 1
fxpl

17220.30.0/24 Tr ust Zone 172.30.30.0/24
VLAN223 VLAN233
LllJnm
,_
��i1- � <>,:»i-
Worldwide. fducalion Services

"'�""- �-
WWW.jUrupe<nel


Untrust Zone
Cluster-ID 1
lxpl

172_20-40_0/24 172_30_40_0/24
VLAN224 VLAN234

AJEST 12.b LGD PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AJEST 12.b LGD PDF

Uploaded by

Copyright:

Available Formats

Ativanced Junos Enterprise Security

1133 Innovation Way

Course Number: EDU-JUN-AJEST

Advanced Junos Enterprise Security Troubleshooting Lab Gulde. Revision 12.b

Lab 2:: Troubleshooting IPsec ........................................... 2-1

Lab 3:: Troubleshooting Security Features ................................. 3-1

Lab 4:: Troubleshooting Chassis Clustering ................................ 4-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. Phy sical interface:fxpO,

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

www.juniper.net Document Conventions • vii

Education Services Offerings

About This Publication

Juniper Networks Support

viii • Additional Information www.juniper.net

www.juniper.net Troubleshooting Security Zones and Policies • Lab 1-1

Part 1: Accessing Your Device and Verifying the Connectivity

Question: What is the management address

Answer: The answer varies. The sample hostname

Lab 1-2 • Troubleshooting Security Zones and Policies www.ju11iper.net

D Show quick connect on startup [t] Save session

--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC

lab@srxC-1# commit and-quit

www.juniper.net Troubleshooting Security Zones and Policies • Lab 1-3

Question: What is the administrative status and link

Answer: As shown in the output, the administrative

Question: What is the status of your management

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

Lab 1-4 • Troubleshooting Security Zones and Policies www.juniper.net

This lab step requires you to open a

D Show quick connect on startup 0 Save session

Virtual Router Login Details

Student Device Username Password

www.juniper.net Troubleshooting Security Zones and Policies • Lab 1-5

--- JUNOS ll.4Rl.6 built 2011-11-15 11:28:05 UTC

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

cl@vr-device> ping local-Juniper-address routing-instance local-Juniper-VR

--- 172.20.105. 1 ping statistics ---

cl@vr-device> ping local-ACME-address routing-instance local-ACME-VR count 3

--- 172.20.205.1 ping statistics ---

Lab 1-6 • Troubleshooting Security Zones and Policies www.juniper.net

Answer: As indicated by the output, both pings

Part 2: Troubleshooting Zones

--- 192.168.1.1 ping statistics

Question: Was the ping successful?

Answer: As indicated by the output, the ping is not

vrlOS.inet.O: 11 destinations, 11 routes (11 active, 0 holddown, O hidden)

0.0.0.0/0 *[Static/SJ ld 07:04:57

www.juniper.net Troubleshooting Security Zones and Policies • Lab 1-7

Question: Does the virtual router make correct

Answer: As indicated by the output, the virtual

Question: Based on the gathered information can

Answer: Because the pings are sent from the virtual

Lab 1-8 • Troubleshooting Security Zones and Policies www.juniper.net