jljn1per - 1 file download

Ativanced Junos Enterprise Security

Troubleshooting

12.b

JLJn1Per NETWORKS

Worldwide Education Services

1133 Innovation Way

Sunn)Nale, CA 94089

USA

408-745-2000

www.juniper.net

Course Number: EDU-JUN-AJEST

Lab Guide

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 1: Accessing Your Device and Verifying the Connectivity ..................................... 2-2

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 1: Accessing Your Device and Verifying the Connectivity ..................................... 3-2

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 1: Accessing Your Device and Verifying the Connectivity ..................................... 4-2

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

Objectives

lntend1�d Audience

Course Level

Prerequisites

www.juniper.net

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 Ju nos OS. This course is based on Ju nos OS Release 12.1R5.5.

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.

The primary audience for this course is the following:

Individuals responsible for configuring and monitoring devices running the Ju nos OS.

Advanced Junos Enterprise Security Troubleshooting is an advanced-level course.

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

Course Overview • v

Course Agenda

Day1

vi • Course Agenda

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

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

Franklin Gothic

Courier New

Description

Normal text.

Console text:

Screen captures

Noncommand-related

syntax

GUI text elements:

Menu names

Text field entry

Usage Example

Most of what you read in the Lab Guide

and Student Guide.

commit complete

Exiting configuration mode

Select File > Open, and then click Configuration.confin the Filename text box.

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.

Style Description

Normal CLI No distinguishing variant.

Normal GUI

CLI Input Text that you must enter.

GUI Input

Usage Example

Phy sical interface:fxpO,

Enabled

View configuration history by clicking

Configuration > History.

lab@San Jose> show route

Select File > Save, and type

conf ig. ini in the Filename field.

Defined and Undefined Syntax Variables

www.juniper.net

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.

Style

CLI Variable

GUI Variable

CLI Undefined

GUI Undefined

Description

Text where variable value is already

assigned.

Text where the variable's value is

the user's discretion or text where

the variable's value as shown in

the lab guide might differ from the value the user must input

according to the lab topology.

Usage Example

policy my-peers

Click my-peers in the dialog.

Type set policy policy-name.

ping 10.0.�

Select File > Save, and type

filename in the Filename field.

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 [email protected].

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

Overview

Lab

Troubleshooting Security Zones and Policies

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 Ju nos Enterprise Security Troubleshooting

Part 1: Accessing Your Device and Verifying the Connectivity

Step 1.1

Step 1.2

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.

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.

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


D Show quick connect on startup

Step 1.3

[t] Save session

0 Open in a tab

I, Connect� [ __ ca_n_ce_l�

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 Interface ge-0/0/0

ge-0/0/0.0

ge-0/0/1 ge-0/0/2

ge-0/0/3

www.juniper.net

interfaces terse I match Admin Link Proto up up up up up up up up up up

inet

11 gello 11

Local

10.210.14.135/27

Remote

Troubleshooting Security Zones and Policies • Lab 1-3

Advanced Junos Enterprise Security Troubleshooting

ge-0/0/3.0 up

ge-0/0/4 up

ge-0/0/4.105 up

ge-0/0/4.205 up

ge-0/0/4.32767 up

ge-0/0/5 up

ge-0/0/6 up

ge-0/0/7 up

ge-0/0/8 up

ge-0/0/9 up

ge-0/0/10 up

ge-0/0/11 up

ge-0/0/12 up

ge-0/0/13 up

ge-0/0/14 up

ge-0/0/15 up

loo up

loO.O up

lo0.16384 up

lo0.16385 up

lo0.32768 up

Step 1.5

up inet 172.18.1.2/30

up

up inet 172.20.105.1/24

up inet 172.20.205.1/24

up

up

up

up

up

down

up

up

down

down

up

up

up

up inet 192.168.1.1 -->

up inet 127.0.0.l -->

up inet 10.0.0.l -->

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.

0/0

0/0

0/0

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

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=O ttl=64 time=3.610 ms 64 bytes from 172.20.205.1: icmp_seq=l ttl=64 time=3.645 ms

64 bytes from 172.20.205.1: icmp seq=2 ttl=64 time=3.593 ms

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



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

Step 2.1

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.

Test the connectivity from your Juniper virtual router to your SRX's loopback address.

[email protected]> 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

3 packets transmitted, 0 packets received, 100% packet loss

Step 2.2

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.

View the forwarding decision on your Juniper virtual router to the SRX's loopback.

[email protected]> 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

Step 2.3

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.

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


Step 2.4


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.

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.

lab@srxC-1> configure Entering configuration 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] lab@srxC-1# commit and-quit commit complete




lab@srxC-1>

Step 2.5

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.

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

Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Default Is-Primary

Local: 192.168.1.1

Step 2.6

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.

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 64 bytes from 192.168.1.1: icmp seq=O ttl=64 time=4.005 ms 64 bytes from 192.168.1.1: icmp_seq=l ttl=64 time=3.622 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.622 ms



--- 192.168.1.1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 3.622/3.750/4.005/0.181 ms


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

successful.

Part 3: Troubleshooting Security Policies

Step 3.1

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.

From Telnet session established with the vir tual 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>

www.juriiper.net

Question: Is the telnet connection established?

Answer: As shown in the output, the telnet is not

successful.



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

Step 3.3

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.

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

Step 3.4

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.

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;

[edit security zones security-zone untrust] lab@srxC-1# replace pattern 172.31.16.1 with 172.31.15.1



[edit security zones security-zone untrust] lab@srxC-1# show address-book {

address internet-host 172.31.15.1/32;

} host-inbound-traffic {


protocols all;

interfaces { ge-0/0/3.0;

[edit security zones security-zone untrust] lab@srxC-1# commit and-quit commit complete Exiting configuration mode

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)


login: username

Password:



NOTE: This router is divided into many virtual routers used by different teams.

Please only configure your own virtual router.


cl@vr-device>

Step 3.6

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.


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>

Step 3.7

www.juniper.net

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


From your assigned virtual router, exit from the established telnet session to the

Internet host.



cl@vr-device> exit

Connection closed by foreign host.

cl@vr-device>

Part 4: Troubleshooting Security Policies for Host Traffic

Step 4.1

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.

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>

Step 4.2

Question: Is the telnet connection established?

Answer: As shown in the output, the telnet is not

successful.


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

Policy Type: Configured Sequence number: 1 From zone: Juniper-SV, To zone: ACME-SV Source addresses:

vrl05: 172.20.105.0/24 Destination addresses:

vr205: 172.20.205.0/24 Application: any

IP protocol: 0, ALG: 0, Inactivity timeout: 0 Source port range: [0-0] Destination port range: [0-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 0 VPN packets :

Step 4.4

Question: Is the telnet among allowed

host-inbound-traffic services?

Answer: As shown in the output, the telnet service is

allowed.

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 Exiting configuration mode

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 57916->172.20.105.10/57916 protocol O

0/0, 172.20.105.10/

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

Alloc sess plugin info for

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 OxO, impl mask OxO. re 4

Apr 1 08:04:40 08:04:40.488477:CID-0:RT:-jsf int check: plugin id 5, svc req OxO, impl mask OxO. re 4





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

flow_process_pkt re Ox7 (fp re

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 Policy Type: Configured Sequence number: 1 From zone: ACME-SV, To zone: junos-host Source addresses:

any-ipv4: 0.0.0.0/0 any-ipv6: : : /0

Destination addresses: any-ipv4(global): 0.0.0.0/0 any-ipv6(global): : :/0

Application: junos-telnet IP protocol: tcp, ALG: 0, Inactivity timeout: 1800

Source port range: [0-0] Destination port range: (23-23]




Step4.8

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.

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;

[edit security policies from-zone ACME-SV to-zone junos-host] lab@srxC-1# delete policy drop-telnet

[edit security policies from-zone ACME-SV to-zone junos-host] lab@srxC-1# show ## Warning: missing mandatory statement(s): 'policy'



[edit security policies from-zone ACME-SV to-zone junos-host]

lab@srxC-1# commit and-quit

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.

Escape character is 'A

l•

srxC-1 (ttypO)

login: lab

Password:

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

lab@srxC-1>

www.juniper.net

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

SIXA-2

Sll<B-1

Sll<B-2

srx!r1

srx!r2

srxD-1

srxD-2

vr-device

Server

Gateway

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

172.20.103.0/24

,/(10)

I vr10

3 IJuniper-SV

www.juniper.net

Host 172.31.15.1

V0/4.203 -- -- ge-0/0/4.104 Tagged Interface

172.20.203.0/24 (see VLAN Assignments table) 172.20.104.0/24 (.10) (10j

Juniper-WF

V0/4.204

172.20.204.0/24

ACME-WF



Pod C Network Diagram: Troubleshooting


VLAN-ID Hostname

--El srxC-1 105, 205

srxC-2 106, 206 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


Overview

Lab

Troubleshooting IPsec

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



Step 1.1

Step 1.2


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.

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

necessary. Consult the Management Network Diagram to determine the









Access the command-line interface (CU) at your station using either the console,


Lab 2-2 • Troubleshooting IPsec www.juniper.net

Step 1.3

srxC-1 (ttypO)

login: lab

Password:


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


the lab2-start. configfrom the /var/home/lab/ajestj directory. Commit the


--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC lab@sr:x:C-1> configure Entering configuration mode

[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 ge-0/0/0 up ge-0/0/0.0 up ge-0/0/1 up ge-0/0/2 up ge-0/0/3 up

www.juniper.net

terse up up up up up

I match "gelstOlloO"

inet 10.210.14.135/27

Troubleshooting IPsec • Lab 2-3


ge-0/0/3.0 up ge-0/0/4 up ge-0/0/4.105 up ge-0/0/4.205 up ge-0/0/4.32767 up ge-0/0/5 up

ge-0/0/6 up ge-0/0/7 up ge-0/0/8 up ge-0/0/9 up ge-0/0/10 up ge-0/0/11 up ge-0/0/12 up ge-0/0/13 up ge-0/0/14 up ge-0/0/15 up loo up loo.a up lo0.16384 up lo0.16385 up lo0.32768 up stO up stO.O up

up inet 172.18.1.2/30 up up inet 172.20.105.1/24 up inet 172.20.205.1/24 up up up up up down up up down down up up up up inet 192.168.30.1 --> up inet 127.0.0.1 --> up inet 10.0.0.1 --> up up up inet 10.10.30.1/24






Part 2: Examining the IPsec Configuration and Troubleshooting IPsec VPNs

0/0 0/0 0/0

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; pre-shared-key ascii-text "$9$0VD91EyM87s2alK2aZU.m01R"; ## SECRET-DATA

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 { ike-policy policy-2; address 192.168.30.4; external-interface loO.O;


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 notify your instructor.

Step 2.2

Examine the existing IPsec - IKE phase 2 configuration on your SRX.

lab@srxC-1> show configuration security ipsec policy policy-sec {

proposal-set standard;

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;



Step 2.3

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,


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

243597 UP 308f83af84cll27d a774dl633604c29e Main

Remote Address

192.168.30.4

lab@srxC-1> show security ipsec security-associations

Total active tunnels: 1

ID Algorithm SPI Life:sec/kb

<131074 ESP:3des/shal al4a385d 3551/ unlim

>131074 ESP:3des/shal 2af8d64b 3551/ unlim

Mon vsys Port

root 500

root 500

Gateway

192.168.30.4

192.168.30.4

Lab 2-6 • Troubleshooting IPsec

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.

www.juniper.net

Step 2.5


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.

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



Step 2.6

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.

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

3 packets transmitted, 3 packets received, 0% packet loss 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 64 bytes from 192.168.30.4: icmp_seq=O ttl=63 time=2.385 ms 64 bytes from 192.168.30.4: icmp_seq=l ttl=63 time=2.075 ms 64 bytes from 192.168.30.4: icmp_seq=2 ttl=63 time=l.849 ms

--- 192.168.30.4 ping statistics ---3 packets transmitted, 3 packets received, 0% packet loss

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


www.juniper.net

Step 2.7


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.

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.

lab@sr:x:C-1> configure

Entering configuration mode

[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

Exitin9 configuration mode

lab@srxC-1>



Step 2.8

Review the /var/log/kmd file.

lab@srxC-1> show log kmd

Note

For the sake of clarity and time, the

interesting lines are balded in the output.

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 attributelist

Apr 3 05:39:52 <none>:500 (Responder) <-> 192.168.30.3:500 { bd59f524 50519ce6 - c9,:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Notify message version= 1

Apr 3 05:39:52 <none>:500 (Responder) <-> 192.168.30.3:500 { bd59f524 50519ce6 - c9,:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Error text = Could not findacceptable proposal

Apr 3 05:39:52 <none>:500 (Responder) <-> 192.168.30.3:500 { bd59f524 50519ce6 - c9ea459c dc26cd65 [OJ I Ox44b3e47a } Info; Offending message id=OxOOOOOOOO

Apr 3 05:39:52 <none>:500 (Responder) <-> 192.168.30.3:500 { bd59f524 50519ce6 - c9·:a459c dc26cd65 [OJ I Ox44b3e47a } Info; Received notify err = Noproposal 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)

Step 2.9

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.

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 Ju nos Ent erprise Security Tr oubleshooting

policy policy-1 { mode main; proposal-set basic; pre-shared-key ascii-text "$9$0VD91EyM87s2alK2aZU.m01R"; ## SECRET-DATA

} policy policy-2 {


} gateway spoke-1 {

}

ike-policy policy-1; address 192.168.30.3; external-interface loO.O;

gateway spoke-2 { ike-policy policy-2; address 192.168.30.4; external-interface loO.O;

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

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


[edit security ike] lab@srxC-1# commit and-quit commit complete Exiting configuration mode

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 243606 UP 76fc7377169db6a4 57fa23262fdb5db5 Main 243597 UP 308f83af84c1127d a774d1633604c29e Main

lab@srxC-1> show security ipsec security-associations Total active tunnels: 2 ID Algorithm SPI <131073 ESP:3des/shal d7b87066 >131073 ESP:3des/shal cd338cfd<131074 ESP:3des/shal al4a385d>131074 ESP:3des/shal 2af8d64b

www.jurniper.net

Life:sec/kb 3565/ unlim 3565/ unlim 3114/ unlim 3114/ unlim

Mon vsys root root root root

Port 500 500 500 500

Remote Address 192.168.30.3 192.168.30.4

Gateway 192.168.30.3 192.168.30.3 192.168.30.4 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 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

--- 192.171.30.3 ping statistics 3 packets transmitted, 0 packets received, 100% packet loss

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

PING 192.171.30.4 (192.171.30.4): 56 data bytes 64 bytes from 192.171.30.4: icmp_seq=O ttl=63 time=2.197 ms 64 bytes from 192.171.30.4: icmp_seq=l ttl=63 time=2.106 ms 64 bytes from 192.171.30.4: icmp_seq=2 ttl=63 time=l.857 ms


Step 3.2



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


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

www.juniper.net

*[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.

lab@srxC-1> configure


[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

Step 3.5

* [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.

Check the connectivity to spoke-2

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

PING 192.171.30.4 (192.171.30.4): 56 data bytes



--- 192.171.30.4 ping statistics

3 packets transmitted, O packets received, 100% packet loss

Step 3.6

Question: Are you able to reach spoke-2?

Answer: No, as shown in the output, you are not

able to reach spoke2.

View the next-hop tunnel binding table.

lab@sr:x:C-1> show

Next-hop gateway

10.10.30.3

10.10.30.4

Step 3.7

security ipsec next-hop-tunnels

interface IPSec VPN name

stO.O srxC-1-to-spoke-l

sto.o srxC-1-to-spoke-2

Question: Is the next-hop tunnel binding table

populated with correct entries?

Flag

Auto

Auto

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 (Ju nos security device or ScreenOS device)

because only Juniper devices exchange this

message. For other devices manual NHTB entry

must be created.

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



Step 3.8

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.

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


host-inbound-traffic { system-services {

all;

protocols all;

security-zone Juniper-SV { host-inbound-traffic {


protocols all;


security-zone ACME-SV {



host-inbound-traffic { system-services {

all;

protocols all;


security-zone untrust { host-inbound-traffic {


protocols all;

interfaces ge-0/0/3.0; loO.O;

security-zone vpn interfaces {

stO.O;

[edit s:ecurity zones] lab@srxC-1# commit and-quit commit complete Exitin9 configuration mode

lab@srxC-1>

Step3.9

Verify the tunnel interface stO.O is assigned to the correct zone.

lab@srxC-1> show interfaces stO.O statistics 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 Protocol inet, MTU: 9192

Flags: Sendbcast-pkt-to-re .ll.,ddresses, Flags: Is-Preferred Is-Primary




Step 3.10

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.

Test the reachability to spoke-1 and spoke-2 IP addresses again.

lab@srxC-1> ping spoke-1-address count 3 PING 192.171.30.3 (192.171.30.3): 56 data bytes 64 bytes from 192.171.30.3: icmp_seq=O ttl=64 time=2.723 ms

64 bytes from 192.171.30.3: icmp_seq=l ttl=64 time=2.325 ms 64 bytes from 192.171.30.3: icmp seq=2 ttl=64 time=2.611 ms

--- 192.171.30.3 ping statistics ---3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.325/2.553/2.723/0.168 ms

lab@srxC-1> ping spoke-2-address count 3 PING 192.171.30.4 (192.171.30.4): 56 data bytes 64 bytes from 192.171.30.4: icmp_seq=O ttl=64 time=3.178 ms 64 bytes from 192.171.30.4: icmp_seq=l ttl=64 time=2.306 ms 64 bytes from 192.171.30.4: icmp_seq=2 ttl=64 time=2.180 ms


Step3.11


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

both ping are now successful. If you experience

different behavior notify your instructor.

Examine the tunnel interface stO.O.

lab@srxC-1> show interfaces stO.O statistics Logical interface stO. 0 (Index 70) (SNMP if Index 596)

Flags: No-Multicast SNMP-Traps Encapsulation: Secure-Tunnel

Input packets : 6

Output packets: 15 Security: Zone: vpn

Protocol inet, MTU: 9192



Flags: Sendbcast-pkt-to-re

Addresses, Flags: Is-Preferred Is-Primary


Step3.12

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.

Log out using the exit command.

lab@srxC-1> exit

srxC-1 (ttyuO)

login:





I srxA-1

I: srxA-2

srx.lH I

1:::SO<C-

2

A? Ea' Workstations


srx0-1

srx0-2

Server

Gateway

Term Server ___ __

Server Note: Your instructor will provide address and access information.

Pod A Network Diagram:


srxA-1

stO: 10.10.10.1/24 loO: 192.168.10.1


Spoke 1 A-1 stO: 10.10.10.3/24

loO: 192.168.10.3

Spoke 1A-2 stO: 10.10.10.6/24 loO: 192.168.10.6

Spoke2A-2 stO: 10.1010.7/24 loO: 192.168.10. 7

srxA-2

stO: 10.10.10.2/24 loO: 192.168.10.2

Unlpe Woddwld& 1:,t",;;;ij�� Services www,um""' "" "'k,� �--

www.juniper.net


Pod B Network Diagram:


Spoke 1 B-1 stO: 10.10.20.3/24

loO: 192.168.20.3

Pod C Network Diagram:

Spoke 1 B-2 O: 10.10.20.6/24 O: 192.168.20.6


srxC-1

stO: 10.10.30.1/24 loO: 192.168.30.1



Pod D Network Diagram:


Spoke 1 D-1 stO: 10.10.40.3/24

loO: 192.168.40.3

Spoke2 D-1 stO: 10.10.40.4/24 loO: 192.168.40.4

srxD-1 stO: 10.10.40.1/24 loO: 192.168.40.1


Spoke 1 D-2 stO 10.10.40.6/24 loO: 192.168.40.6

.Z;,< e,,·.ze.<o -o_,,o_,,.(.Jo

r.,,;�---s-rx_D-_2 _ _..., stO: 10.10.402/24 loO: 192.168.40.2

www.juniper.net

Overview

Lab

Troubleshooting Security Features

In this lab, you will troubleshoot security features - AppSecure and UTM. You will use

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



Step 1.1

Step 1.2



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.

Ensure that you know to which device you are assigned. Check with your instructor if

necessary. Consult the Management Network Diagram to determine the









Access the command-line interface (CU) at your station using either the console,


Lab 3-2 • Troubleshooting Security Features www.juniper.net

Step 1.3

srxC-1 (ttypO)

login: lab

Password:

D S ho1N quick connect on startup


B Save session

0 Open in a tab

Connect Cancel

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 configuration when complete.

--- JUNOS 12.1R5.5 built 2013-01-17 06:12:00 UTC lab@sr:x:C-1> configure Entering configuration mode

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

load complete

lab@sr:x:C-1# commit and-quit commit complete Exiting configuration mode

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

ge-0/0/4

ge-0/0/4.105

ge-0/0/4.205

ge-0/0/4.32767

ge-0/0/5

ge-0/0/6

ge-0/0/7

ge-0/0/8

ge-0/0/9

ge-0/0/10

ge-0/0/11

ge-0/0/12

ge-0/0/13

ge-0/0/14

ge-0/0/15

loo

loo.a

lo0.16384

lo0.16385

lo0.32768

Step 1.5

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up

up inet 172.18.1.2/30

up

up inet 172.20.105.1/24

up inet 172.20.205.1/24

up

up

up

up

up

down

up

up

down

down

up

up

up

up inet 192.168.1.1 -->

up inet 127.0.0.1 -->

up inet 10.0.0.1 -->

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.

0/0

0/0

0/0

Open a separate Telnet session to the virtual router attached to your team device.


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

Troubleshooting Security Features • Lab 3-5

Adva nced Ju nos Enterprise Security Troubleshooting

vr-device (ttypO)

login: username

Password:


NOTE: This router is divided into many virtual routers used by different teams. Please only configure your own virtual 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







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=26.430 ms 64 bytes from 172.20.105.1: icmp_seq=l ttl=64 time=4.473 ms 64 bytes from 172.20.105.1: icmp_seq=2 ttl=64 time=3.343 ms

--- 172.20.105.1 ping statistics ---3 packets transmitted, 3 packets received, 0% packet loss 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 64 bytes from 172.20.205.1: icmp_seq=O ttl=64 time=3.405 ms 64 bytes from 172.20.205.1: icmp_seq=l ttl=64 time=3.367 ms 64 bytes from 172.20.205.1: icmp_seq=2 ttl=64 time=5.167 ms


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


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

Step 2.1

In this lab part, you will examine and troubleshoot UTM to determine the reason of

experienced traffic processing.

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 a jest 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.



Step 2.3

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.


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

Step 2.4

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.

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

Step 2.5

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.

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

Policy Type: Configured

Sequence number: 1

From zone: Juniper-SV, To zone: ACME-SV

Source addresses:

any-ipv4(global): 0.0.0.0/0

any-ipv6(global): : :/0

Destination addresses:

any-ipv4(global): 0.0.0.0/0



any-ipv6(global): : :/0

Application: any

IP protocol: 0, ALG: 0, Inactivity timeout: 0

Source port range: [ O -OJ

Destination port range: [0-0]


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

Step 2.7

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.

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;



Step 2.8

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.

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;

Step 2.9

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.

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:

Total allocated sessions:

Total freed sessions:

Active sessions:

Step 2.1'.L

4000

2

1

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.

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



Step 2.12

ftp> bye 221 Goodbye.

cl@vr-device>

Step 2.13

Question: Did any of the options listed above block

traffic?

Answer: As shown in the output, the extension list

was used to block traffic.


From your assigned virtual router, close the ftp connection.


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/ 50704->172.20.205.1/21 None None 6 app-service-policy Juniper-SV ACME-SV 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 App Track about the

session.

Part 3: Examining and Troubleshooting AppSecure features

Step 3.1.

In this lab part, you will examine and troubleshoot application identification and

application firewall to determine the reason of experienced traffic processing.


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

[email protected]'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

Out: 172.20.205.1/22 --> 172.20.105.10/50554;tcp, If: .local .. 0, Pkts: 9,

Bytes: 2005

Total sessions: 1



Step 3.3

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.

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 Policy name: app-service-policy/9 Source NAT pool: Null, Application: junos-ssh/22 Dynamic application: junos:SSH, Application firewall rule-set: Allowed-services, Rule: ssh Maximum timeout: 1800, Current timeout: 1744 Session State: Valid Start time: 10954, Duration: 56

In: 172.20.105.10/50554 --> 172.20.205.l/22;tcp, Interface: ge-0/0/4.105, Session token: Ox9, Flag: Ox621 Route: OxaOOlO, Gateway: 172.20.105.10, Tunnel: O Port sequence: 0, FIN sequence: 0, FIN state: o, Pkts: 10, Bytes: 2001

Out: 172.20.205.1/22 --> 172.20.105.10/50554;tcp, Interface: .local .. 0, Session token: Ox2, Flag: Ox630 Route: Oxfffb0006, Gateway: 172.20.205.1, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: o, Pkts: 9, Bytes: 2005

Total sessions: 1


Adva nced Ju nos Enterprise Security Troubleshooti ng


Step 3.4

Answer: As shown in the output, the dynamic application a result from application identification is junos:SSH.

Question: What is the name of the application firewall rule-set and rule handling this session?


firewall rule-set is Allowed-service and rule is ssh.


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 12:32AM up 3:04, 4 users, load averages: 0.13, 0.16, 0.15 USER TTY FROM LOGIN@ IDLE lab uO Fri09PM 22 lab pO 10.210.14.158 FrilOPM -

lab pl 10.210.14.158 FrilOPM -

lab p2 172.20.105.10 12: 31AM -

lab@srxC-1> exit

Connection to 172.20.205.1 closed.

Step 3.5

WHAT -cli (cli)-cli (cli)telnet 172.20.-cli (cli)


From your assigned SRX device, view the last 10 lines of the RF-FLOW log file.

lab@srxC-1> show log RT-FLOW I last 10 Apr 6 00:31:38 srxC-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:

172.20.105.10/52965->172.20.205.1/22 junos-ssh 172.20.105.10/ 52965->172.20.205.1/22 None None 6 app-service-policy Juniper-SV ACME-SV 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 172.20.105.10/52965->172.20.205.l/22 None None 6 app-service-policy Juniper-SV ACME-SV 1663 14(2353) 13(2293) 8 N/A N/A N/A

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

Apr 6 00:32:22 srxC-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN: 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 172.20.105.10/50554->172.20.205.l/22 None None 6 app-service-policy Juniper-SV ACME-SV 1668 65(6669) 55(7565) 40 N/A N/A N/A

Step 3.6


related your SSH session?



the ssh connection. In addition it contains also

App Track session close message.

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

Logical system name: O IP address: 172.20.205.1 Application: FTP

Lab 3-18 • Troubleshooting Security Features

Port: 22 Protocol: TCP Encrypted: No

Port: 21 Protocol: TCP Encrypted: No

www.juniper.net

Step 3.7


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.


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

Out: 172.20.205.1/23 --> 172.20.105.10/50447;tcp, If: .local .. 0, Pkts: 23,

Bytes: 1446

Total sessions: 1



Step 3.9

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.

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

Policy name: app-service-policy/9

Source NAT pool: Null, Application: junos-telnet/10

Dynamic application: PENDING,

Application firewall rule-set: Allowed-services, Rule: PENDING

Maximum timeout: 1800, Current timeout: 1764

Session State: Valid

Start time: 11228, Duration: 40

In: 172.20.105.10/50447 --> 172.20.205.l/23;tcp,

Interface: ge-0/0/4.105,


Route: OxaOOlO, Gateway: 172.20.105.10, Tunnel: O


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


Step 3.10



Answer: As shown in the output, the dynamic

application a result from application identification is

PENDING. This means the application identification

has not yet come to final result for identifying the

application.

Question: What is the name of the application

firewall rule-set and rule handling this session?


firewall rule-set is Allowed-service and rule is

PENDING.

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 Number of sessions matched: 1

Default rule:deny Number of sessions matched: O

Number of sessions with appid pending: 1

Question: Is there currently any session without

identified application?

www.juniper.net

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 12:39AM up 3:11, 5 users, load averages: 0.11, 0.12, 0.12

lab@srxC-1> show

Step 3.12

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.

Terminate the stuck telnet session by hitting the CTRL+] key combination and

entering the quit command.

telnet> quit Connection closed.

cl@vr-device>

Step 3.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 Number of sessions matched: 1

Rule: ssh Dynamic Applications: junos:SSH Action:permit Number of sessions matched: 1

Default rule:deny Number of sessions matched: 1

Number of sessions with appid pending: O


Step 3.14


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.

View the last 15 lines of the RF-FLOW log file.

lab@srxC-1> show log RT-FLOW I last 15 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/ 50447->172.20.205.1/23 None None 6 app-service-policy Juniper-SV ACME-SV 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 172.20.105.10/50447->172.20.205.l/23 None None 6 app-service-policy Juniper-SV ACME-SV 1746 31(1777) 23(1446) 60 N/A N/A N/A

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



Step 3.15


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.

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)

_,.....,,.... srxA-1� •...... ·.·.·.-·.···., ®:J .I· ----

. - Serial Console Terminal \ :\ '- Connections srxA-2

Management Netwml<

� Server \ '-'

, , '-, &c:1111: Workstations

\' '\ '\ '�

\ '\ 'iI, \ '- srxD-2

\ '\

\

\D Server

r�:----1�2 ' sncB-1

I S<XB-2 I =1


----�-"""i srxD-1

srxD-2

vr-device

Server

Gateway

Tenn Server

Note: Your instructor will provide address and access information.

�tio� Services WWW Jumper.net



Hostname VLAN·ID

srxA-1 101, 201

srxA-2 102, 202

www.juniper.net

(=:):-� 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

V0/4_203 -- ___.., ge-0/0/4-�lJ 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 ACME-WF



Host name VLAN-10

srxC-1 105, 205

srxC-2 106, 206 --iEJ

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

..._Virtual Routers --

(.10) (.10)

Juniper-WF

Lab 3-26 • Troubleshooting Security Features www.juniper_net




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


Overview

Lab

Troubleshooting Chassis Clustering

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

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



Step 1.1

Step 1.2



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.

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.








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

Step 1.3


-�·

Q!!j'l£,��01,,&;-, , ,,pg{ ,,', i 'pg•, cillm'0 ,wAlHJ�

Protocol:

Hostname:

Port:

D Show quick connect on star tup 0 Save se ssion

0 Open in a tab

Connect.·� l�_C_an_c_el�


the lab4-start. configfrom the /var/home/lab/ajest/ directory. Commit the


srxC-1 (ttypO)

login: lab

Password:

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

lab@srxC-1> configure


[edit]

lab@srxC-1# load override ajest/lab4-start.config

load complete


commit complete

Exitin9 configuration mode

lab@srxC-1>



Part 2: Forming and Troubleshooting a Chassis Cluster

Step 2.1

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.

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:


--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC {hold:nodeO} lab@srxC-1>

Step 2.4

{hold:nodeO}

Question: What state of the node does the CLI indicate?

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

the hold state.

Check the chassis cluster status using the show chassis cluster status

command.

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

lost no n/a

no n/a nodel

{hold:nodeO} lab@srxC-1>

Step 2.5

{hold:nodeO}

0

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.

View the chassis cluster statistics using the show chassis cluster

statisticsand s how chassis cluster control-plane statistics

command.

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

Control link 0: Heartbeat packets sent: 0 Heartbeat packets received: O Heartbeat packet errors: 0


Probes sent: 0 Probes received: O

Child link 1 Probes sent: 0 Probes received: 0


Step 2.6

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 receivenor is it able to send any heartbeats or probes. The

next step would be check the control and data link

status.

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 0

Interface fxpl

Fabric link status: Down

Fabric interfaces: Name Child-interface

fabO fabO


Step 2.7

Status Down

Status (Physical/Monitored)

Question: What is the state of the control and fabric

link?

Answer: As indicated by the output, both links are

Down.

Check all the fxp interfaces status.

{hold:nodeO} lab@srxC-1> fxpO fxpl fxp2


www.juniper.net

show interfaces up up up

terse I match fxp up up up

Question: What is the state of the fxp interfaces?

Answer: As indicated by the output, all the fxp

interfaces are up.

Troubleshooting Chassis Clustering • Lab 4- 7


Step 2.8

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.

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

Step 2.9

Question: What does the command output display?

Answer: As indicated by the output, an error about connectivity problem to node O is displayed.

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 2 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 Apr 5 18:08:37 Apr 5 18:08:37 Apr 5 18:08:37 Apr 5 18:08:37

printing fpc_num

printing fpc_num e

printing fpc_num d

printing fpc_num n

IP Monitoring infrastructure initialized Apr 5

Apr 5

18:08:37 18:08:37

Control interface is not present yet, retry later 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 0

O ifstate download

Apr Apr Apr Apr Apr Apr Apr Apr Apr Apr Apr

Apr Apr

Apr

Apr

Apr

5

5

5

5

5

5

5

5

5

5

5

5

5

5

5

5

18:08:37 18:08:37 18:08:37 18:08:37 18:08:37 18:08:37 18:08:37 18:08:37 18:08:37 18:08:37

18:08:37 18:08:37

18:08:37 18:08:37

18:08:37 18:08:37

fabric monitoring is enabled hardware monitoring is enabled RG-0 failover for HW errors is enabled Failover for loopback error is disabled Failover for fabric nexthop error is disabled Failover for mbuf error is disabled Unable to read data-plane mode for cluster O from ssam, error 2 data plane mode is active-active

fwdd monitoring is enabled fabric time out is set to O control link recovery is disabled

Reading redundancy-group config reading the RG entries config

deleting all RGs

reading the RG entries config

creating RGO

5 18:08:37 Apr unable to set priority, for RG-0, fsm context uninitialized 5 18:08:37 Apr 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 printing fpc_num 1 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

Step 2.10

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.

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



Step 2.1: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.

Remove the ge-0/0/0 configuration. Commit and exit to the operational mode when

complete.

{hold:nodeo} lab@srxC-1> configure 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 Entering configuration mode The configuration has been changed but not committed

{hold:nodeo} [edit] lab@srxC-1# delete interfaces ge-0/0/0

{hold:nodeO} [edit] lab@srxC-1# commit and-quit [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] lab@srxC-1# commit and-quit nodeO:



commit complete Exiting configuration mode


Step 2.12

{primary:nodeO}

Reboot the node.

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

System going down IMMEDIATELY

Part 3: Monitoring a Chassis Cluster

In this lab part, you will monitor the chassis cluster status using the CLI tools.

Step 3.1

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.

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:

--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC {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?

Step 3.3

{primary:nodeO}

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.

View the chassis cluster status.

lab@sr:x:C-1> show chassis cluster status Cluster ID: 1 Node Priority

Redundancy group: O , Failover count: 1 nod.ea 1 nod.el

{primary:nodeO} lab@sr:x:C-1>

1

Status

primary secondary

Preempt

no no

Manual failover

no no

Question: What are the states of the cluster nodes?

www.juniper.net

Answer: As indicated by the output from srxC-1, nodeO is primary and node 1 is secondary.

Troubleshooting Chassis Clustering • Lab 4-13


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

Control link 0: Heartbeat packets sent: 69 Heartbeat packets received: 105 Heartbeat packet errors: O


Probes sent: 0 Probes received: O

Child link 1 Probes sent: O Probes received: O

{primary:nodeO} lab@srxC-1>

Step 3.5

Question: Are any of the counters increased?

Answer: As indicated by the output, the both - sent and received - control link heartbeat counters have increased.

Check the fabric interfaces status using the show interfaces terse I match fab command.

{primary:nodeO} lab@srxC-1> show interfaces terse I match fab fabO up down fabO. 0 fabl fabl.O swfabO

swfabl

up up up up

up

down inet down down inet down

down

30.17.0.200/24

30.18.0.200/24

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.


Step 3.6


Question: Can you think of any reason why is the

fabric interface status down?

Answer: The fabric interface have not been yet

configured.

Check the cluster interfaces status using the show chassis cluster

interfaces command.

{primary:nodeO} lab@srxC-1> show chassis cluster interfaces Control link status: Up

Control interfaces: Index Interface O fxpl

Fabric link status: Down


fabO fabO fabl fabl

Step 3.7

Status Up

Status (Physical/Monitored)

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.

Enter configuration mode and load the lab6-p3s8. configfrom the /var I

home/lab/aj est/ directory. Commit the configuration when complete.

{primary:nodeO} lab@srxC-1> configure warning: Clustering enabled; using private edit warning: uncommitted changes will be discarded on exit Entering configuration mode



{primary:nodeO} [edit] lab@srxC-1# load override ajest/lab6-p3s8.config

load complete

{primary:nodeO} [edit] lab@srxC-1# commit and-quit nodeO: configuration check succeeds nodel: commit complete nodeO: commit complete Exiting configuration mode


Step 3.8

View the control and fabric interfaces status using the show interfaces terse I match "fxp I fab" command.

{primary:nodeO} lab@srxC-1> show interfaces terse I match "fxplfab" ge-0/0/2.0 ge-5/0/2.0 fabO fabO.O fabl fabl.O fxpO fxpO.O fxpl fxpl.O fxp2 fxp2.0 swfabO swfabl

Step 3.9

up up up up up up up up up up up up up up

up aenet --> fabO.O up aenet --> fabl.O up up inet 30.17.0.200/24 up up inet 30.18.0.200/24 up up inet 10.210.34.135/26 up up inet 129.16.0.1/2 up up tnp OxllOOOOl down 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.

Display the cluster status using the show chassis cluster status command.



{primary:nodeo} lab@srxC-1> show chassis cluster status Cluster ID: 1 Node Priority Status Preempt Manual failover

Redundancy group: 0 nodeO nodel




Step 3.10

Failover count: 1 1 primary no 254 secondary no

Failover count: 1 200 primary no 100 secondary no

Failover count: 0 100 secondary yes 200 primary yes

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.

no no

no no

no no

View the chassis cluster interfaces using the show chassis cluster

interfaces command.

{primary:nodeO} lab@srxC-1> show chassis cluster interfaces Control link status: Up

Control interfaces: Ind.ex 0

Interface fxpl

Fabric link status: Up

www.juniper.net

Status Up




fabO ge-0/0/2 fabO fabl fabl

ge-5/0/2

Status (Physical/Monitored) Up I Up

Up I Up

Redundant-ethernet Information: Name Status Redundancy-group rethO Up 1 rethl Up 2

Interface Monitoring: Interface ge-5/0/3

{primary:nodeo} lab@srxC-1>

Weight 255

Status Up

Redundancy-group 2

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.


Step 3.1:1


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.

Display detailed 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 Apr

5 18:30:07.031 5 18:30:33.069

hold->secondary, reason: Hold timer expired secondary->primary, reason: Better priority (1/1)


100)

Apr 5 18:46:07.163 Apr 5 18:46:07.190

hold->secondary, reason: Hold timer expired secondary->primary, reason: Better priority (200/


Apr 5 18:46:07.167 : hold->secondary, reason: Hold timer expired

nodel:

Redundancy mode: Configured mode: active-active Operational mode: active-active









Apr 5 18:41:17.405 : secondary->primary, reason: Better priority (200/ 100)


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 *** System going down IMMEDIATELY

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:

--- JUNOS 12.lRS.5 built 2013-01-17 06:12:00 UTC lab> co:nfigure

Enterin3 configuration mode

[edit] lab# load override ajest/labl-start.config

load complete

[edit] 1 ab# co,[llll\i t 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)

.,.... .,.... .,.... .,....

srxA-1�

anagement

fi2ir2:i_c:1· -

e Networn �Lr •c•••· ---- � �

• Serial Console Terminal\:"\, Connections srxA-2 . Student Server \

� �,' .

�

I 'C

_J-m::D] Workstations

\ \. ' \ \ \. \. '®' Management Addressing

\ \. srxD-2 srx,H srxD-1

\ \.Cl ::: � \ vr-device srxB-2 Server

\

'{] srxC-1 Gateway

srxG-2 Term Server -----

Server Note: Your instructor will provide address and access information



rethO Network

172.20.10.0/24 VIAN 221

Lab 4-22 • Troubleshooting Chassis Clustering

Untrust Zone

Cluster-ID 1 fxp1

reth1 Network

172.30.10.0/24 VLAN231

www.juniper.net




rethO Network

17220.20.0/24 VLAN222

vr222

Untrust Zone

Cluster-ID 1

fxpl

Trust Zone

vr232

rethl Network

172.30.20.0/24 VLAN232



rethO Network

17220.30.0/24

VLAN223

www.juniper.net

Untrust Zone

Cluster-ID 1

fxpl

Tr ust Zone rethl Network

172.30.30.0/24

VLAN233

,_ ��i1- � <>,:»i-

LllJnm Worldwide. fducalion Services WWW.jUrupe<nel "'�""- �-





rethO Network

172_20-40_0/24

VLAN 224

Lab 4-24 • Troubleshooting Chassis Clustering

Untrust Zone

Cluster-ID 1

lxpl

rethl Network

172_30_40_0/24

VLAN234

www.juniper.net

jljn1per - 1 file download

Documents