Bản Sao Của Ajsec-lg

Juniper University
juniper
MCT\A/nDlZC
NETWORKS Education Services
Advanced Juniper Security
LAB GUIDE Revision V20A
3
J
A
3
Engineering
Simplicity
Juniper University Education Services Courseware

V20A
Lab Guide
Juniper University
jumper NETWORKS
MirT\A//^Diy e Education Services
1133 Innovation Way
Sunnyvale, CA 94089 USA
408-745-2000
wvvw.juniper.net
Course Number: AJSEC

This document is produced by Juniper Networks, Inc.
This documentor any partthereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education
Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The
Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
marks are the property of their respective owners.
Advanced Juniper Security Student GuideLab GuideLab Diagrams, Revision V20A
Copyright © 2020 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision lO.a—March 2011
Revision 12.a—June 2012
Revision 12.b—June 2013
Revision V-15.a—November 2016
Revision V-15.b—June 2017
Revision V20A—July 2020
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 Junos OS Release20.1Rl.ll, Junos Space Security Director 19.4, and Juniper
ATP On-Prem version 5.0.7. 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 defector omission in this document, even if advised of the possibility of such
damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
Contents
Lab 1: Implementing Layer 2 Security 1-1
Part 1: Loading the Baseline Configuration .1-2
Part 2: Configuring Transparent Mode ... . 1-4
Part 3: Configuring In-Band Management 1-17
Part 4: Configuring Secure Wire .............. 1-24
Lab 2: Firewall Filters................................................. 2-1

Part 1: Preparing the System and Verifying Proper Operation . 2-2
Part 2: Configuring and Monitoring Firewall Filters .............. . 2-7
Parts: Configuring Internet Access....................................... 2-21
Part 4: Configuring Inter-VR Communication ........................ 2-26
Part 5: Configuring Filter-Based Forwarding.......................... 2-39
Lab 3: Troubleshooting Security Zones and Policies 3-1

Part 1: Accessing Your Device and Verifying Connectivity........ .3-2
Part 2: Troubleshooting Zones................................................... . 3-5
Part 3: Troubleshooting Security Policies................................. . 3-9
Part 4: Troubleshooting Local Host Traffic............................... 3-18
Lab 4: Hub-and-Spoke VPNs ............................... 4-1

Part 1: Inspecting Existing VPN Configuration ................ .4-2
Part 2: Configuring the Hub Device................................. . 4-4
Part 3: Configuring the Spoke Devices ........................... 4-12
Part 4: Verifying and Monitoring the Hub-and-Spoke VPN 4-18
Lab 5: Advanced NAT...................................................................... 5-1

Part 1: Loading the Baseline Configuration ................................................... . 5-2
Part 2: Configuring Pool-based Destination NAT with Port Forwarding.......... . 5-6
Part 3: Configuring NAT for a Local Routed and Local Switched Environment 5-11
Part 4: Implementing IPv6 NAT—NAT46 ......................................................... 5-20
Part 5: Implementing IPv6 NAT—NAT64 ......................................................... 5-24
Lab 6: Implementing Tenant Systems 6-1

Part 1: Loading Start Configurations........ .6-2
Part 2: Master Administrator Tasks.......... . 6-3
Part 3: Tenant Administrator Tasks.......... 6-11
Lab 7: PKIandADVPNs ........................... 7-1

Part 1: Configuring PKI Settings ...................... .7-2
Part 2: Configuring the ADVPN.......................... 7-14
Part 3: Configuring Tunnel Routing Parameters 7-19
Lab 8: Implementing Advanced IPsec VPN Solutions 8-1

Part 1: Loading the Baseline Configuration .............................. .8-2
Part 2: Configuring the Site-to-Site IPsec VPN .......................... . 8-5
Part 3: Configuring the GRE Tunnel over the IPsec VPN .......... 8-10
Part 4: Configuring OSPF over the GRE Tunnel ........................ 8-12
Part 5: Working with Overlapping Address Space .................... 8-15
www.juniper.net Contents • Lab 1-iii

Lab 9: Troubleshooting IPsec...................................... 9-1
Part 1; Examining Log Messages............................................. . 9-2
Part 2: Troubleshooting an IPsec VPN..................................... . 9-4
Part 3: Troubleshooting Connectivity Problems for IPsec VPNs 9-20
Lab 10:Seclntel ................................................... 10-1

Part 1; Setting up the Environment............................. .10-2
Part 2: Creating a Policy using the Office 365 Feed ... .10-7
Part 3: Creating a Firewall Policy using a Custom Feed 10-25
Part 4; Cleaning Up....................................................... 10-36
Lab 11: Juniper ATP On-Prem............. 11-1

Part 1; Connect to Devices...................... .11-2
Part 2: Juniper ATP On-Prem Setup........ . 11-5
Part 3: Testing the Web Collector—HTTP . 11-13
Part 4; Testing the Web Collector—Samba 11-19
Part 5: Testing the SSH Honeypot.......... 11-22
Lab 12: Juniper Connected Security—Automated Threat Remediation 12-1

Part 1; Setting up the Environment............................................................................... .12-2
Part 2: Configure the Secure Fabric ............................................................................. .12-8
Part 3: Creating Security Policies................................................................................... 12-16
Part 4; Simulating an Infected Host ............................................................................. 12-24
Part 5: Simulating C&C Server Communication........................................................... 12-27
Part 6: Cleaning Up........................................................................................................ 12-36
Lab 1-iv • www.juniper.net

Course Overview
This four-day course, designed to build off the current Juniper Security (JSEC) offering, delves deeper into Junos security,
next-generation security features, and ATP supporting software.
Through demonstrationsand hands-on labs, you will gain experience in configuring and monitoring the advanced Junos
OS security features with coverage of advanced logging and reporting, next-generation Layer 2 security, next-generation
advanced anti-malware with Juniper ATP On-Prem and SecIntel. This course uses Juniper Networks SRX Series Services
Gateways for the hands-on component. This course uses on Junos OS Release 20.lRl.il, Junos Space Security Director
19.4, and Juniper ATP On-Prem version 5.0.7.
Course Level
AdvancedJuniper Security (AJSEC) is an advanced-level course.
Intended Audience
This course benefits individuals responsible for implementing, monitoring, and troubleshooting Junos security
components.
Prerequisites
Students should have a strong level of TCP/IP networking and security knowledge. Students should also attend the
Introduction to Juniper Security (IJSEC) and Juniper Security (JSEC) courses before attending this class.
Objectives
After successfully completing this course, you should be able to:
Demonstrate understanding of concepts covered in the prerequisite Juniper Security courses.
Describe the various forms of security supported by the Junos OS.
Describe the Juniper Connected Security model.
Describe Junos security handling at Layer 2 versus Layer 3.
Implement next-generation Layer 2 security features.
Demonstrate understanding of Logical Systems (LSYS).
Demonstrate understanding of Tenant Systems (TSYS).
Implement virtual routing instances in a security setting.
Describe and configure route sharing between routing instances using logical tunnel interfaces.
Describe and discuss Juniper ATP and its function in the network.
Describe and implement Juniper Connected Security with Policy Enforcer in a network.
Describe firewall filters use on a security device.
Implement firewall filters to route traffic.
Explain how to troubleshoot zone problems.
Describe the tools available to troubleshoot SRX Series devices.
Describe and implement IPsec VPN in a hub-and-spoke model.
Describe the PKI infrastructure.
Implement certificates to build an ADVPN network.
Describe using NAT, CoS, and routing protocols over IPsec VPNs.
Implement NAT and routing protocols over an IPsec VPN.
Describe the logs and troubleshooting methodologies to fix IPsec VPNs.
Implement working IPsec VPNs when given incorrect configurations.
Describe Incident Reporting with Juniper ATP On-Prem device.
www.juniper.net Course Overview • v

Configure mitigation response to prevent lateral spread of malware.
Explain SecIntel uses and when to use them.
Describe the systems that work with SecIntel.
Describe and implement advanced NAT options on the SRX Series devices.
Explain DNS doctoring and when to use it.
Describe NAT troubleshooting logs and techniques.
vi • Course Overview www.juniper.net

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Junos Layer 2 Packet Handling and Security Features
Lab 1: Implementing Layer 2 Security
Chapter 3: Firewall Filters
Lab 2: Implementing Firewall Filters
Chapter 4: Troubleshooting Zones and Policies
Lab 3: Troubleshooting Zones and Policies
Day 2
Chapter 5: Hub-and-Spoke VPN
Lab 4: Implementing Hub-and-Spoke VPNs
Chapter 6: Advanced NAT
Lab 5: Implementing Advanced NAT Features
Chapter 7: Logical and Tenant Systems
Lab 6: Implementing TSYS
Day 3
Chapter 8: PKI and ADVPNs
Lab 7: Implementing ADVPNs
Chapter 9: Advanced IPsec
Lab 8: Implementing Advanced IPsec Solutions
Chapter 10: Troubleshooting IPsec
Lab 9: Troubleshooting IPsec
Day 4
Chapter 11: Juniper Connected Security
Chapter 12: SecIntel
Lab 10: Implementing SecIntel
Chapter 13: Advanced Juniper ATP On-Prem
Lab 11: Implementing Advanced ATP On-Prem
Chapter 14: Automated Threat Mitigation
Lab 12: Identifying and Mitigation of Threats
Appendix A: Group VPNs
www.juniper.net Course Agenda • vii

Document Conventions
CLI and GUI Text

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

commit complete
Screen captures
Noncommand-related syntax Exiting configuration mode
GUI text elements:
Menu names Select File Open, and then click
Configuration. conf in the Filename text
• Text field entry
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.
Normal CLI No distinguishing variant. Physical interface:fxpO, Enabled

Normal GUI View configuration history by clicking
Configuration History.
CLI Input Text that you must enter. labQSan Jose show route
GUI Input Select File Save, and type config. ini

in the Filename field.
Undefined Syntax Variables

Finally, this course distinguishes syntax variables, where you must assign the value (undefined variables). Note that
these styles can be combined with the input style as well.
CLI Undefined Text where the variable’s value is the user’s Type set policy policy-name.
discretion or text where the variable’s value
GUI Undefined ping 10.0 . jc.
as shown in the lab guide might differ from
the value the user must input according to Select File Save, and type filename
the lab topology. in the Filename field.
viii • Document Conventions www.juniper.net

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

This course was developed and tested using the software release listed on the copyright page. Previous and later
versions of software might behave differently so you should always consult the documentation and release notes for the
version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.net/techpubs/.
Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net Additional Information • ix

X • Additional Information www.juniper.net
Lab
Implementing Layer 2 Security
Overview
In this lab, you will implement Layer 2 security. You will work with the vSRX-1 to configure transparent
mode operations. You will also configure Layer 2 security, and verify the results.
By completing this lab, you will perform the following tasks:
• Implement transparent mode.
Implement secure wire.
Secure Layer 2 traffic.
www.juniper.net Implementing Layer 2 Security • Lab 1-1

Part 1: Loading the Baseline Configuration

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. Then, you will
load the starting configuration for Lab 1. Next, you will run a ping command from the Juniper-SV device to
ensure connectivity.
Note
Depending on the class, the lab equipment used might be
remote from your physical location. The instructor will inform
you as to the nature of your access and will provide you the
details needed to access your assigned device.
Step 1.1
Consult the Management Network Diagram to determine the management addresses of your devices.
Question: What are the management addresses assigned to your

devices?
Answer: The answer varies. The sample hostname and IP address

used in the output examples in this lab are for vSRX-1, which uses
172.25.11.1 as its management IP address. The actual management
subnet might vary between delivery environments.
Step 1.2
Access the CLI of vSRX-1 using either the console or SSH as directed by your instructor. Refer to
the management network diagram for the IP address associated with vSRX-1.
Step 1.3
Log in to the vSRX-1 device with the username lab and a password of labl23. Note that both the name
and password are case-sensitive. Enter configuration mode and load the reset configuration file using the
load override ajsec/labl-start. configcommand. After the configuration has been loaded
commit the changes before proceeding.
vSRX-1 (ttyuO)
login: lab
Password:
-- JUNOS 20.lRl.il Kernel 64-bit XEN JNPR-11.0-20200219.fbl20e7_buil

lab@vSRX-l> configure
Entering configuration mode
[edit]
lab@vSRX-l# load override ajsec/labl-start.config
[edit]
lab@vSRX-l# commit
commit complete
Lab 1-2 • Implementing Layer 2 Security www.juniper.net

[edit]
lab@vSRX-l#
Step 1.4
Open a separate session to the vSRX-2 device. From the open session with vSRX-2, log in to the vSRX-2
device with the username lab and a password of labl23. Note that both the name and password are
case-sensitive. Enter configuration mode and load the reset configuration file using the load
override
ajsec/labl-start. config command. After the configuration has been loaded, commit the
changes before proceeding.
vSRX-2 (ttyuO)
login: lab
Password:

lab@vSRX-2> configure
[edit]
lab@vSRX-2# load override ajsec/labl-start.config
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.5
Open a separate session to the vSRX-VR device. From the open session with vSRX-VR, log in to the
vSRX-VR device with the username lab and a password of labl23. Note that both the name and
password are case-sensitive. Enter configuration mode and load the reset configuration file using the
load override ajsec/labl-s tart. config com ma nd. After the configuration has been loaded J

vSRX-VR (ttyuO)
login: lab
Password:

lab@vSRX-VR> configure
[edit]
lab@vSRX-VR# load override ajsec/labl-start.config
[edit]
lab@vSRX-VR# commit
commit complete
[edit]
lab@vSRX-VR#

Part 2: Configuring Transparent Mode

In this lab part, you become familiar with transparent mode operations. You will configure the ge-0/0/4
and ge-0/0/5 interfaces to pass Layer 2 traffic in transparent mode on vSRX-1. You will also configure
transparent mode in-band device management.
step 2.1
Examine the lab diagram and answer the following questions.
Question: Does the lab diagram show the Juniper-sv and

ACME-SV devices in the same or separate subnet?
Answer: Yes. The lab diagram shows that both devices are in the same
subnet.
Question: What is the shared subnet addressing scheme?
Answer: The shared subnet addressing scheme is 10.10.101.0/24.
Step 2.2
Return to the open session with vSRX-1.
From the open session with vSRX-1, navigate to the [edit interfaces ] hierarchy. Examine the
configured interfaces by issuing the show command.
[edit]
lab@vSRX-l# edit interfaces
[edit interfaces]
lab@vSRX-l# show
ge-0/0/0 {
description "MGMT INTERFACE DO NOT DELETE";
unit 0 {
family inet {
address 172.25.11.1/24;
}
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 10.10.101.1/24;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.201.1/24;

}
}
}
fxpO {
disable;
}
loO {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
[edit interfaces]
lab@vSRX-l#
Question: Which protocol family is applied to the ge-0/0/4 and

ge-0/0/5 interfaces?
Answer: The inet protocol family is applied to the ge-0/0/4 and

ge-0/0/5 interfaces.
Question: Will the current interface configuration allow for

communication between the Juniper-sv and acme-sv hosts?
Why?
Answer: No, the current interface configuration will not allow

communication between the Juniper-sv and acme-sv devices
because the interfaces are configured for different subnets.
Question: Which protocol family must you apply to the interfaces to

allow the Juniper-sv and acme-sv device to communicate?
Answer: You must configure the interfaces using the

ethernet-switching protocol family.
Step 2.3
Delete the configuration for the ge-0/0/4 and ge-0/0/5 interfaces and then configure them with the
ethernet-switching protocol family.
[edit interfaces]
lab@vSRX-l# delete ge-0/0/4
[edit interfaces]
lab@vSRX-l# delete ge-0/0/5

[edit interfaces]
lab@vSRX-l# set ge-0/0/4 unit 0 family ethernet-switching
[edit interfaces]
lab@vSRX-l# set ge-0/0/5 unit 0 family ethernet-switching
[edit interfaces]
lab@vSRX-l# show
ge-0/0/0 {
unit 0 {
family inet {
address 172.25.11.1/24;
}
}
}
ge-0/0/4 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/5 {
unit 0 {
family ethernet-switching;
}
}
loO {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
Step 2.4
Examine the security zones by issuing the run show security zones command.
[edit interfaces]
lab@vSRX-l# run show security zones
Functional zone: management
Policy configurable: No
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: ACME-SV

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


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

Interfaces bound: 0
Interfaces:
Question: Which zones are the ge-0/0/4 and ge-0/0/5 interfaces

bound to?
Answer: The ge-0/0/4 and ge-0/0/5 interfaces are bound to the

Juniper-SV and the acme-sv zones; respectively.
Step 2.5
Navigate to the [edit security zones] hierarchy, and delete the security zones.
[edit interfaces]
lab@vSRX-l# up 1 edit security zones
[edit security zones]

lab@vSRX-l# show
functional-zone management {
interfaces {
ge-0/0/0.0;
}
host-inbound-traffic {
system-services {
all;
}
}
}
security-zone Juniper-SV {
system-services {
ping;
}
}
interfaces {
ge-0/0/4.0;
}
}
security-zone ACME-SV {
interfaces {
ge-0/0/5.0;
}
}

lab@vSRX-l#


lab@vSRX-l# delete security-zone ACME-SV

lab@vSRX-l#

lab@vSRX-l# delete security-zone Juniper-SV

lab@vSRX-l#
Step 2.6
Configure the L2 zone and bind the ge-0/0/4 and ge-0/0/5 interfaces to the zone. Ensure that SSH is
allowed in the zone.
lab@vSRX-l# set security-zone L2 interfaces ge-0/0/4

lab@vSRX-l# set security-zone L2 interfaces ge-0/0/5

lab@vSRX-l# set security-zone L2 host-inbound-traffic system-services ssh
Step 2.7
Issue the run show ethernet-switching global-information command.
lab@vSRX-l# run show ethernet-switching global-information
Global Configuration:
MAC aging interval 300

MAC learning Enabled
MAC statistics Disabled
MAC limit Count 65536
MAC limit hit Disabled
MAC packet action drop Disabled
MAC+IP aging interval IPv4 1200 seconds
IPv6 1200 seconds
MAC+IP limit Count 65536
MAC+IP limit reached No
LE aging time 1200
LE BD aging time 1200
MP discard notification interval: 60
Global Mode : Not set
RE state : Master
VXLAN Overlay load bal: Disabled

Question: If you were to commit the configuration right now, would the
Juniper-sv and the acme-sv devices be able to communicate
with each other? Why?
Answer: No, if you were to commit the configuration right now the
Juniper-sv and ACME-sv devices would not be able to
communicate with each other. From the Global Mode field you can
determine that vSRX-1 is set to Not set, which allows only L3
traffic.
step 2.8
Commit the configuration.

lab@vSRX-l# commit
warning: Interfaces are changed from route mode to mix mode. Please reboot the
device or all nodes in the HA cluster!
commit complete
Question: What is mixed mode?
Answer: Mixed mode is a mode in which Layer 3 and Layer 2

interfaces can function on the same SRX device.
Question: What must you now do to get mixed mode to function

properly?
Answer: You must now reboot vSRX-1 to get mixed mode to function
properly.
Step 2.9
Reboot vSRX-1 by issuing the run request system reboot command. Enter yes when prompted.

lab@vSRX-l# run request system reboot
Reboot the system ? [yes,no] (no) yes
Shutdown NOW!
[pid 2695]
[edit interfaces]
lab@vSRX-l#
'k "k "k
FINAL System shutdown message from lab@vSRX-l 'kk k
System going down IMMEDIATELY

Note
It might take up to 10 minutes for vSRX-1 to completely reboot.

Please be patient and now might be a great time for a break.
Step 2.10
After the reboot, log in to the vSRX-1 device with the username lab and a password of labl23. Note
that both the name and password are case-sensitive.
vSRX-1 (ttyuO)
login: lab
Password:

lab@vSRX-l>
Step 2.11
Examine the Layer 2 forwarding status by issuing the show ethernet-switching
global-information command.
lab@vSRX-l> show ethernet-switching global-information
Global Configuration:
MAC aging interval 300

MAC learning Enabled
MAC statistics Disabled
MAC limit Count 65536
MAC limit hit Disabled
MAC packet action drop Disabled
MAC+IP aging interval IPv4 1200 seconds
IPv6 1200 seconds
MAC+IP limit Count 65536
MAC+IP limit reached No
LE aging time 1200
LE VLAN aging time 1200
Global Mode Transparent bridge
RE state Master
VXLAN Overlay load bal Disabled
Question: What can you determine from the output?
Answer: The main item that changed in the output is that the Global
Mode status shows Transparent bridge. This status means that
the interfaces that are configured with the ethernet-switching
protocol family can now receive and forward frames from connected
hosts. There is also other important information in the output, such as
MAC learning being enabled and MAC aging interval setting.

Step 2.12
Issue the show ethernet-switching table command.
lab@vSRX-l> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P Persistent

static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R remote PE MAC, 0
- ovsdb MAC)
Ethernet switching table : 2 entries, 2 learned

Routing instance : default-switch
Vian MAC MAC Age Logical NH RTR
name address flags interface Index ID
default 00:50:56:a9:21:8a D ge-0/0/4.0 0 0
default 00:50:56:a9:4b:d6 D ge-0/0/5.0 0 0
Question: What does the output show?
Answer: The output shows two that the ge-0/0/4 and ge-0/0/5
interfaces have received traffic and have recorded the MAC
addresses on the incoming interface. Also, the MAC addresses were
dynamically learned. Note that more or less MAC addresses might be
present. The MAC address values might not match the output
displayed above.
Step 2.13
Issue the show vlans command.
lab@vSRX-l> show vlans
Routing instance VLAN name Tag Interfaces

default-switch default 1
ge-0/0/4.0 *
ge-0/0/5.0 *
Question: To which VLAN do the ge-0/0/4 and ge-0/0/5 interface

belong?
Answer: The the ge-0/0/4 and ge-0/0/5 interfaces belong to the

default VLAN.

Question: You did not configure any VLANs, why are the interfaces a
part of this VLAN?
Answer: If interfaces are not assigned a VLAN then they are placed in
the default VLAN.
Question: Why is the default VLAN assigned a VLAN ID of 1?
Answer: The default VLAN receives a VLAN ID of 1 by default. The

VLAN ID of 1 is reserved for the default VLAN.
Step 2.14
Issue the show ethernet-switching interface command.
lab@vSRX-l> show ethernet-switching interface
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop.
LH - MAC limit hit, DN interface down,
MMAS - Mac-move action shutdown. AS - Autostate-exclude enabled.
SCTL - shutdown by Storm-control, MI - MAC+IP limit hit)
Logical Vian TAG MAC MAC+IP STP Logical Tagging

interface members limit limit state interface flags
ge-0/0/4.0 8192 0 untagged
default 1 1024 0 Forwarding untagged
LH - MAC limit hit, DN interface down.

ge-0/0/5.0 8192 0 untagged
default 1 1024 0 Forwarding untagged
Question: Are the ge-0/0/4 and ge-0/0/5 interfaces acting in access

mode or trunk mode? How can you determine this fact?
Answer: The interfaces are in access mode. If you look at the

Tagging field you can see that the interfaces are listed as
untagged.

Question: What VLAN ID is being assigned to these interfaces? How

can you determine this fact?
Answer: The tag field shows that the VLAN ID of 1 is being assigned
to these interfaces.
step 2.15
Open a separate session to the vSRX-VR device.
From the open session the vSRX-VR device, log in to the vSRX-VR device with the username lab and a
password of labl23. Note that both the name and password are case-sensitive.
vr-device (ttypO)
login: lab
Password:
JUNOS 20.lRl.il Kernel 64-bit XEN JNPR-11.0-20200219.fbl20e7 bull
lab@vSRX-VR>
Step 2.16
Test connectivity from the Juniper-svtothe acme-sv device. Remember that the Juniper-SV and
ACME-SV devices are on the same subnet for this lab. To test this connectivity issue the
ssh 10.10.101.100 routing-instance Juniper-SV command.
lab@vSRX-VR> ssh 10.10.101.100 routing-instance Jun±per-SV
Question: What is the result of the test?
Answer: The SSH test does not complete successfully.
Step 2.17
Return to the vSRX-1 device.
From the vSRX-1 device, issue the show security flow session destination-prefix
10.10.101.100 application ssh command.
lab@vSRX-l> show security flow session destination-prefix 10.10.101.100
application ssh
Total sessions: 0

Answer: The output shows that there are no SSH flows for the host.
This result means that the traffic between the Juniper-sv and
ACME-SV devices is not flowing through vSRX-1.
Question: What are some possible items that can cause this situation
on vSRX-1?
Answer: Some possible problems are misconfigured interfaces,

interfaces that are not in the correct security zone, misconfigured
transparent mode, and a misconfigured security policy, as well as
other things.
Step 2.18
Examine the security zones by issuing the show security zones command.
lab@vSRX-l> show security zones
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: L2
Interfaces bound: 2
Interfaces:
ge-0/0/4.0
ge-0/0/5.0

Interfaces bound: 0
Interfaces:
Question: Which zone are the ge-0/0/4 and ge-0/0/5 interfaces in? Is
this the correct zone for the interfaces?
Answer: The interfaces are in the L2 zone, which is the correct zone.

Step 2.19
Examine the interfaces by issuing the show interfaces terse | match eth-switch
command.
lab@vSRX-l> show interfaces terse | match eth-switch
ge-0/0/4.0 up up eth-switch
ge-0/0/5.0 up up eth-switch
Question: What protocol family is applied to the ge-0/0/4 and

ge-0/0/5 interfaces? Is it the correct protocol family?
Answer: The ethenet-switching protocol family is applied to the

interfaces. The interfaces have the correct protocol family.
Step 2.20
Examine the security policies by issuing the show security policies command.
lab@vSRX-l> show security policies
Default policy: deny-all
Pre ID default policy: permit-all
Question: What is the problem?
Answer: The only security policy on vSRX-1 is the implicit deny all
policy which is the Default policy on vSRX-1. The Pre ID default poicy
is only for packets being used with Unified Policies where the
application ID is needed to decide if the flow matches the policy. So,
there is no security policy to permit the traffic between the J uniper-SV
and ACME-SV devices.
Step 2.21
Enter configuration mode and navigate to the [edit security policies global policy L2]
hierarchy level.
[edit]
lab@vSRX-l# edit security policies global policy L2
[edit security policies global policy L2]

lab@vSRX-l#
Step 2.22
Configure the security policy to allow any traffic that is going to or coming from the L2 security zone
(intra-zone traffic). Commit the configuration when you are finished.
lab@vSRX-l# set match from-zone L2


lab@vSRX-l# set match to-zone L2

lab@vSRX-l# set match source-address any

lab@vSRX-l# set match destination-address any

lab@vSRX-l# set match application any

lab@vSRX-l# set then permit

lab@vSRX-l# show
match {
source-address any;
destination-address any;
application any;
from-zone L2;
to-zone L2;
}
then {
permit;
}

lab@vSRX-l# commit
commit complete
Step 2.23
Return to the open session with the vSRX-VR device.
From the open session with the vSRX-VR device, press the Ctrl + c key combination to close the SSH
session attempt if it is still open and start the SSH testagain by issuing the ssh 10.10.101.100
routing-instance Juniper-sv command. Log in using the labl23 password. If you are asked to
permanently add that address to the known hosts, answer yes when asked if you want to continue.
lab@vSRX-VR> ssh 10.10.101.100 routing-instance Juniper-SV
PING 10.10.101.100 (10.10.101.100): 56 data bytes
ECDSA key fingerprint is cc:50:59:d9:eO:69:7f:5f:3f:c5:ae:79:34:18:9d:ff.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’10.10.101.100 I (ECDSA) to the list of known hosts.
Password:
lab@vSRX-VR>

Step 2.24
From the vSRX-1 device, issue the run show security flow session destination-prefix
lab@vSRX-l# run show security flow session destination-prefix 10.10.101.100
application ssh
Session ID: 183, Policy name: L2/4, Timeout: 1712, Valid
In: 10.10.101.10/50654 10.10.101.100/22;tcp. Conn Tag: 0x0, If: ge-0/0/4.0.
Pkts : 40, Bytes: 8314,
Out: 10.10.101.100/22 -- 10.10.101.10/50654;tcp. Conn Tag: 0x0, If: ge-0/0/5.0.
Pkts : 27, Bytes: 4263,
Total sessions: 1
Answer: The output shows that traffic is flowing between the

Juniper-sv and ACME-sv devices.
Step 2.25
Return to the vSRX-VR device.
From the vSRX-VR device, stop the running exit the SSH session by issuing the exit command.
lab@vSRX-VR> exit
Connection to 10.10.101.100 closed.
lab@vSRX-VR>
Part 3: Configuring in-Band Management

In this lab part you will use an IRB interface to allow in-band management of vSRX-1.
Step 3.1
Return to open session with vSRX-1.
From the open session with vSRX-1, navigate to the [edit interfaces] hierarchy.
lab@vSRX-l# top edit interfaces
[edit interfaces]
lab@vSRX-l#
Step 3.2
Configure the IRB interface with the 10.10.101.101/24 address.
[edit interfaces]
lab@vSRX-l# set irb.O family inet address 10.10.101.101/24

[edit interfaces]
lab@vSRX-l# show irb
unit 0 {
family inet {
address 10.10.101.101/24;
}
}
Step 3.3
Navigate to the [edit vlans] hierarchy.
[edit interfaces]
lab@vSRX-l# up 1 edit vlans
[edit vlans]
lab@vSRX-l#
Step 3.4
Configure the sv VLAN with VLAN ID 101 and bind the irb.O interface as the Layer 3 interface for the
VLAN.
[edit vlans]
lab@vSRX-l# set SV vlan-id 101
[edit vlans]
lab@vSRX-l# set SV 13-interface irb.O
[edit vlans]
lab@vSRX-l# show
SV {
vlan-id 101;
13-interface irb.O;
}
Question: What must you do to add the ge-0/0/4 and ge-0/0/5

interfaces to the SV VLAN?
Answer: There are a few different methods to add the interfaces to the
VLAN. You can reference the VLAN name under the interfaces, you can
reference the VLAN ID under the interfaces, or you can add the
interfaces to the VLAN.
Step 3.5
Add the ge-0/0/4 and ge-0/0/5 interfaces to the sv VLAN.
[edit vlans]
lab@vSRX-l# set SV interface ge-0/0/4
[edit vlans]
lab@vSRX-l# set SV interface ge-0/0/5
[edit vlans]
lab@vSRX-l# show

SV {
vlan-id 101;
interface ge-0/0/4.0;
13-interface irb.O;
}
step 3.6
Add the irb.O interface to the L2 security zone and attempt to commit the configuration when you are
finished.
[edit vlans1
lab@vSRX-l# top set security zones security-zone L2 interfaces irb.O
[edit vlans1
lab@vSRX-l# commit
[edit security zones security-zone L2]
’interfaces irb.O’
Interface irb is not allowed in mix mode
error: configuration check-out failed
Question: What is wrong with the configuration?
Answer: Although the commit error makes it seem like you cannot use
IRB interfaces while vSRX-1 is in mixed mode, it really means that you
cannot put an IRB interface in a security zone while vSRX-1 is in
mixed mode.
Step 3.7
Remove the irb.O interface from the L2 security zone and commit the configuration when you are
finished.
[edit vlans1
lab@vSRX-l# top delete security zones security-zone L2 interfaces irb.O
[edit vlans1
lab@vSRX-l# commit
commit complete
[edit vlans]
lab@vSRX-l#
Step 3.8
Issue the run show vlans command.
[edit vlans1
lab@vSRX-l# run show vlans

default-switch SV 101
ge-0/0/4.0 *
ge-0/0/5.0 *

Question: What does the output tell you?
Answer: The output shows that the ge-0/0/4 and ge-0/0/5 interfaces
are now part of the sv VLAN and they use the 101 VLAN ID tag.
Question: Why does the output not show the irb.O interface?
Answer: Although the sv VLAN uses the irb.O interface as the Layer 3
interface for the VLAN, it does not appear in the output because it is
not a Ethernet switching interface.
Step 3.9
From the open session with the vSRX-VR device, start an SSH test by issuing the ssh 10.10.101.101
routing-instance Juniper-SV command.
Question: What is the result of the SSH test?
Answer: The SSH test shows that there is no connectivity.
Step 3.10
[edit vlans]
application ssh
Total sessions: 0
Step 3.11
From the vSRX-1 device, issue the run show ethernet-switching interface command.
[edit vlans]
lab@vSRX-l# run show ethernet-switching interface
LH - MAC limit hit, DN interface down,


ge-0/0/5.0 0 0 tagged
SV 101 1024
Forwarding
0 tagged

interface members limit limit State interface flags
ge-0/0/4.0 0 0 tagged
SV 101 1024 0 Forwarding tagged
Question: What is the problem? What must you do to solve the

problem?
Answer: Before the interfaces were placed in the VLAN, they were
access interfaces, but adding the interfaces to the VLAN causes the
interfaces to become trunk interfaces. You must configure the
interfaces in access mode to solve the problem. Note that you cannot
reference the interfaces in a VLAN if you explicitly configure them as
access mode interfaces. You will need to remove the ge-0/0/4 and
ge-0/0/5 interfaces from the SV VLAN.
Step 3.12
Remove the ge-0/0/4 and ge-0/0/5 interfaces from the sv VLAN.
[edit vlans]
lab@vSRX-l# delete SV interface ge-0/0/4
[edit vlans]
lab@vSRX-l# delete SV interface ge-0/0/5
Step 3.13
Navigate to the [edit interfaces ] hierarchy. Configure the ge-0/0/4 and ge-0/0/5 interfaces as
access interfaces.
[edit vlans1
lab@vSRX-l# up 1 edit interfaces
[edit interfaces]
lab@vSRX-l#
Step 3.14
Configure the ge-0/0/4 and ge-0/0/5 interfaces as access mode interfaces.
[edit interfaces]
lab@vSRX-l# set ge-0/0/4 unit 0 family ethernet-switching interface-mode access
[edit interfaces]
lab@vSRX-l# set ge-0/0/5 unit 0 family ethernet-switching interface-mode access

Step 3.15
Configure the ge-0/0/4 and ge-0/0/5 interfaces to be members of the sv VLAN. Commit the
configuration when you are finished. Note there are a few different ways to configure VLANs and we are
using the interface VLAN assignment method.
[edit interfaces]
lab@vSRX-l# set ge-0/0/4 unit 0 family ethernet-switching vlan members SV
[edit interfaces]
lab@vSRX-l# set ge-0/0/5 unit 0 family ethernet-switching vlan members SV
[edit interfaces]
lab@vSRX-l# show
ge-0/0/0 {
unit 0 {
family inet {
address 172.25.11.1/24;
}
}
}
ge-0/0/4 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members SV;
}
}
}
}
ge-0/0/5 {
unit 0 {
interface-mode access;
vlan {
members SV;
}
}
}
}
irb {
unit 0 {
family inet {
address 10.10.101.101/24;
}
}
}
loO {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}

[edit interfaces]
lab@vSRX-l# commit
commit complete
[edit interfaces]
lab@vSRX-l#
Step 3.16
From the open session with the vSRX-VR device, press the Ctrl + c key combination to close the SSH
session attempt if it is still open and start the SSH test again by issuing the ssh 10.10.101.101
routing-instance Juniper-SV command. Login to vSRX-1 with a password of labl23. If it asks
you to permanently add the IP address to the list of known hosts, enter yes when asked if you want to
continue.
PING 10.10.101.100 (10.10.101.100): 56 data bytes
The authenticity of host ’10.10.101.101 (10.10.101.101)’ can’t be established.
ECDSA key fingerprint is 07:3c:c5:9d:3b:05:d7:53:5d:2d:f1:11:56:aa:aa:45.
Warning: Permanently added ’10.10.101.101’ (ECDSA) to the list of known hosts.
Password:
lab@vSRX-l>
Question: What are the results of the SSH test?
Answer: The SSH test shows that there is communication between

the Juniper-SV device and vSRX-1 using the irb.O interface on
vSRX-1.
Question: What is the result of the SSH attempt?
Answer: You are able to manage vSRX-1 from the Juniper-SV device
using SSH.
Step 3.17
[edit vlans]
application ssh
Session ID: 40, Policy name: self-traffic-policy/1, Timeout: 1734, Valid
Pkts : 19, Bytes: 3857,

Out: 10.10.101.101/22 10.10.101.10/59117;tcp. Conn Tag: 0x0, If: .local..0,

Pkts : 15, Bytes: 3419,
Total sessions: 1
Question: What does the output reveal?
Answer: The output shows that the SSH session is working properly.
Step 3.18
Return to the session with the vSRX-VR device.
From the open session with the vSRX-VR device, issue the exit command to return to the vSRX-VR
terminal.
lab@vSRX-l> exit
lab@vSRX-VR>
Part 4: Configuring Secure Wire
In this lab part you configure secure wire functionality.

Step 4.1
Return to the open session with vSRX-1. Configure the ge-0/0/1 and ge-0/0/7 interface with the
ethernet-switching protocol family and add them to be members of the sw VLAN.
[edit interfaces]
lab@vSRX-l# set ge-0/0/1 unit 0 family ethernet-switching vlan members SW
[edit interfaces]
lab@vSRX-l# set ge-0/0/7 unit 0 family ethernet-switching vlan members SW
[edit interfaces]
lab@vSRX-l# show ge-0/0/1
unit 0 {
vlan {
members SW;
}
}
}
[edit interfaces]
lab@vSRX-l# show ge-0/0/7
unit 0 {
vlan {

members SW;
}
}
}
Step 4.2
Navigate to the [edit vlan] hierarchy level.
[edit interfaces]
lab@vSRX-l# up 1 edit vlans
[edit vlans]
lab@vSRX-l#
Step 4.3
Configure the SW VLAN to use the VLAN ID of 50.
[edit vlans]
lab@vSRX-l# set SW vlan-id 50
[edit vlans]
lab@vSRX-l# show
SV {
vlan-id 101;
13-interface irb.O;
}
SW {
vlan-id 50;
}
Step 4.4
Navigate to the [edit security forwarding-options secure-wire] hierarchy level.
[edit vlans]
lab@vSRX-l# up 1 edit security forwarding-options secure-wire
[edit security forwarding-options secure-wire]

lab@vSRX-l#
Step 4.5
Configure the ge-0/0/1.0 and the ge-0/0/7.0 interfaces in the sw secure wire.
Note
Make sure you include the unit number of 0 on both interfaces
in the secure wire. If you omit the unit number the commit
check will fail.

lab@vSRX-l# set interface ge-0/0/1.0


Question: What are the next steps in configuring the SW secure wire?
Answer: The next steps would be to add the secure wire interfaces to a
security zone, then create a security policy that allows the traffic.
Step 4.6
Navigate to the [edit security zones security-zone SW] hierarchy.
lab@vSRX-l# top edit security zones security-zone SW
[edit security zones security-zone SW]

lab@vSRX-l#
Step 4.7
Bind the ge-0/0/1 and ge-0/0/7 interfaces to the security zone.
lab@vSRX-l# set interfaces ge-0/0/1


lab@vSRX-l# show
interfaces {
ge-0/0/1.0;
ge-0/0/7.0;
}
Step 4.8
Configure the L2-deny log file by issuing the top set system syslog file L2-deny any any
command. Then, issue the top set system syslog file L2-deny rt_flow_session_deny
command.
lab@vSRX-l# top set system syslog file L2-deny any any

lab@vSRX-l# top set system syslog file L2-deny match RT_FLOW_SESSION_DENY
Note
These commands will help later for troubleshooting. They are not
required for the operation of secure wire.
Step 4.9
Navigate to the [edit security zones security-zone SW-permit] hierarchy.
[edit security zones security-zone SW-permit]
lab@vSRX-l# top edit security policies global policy SW-peirmit

[edit security policies global policy SW-permit]
lab@vSRX-l#
Step 4.10
Configure the security policy to permit all SSH traffic coming from or going to the sw security zone.
lab@vSRX-l# set match from-zone SW

lab@vSRX-l# set match to-zone SW



lab@vSRX-l# set match application junos-ssh


lab@vSRX-l# show
match {
source-address any;
application junos-ssh;
from-zone SW;
to-zone SW;
}
then {
permit;
}
Step 4.11
Navigate to the [edit security zones security-zone SW-deny] hierarchy.
lab@vSRX-l# up 1 edit policy SW-deny
[edit security policies global policy SW-deny]

lab@vSRX-l#
Step 4.12
Configure the security policy to deny and log Telnet traffic coming from or going to the sw security zone.
Commit the configuration and exit to operational mode when you are finished.
lab@vSRX-l# set match from-zone SW

lab@vSRX-l# set match to-zone SW



lab@vSRX-l# set match application junos-telnet

lab@vSRX-l# set then deny

lab@vSRX-l# set then log session-init

lab@vSRX-l# show
match {
source-address any;
application junos-telnet;
from-zone SW;
to-zone SW;
}
then {
deny;
log {
session-init;
}
}

lab@vSRX-l# commit and-quit
commit complete
Exiting configuration mode
lab@vSRX-l>
Step 4.13
Clear the log file to L2-deny log file with the clear log L2-deny command.
lab@vSRX-l> clear log L2-deny
Step 4.14
Issue the show vlans command.
lab@vSRX-l> show vlans

default-switch SV 101
ge-0/0/4.0*
ge-0/0/5.0*
default-switch SW 50
ge-0/0/1.0*
ge-0/0/7.0*

Question: What does the output reveal?
are a part of the SW VLAN and the VLAN is using the VLAN ID of 50.
Step 4.15
Issue the show ethernet-switching interface command.
lab@vSRX-l> show ethernet-switching interface
MMAS - Mac-move action shutdown. AS Autostate-exclude
enabled.

interface memb e r s limit limit state interface flags
ge-0/0/1.0 8192 0 untagged
SW 50 1024 0 Forwarding untagged
enabled.

interface memb e r s limit limit state interface flags
ge-0/0/7.0 8192 0 untagged
SW 50 1024 0 Forwarding untagged
enabled.
Logical Vian TAG MAC MAC+IP STP

Tagging
interface members limit limit state interface
flags
ge-0/0/4.0 8192 0
untagged
SV 101 1024 0 Forwarding
untagged
enabled.

Logical Vian TAG MAC MAC+IP STP Logical

Tagging
ge-0/0/5.0 8192 0
untagged
SV 101 1024 0 Forwarding
untagged
lab@vSRX-l>
are in the forwarding STP state and are functioning as access
interfaces.
Step 4.16
From the open session with vSRX-2, issue the ssh 172.18.1.1 command to open an SSH session with
the local host. To make sure the session does not timeout prematurely, login using the password
labl23.
lab@vSRX-2 ssh 172.18.1.1
Note
You might be prompted if you are sure you want to connect to
the 172.18.1.1 host, if you are enter yes to continue
Password:
--- JUNOS 20.lRl.il Kernel 64-bit XEN JNPR-11.0-20200219.fbl20e7_buil
lab@vSRX-VR>
Step 4.17
From the open session with vSRX-1, issue the show security flow session application ssh
source-prefix 172.18.1.2 command.
lab@vSRX-l> show security flow session application ssh source-prefix 172.18.1.2
Session ID: 15435, Policy name: SW-permit/6, Timeout: 1658, Valid
In: 172.18.1.2/63475 -- 172.18.1.1/22;tcp. Conn Tag: 0x0, If: ge-0/0/7.0. Pkts:
19, Bytes: 4091,
Out: 172.18.1.1/22 — 172.18.1.2/63475;tcp. Conn Tag: 0x0, If: ge-0/0/1.0. Pkts:
15, Bytes: 3459,
Total sessions: 1

Answer: The output shows that SSH traffic is going creating a flow in
the session using interfaces ge-0/0/1 and ge-0/0/7 with the
SW-permit policy.
Step 4.18
Issue the show ethernet-switching table command.
lab@vSRX-l> show ethernet-switching table
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P Persistent

static, C - Control MAC
SE - statistics enabled, NM - non configured MAC, R remote PE MAC, 0
- ovsdb MAC)
Ethernet switching table : 2 entries, 2 learned

Routing instance : default-switch
Vian MAC MAC Age Logical NH RTR
name address flags interface Index ID
SV 00:50:56:a9:4c:22 D ge-0/0/5.0 0 0
SV 00:50:56:a9:57:93 D ge-0/0/4.0 0 0
Question: Why are there no entries for the ge-0/0/1 and

ge-0/0/7 interfaces?
Answer: Remember that with a secure wire there is no routing or

switching lookups as it simulates a Layer 1 connection. To this end
there will be no output for the ge-0/0/1 and ge-0/0/7 interfaces in
the previous output. There might be more MAC addresses in your
output than what is shown in the previous output.
step 4.19
From the open session with vSRX-2, close the SSH session by issuing the exit command.
lab@vSRX-VR> exit
lab@vSRX-2
Step 4.20
Attempt to open a Telnet session with the local host by issuing the telnet 172.18.1.1 command.
lab@vSRX-2 telnet 172.18.1.1
Trying 172.18.1.1...

Step 4.21
From the open session with vSRX-1, issue the show log L2-deny command.
lab@vSRX-l> show log L2-deny
Mar 24 14:40:02 vSRX-1 RT FLOW: RT FLOW SESSION DENY: session denied 172.18.1.2/
61645->172.18.1.1/23 0x0 junos-telnet 6(0) SW-deny(global) SW SW UNKNOWN UNKNOWN
N/A(N/A) ge-0/0/7.0 No Denied by policy 196909 N/A N/A -1 N/A N/A N/A
Question: What can you determine from the log file?
Answer: The log file shows that Telnet traffic is being denied by the
SW-deny policy.
Step 4.22
Issue the exit command to log out of the device.
lab@vSRX-l> exit
Step 4.23
From the open session with vSRX-2, issue the exit command to log out of the device.
lab@vSRX-2 exit
Step 4.24
Return to the open session with vSRX-VR.
From the open session with vSRX-VR, issue the exit command to log out of the device.
lab@vSRX-VR> exit
STOP
Tell your instructor that you have completed this lab.

Management Network Diagram

vSRX-1
ATP Cloud
vSRX-2 I
55 ge-0/0/0 (on all student devices)
Physical
Virtual Desktop! Gateway Desktops
vSRx-vR I I 172,25,11.254 1
1
Internet
vQFX-1 '■M
] Console and
VNC Connections
Junos
Space
Management Addressing
Policy
Enforcer vSRX-1 172.25.11.1
Hypervisor
Virtual Switch vSRX-2 172.25.11.2
Core ATP On-Prem
MGMT vSRX-VR 172.25.11.9
Network
vQFX-1 172.25.11.10
ATP Web Collector 172.25.11.0/24
Junos Space 172.25.11.100
Student Policy Enforcer 172.25.11.101
c
Lab Environment
3
AD/NTP/DNS Server ATP On-Prem 172.25.11.120

ATP Web Collector 172.25.11.121
AD/NTP/DNS Server 172.25.11.130
Gateway 172.25.11.254
© 2020 Juniper Nehvorks, Inc. All Rights Reserved.

Juniper Business Use Only
juniper
NETWORKS
Lab Network Diagram:

Implementing Layer 2 Security
Local Server
172.18.1.1
C
ge-0/0/1
ge-O/O/7
ge-0/0/7 172.18.1.2/24
vSRX-1 vSRX-2
ge-0/0/4 ge-0/0/5
10.10.101.10/24 vSRX-VR 10.10.101.100/24
Juniper-SV ACME-SV
Virtual Routers

jumper
NETWORKS


Lab
Firewall Filters
Overview
This lab demonstrates configuration and monitoring of firewall filters on devices running the Junos
operating system. In this lab, you use the command-line interface (CLI) to define, apply, and monitor
firewall filters. Then, you will configure two virtual routing instances. You will then configure the virtual
routers (VRs) to communicate with the Internet host, and then to communicate with each other. You will
then configure filter-based forwarding to direct traffic in a different direction than the installed route
would take it.
In completing this lab, you will perform the following tasks:
• Prepare your device and verify operation.
• Configure and monitor firewall filters.
• Configure Internet access for the VRs.
• Configure inter-VR communication.
• Configure filter-based forwarding.
www.juniper.net Firewall Filters • Lab 2-1

Part 1: Preparing the System and Verifying Proper Operation
In this lab, you will make modifications to the configuration and verify proper operation of vSRX-1. You
will also login to vSRX-2 to verify and monitor changes in network operation in response to your changes
in configuration to vSRX-1. In this lab part, you must refer to the network diagram for this lab.
Note
The instructor will inform you as to the nature of your access
and will provide you with the details to access your student
environment.
step 1.1
Access the CLI of vSRX-1 using either the console or SSH as directed by your instructor. Your instructor will
provide you with the access details. Log in to vSRX-1 with username lab and password labl23. Note
that both the name and password are case-sensitive. Enter configuration mode and load the lab
configuration file using the load override ajsec/lab2-start. config command. After the
configuration has been loaded, commit the changes.
Last login: Wed Apr 29 18:42:51 2020 from 172.25.11.254
[edit]
lab@vSRX-l# load override ajsec/lab2-start.config
load complete
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Step 1.2
Step 1.3
Access the CLI of vSRX-2 using either the console or SSH as directed by your instructor. Your instructor will
provide you with the access details. Log in to vSRX-2 with username lab and password labl23. Note
that both the name and password are case-sensitive. Enter configuration mode and load the lab
configuration file usingthe load override ajsec/Iab2-start. config command. After the
configuration has been loaded, commit the changes and exit to operational mode.
[edit]
lab@vSRX-2# load override ajsec/lab2-start.config
load complete
Lab 2-2 • Firewall Filters www.juniper.net

[edit]
lab@vSRX-2# commit and-quit
commit complete
lab@vSRX-2
Step 1.4
Access the CLI of vSRX-VR using either the console or SSH as directed by your instructor. Your instructor
will provide you with the access details.
Step 1.5
Log in to vSRX-VR with username lab and password labl23. Note that both the name and password
are case-sensitive. Enter configuration mode and load the lab configuration file using the load
override aj sec/lab2-start. config command. After the configuration has been loaded,
commit the changes and exit to operational mode.
[edit]
lab@vSRX-VR# load override ajsec/lab2-start.conf±g
load complete
[edit]
lab@vSRX-VR# commit and-quit
commit complete
lab@vSRX-VR>
Note
The next lab steps require you initiate traffic from the
Juniper-si/virtual router attached to vSRX-1. The
Juniper-WF virtual router is attached to vSRX-2.
Step 1.6
From vSRX-VR, use the ping utility to verify reachability to the vSRX-1 loopback address and the Internet
host. Refer to the network diagram associated with this lab as needed.
Note
Remember that you must reference the appropriate instance

name when sourcing Internet Control Message Protocol (ICMP)
traffic from a virtual router. In this case, the instance name is
Juniper-SV.
lab@vSRX-VR> ping routing-instance Juniper-SV 192.168.1.1 rapid count 25

PING 192.168.1.1 (192.168.1.1): 56 data bytes
I I I I I I I I I I I I I I I I I I I I I I I I I
- 192.168.1.1 ping statistics --

25 packets transmitted, 25 packets received. 0% packet loss

round-trip min/avg/max/stddev = 7.790/13.574/60.981/10.079 ms

PING 172.31.15.1 (172.31.15.1): 56 data bytes
-- 172.31.15.1 ping statistics --
Question: Do the ping tests succeed?
Answer: Yes, as shown in the capture, the ping tests should succeed
from the virtual router.
Step 1.7
Attempt to establish an SSH session with vSRX-1 by issuing the ssh command. Reference virtual router
Juniper-SVuse the vSRX-1 loopback address as the destination address. Login with username
lab and password labl23. Since this will most likely be the first time an ssh session has been
established between the two devices, it is probable there will be a warning issued. Accept the warning
with yes.
lab@vSRX-VR> ssh routing-instance Juniper-SV lab@192.168.1.1
ECDSA key fingerprint is SHA256:Ky8SDlsQVqFCRA82+RZ+hSfbfyOWPTrfHeTHkvQ4Gf4.
Password:
lab@vSRX-l>
Question: Does the SSH session establish successfully?
Answer: Yes, as shown in the capture, the SSH session does establish
successfully.
Step 1.8
Issue the exit command to close the SSH session.
lab@vSRX-l> exit
lab@vSRX-VR>
Step 1.9
Attempt to establish a Telnet session with vSRX-1. Reference virtual router Juniper-svar\6 use the
vSRX-1 loopback address as the destination address. Login with username lab and password labl23.
lab@vSRX-VR> telnet routing-instance Juniper-SV 192.168.1.1
Trying 192.168.1.1...

Connected to 192.168.1.1.
Escape character is ]'. I A
login: lab
Password:
Last login: Fri Feb 7 17:39:49 from 172.20.101.10
Question: Does the Telnet session establish successfully?
Answer: Yes, as shown in the capture, the Telnet session does

establish successfully.
Step 1.10
Issue the exit command to close the Telnet session.
lab@vSRX-l> exit
Connection closed by foreign host.
lab@vSRX-VR>
Note
You perform additional verification tasks from the

Juniper-si/virtual router later in this lab. Keep the vSRX-VR
CLI session open for the subsequent lab tasks.
Step 1.11
From the open session with vSRX-1, issue the run show ospf neighbor and run show route
commands.
[edit]
lab@vSRX-l# run show ospf neighbor
Address Interface state ID Pri Dead
172.20.66.2 ge-0/0/7.0 Full 192.168.2.1 128 34
172.20.77.2 ge-0/0/8.0 Full 192.168.2.1 128 33
[edit]
lab@vSRX-l# run show route
inet.O: 20 destinations, 20 routes (20 active. 0 holddown, 0 hidden)

+ = Active Route, = Last Active, *
Both
0.0.0.0/0 'k
[Static/5] 5d 07:41:01
> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 * [Direct/0] 5d 07:41:01
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] 5d 07:41:01
Local via ge-0/0/1.0
172.20.66.0/30 *
[Direct/0] 5d 07:41:01
> via ge-0/0/7.0

172.20.66.1/32 ■k
[Local/0] 5d 07:41:01
172.20.77.0/30 * [Direct/0] 5d 07:41:01
> via ge-0/0/8.0
172.20.77.1/32 * [Local/0] 5d 07:41:01
172.20.101.0/24 * [Direct/0] 5d 07:41:01
> via ge-0/0/4.0
172.20.101.1/32 * [Local/0] 5d 07:41:01
172.20.102.0/24 * [OSPF/10] 00:09:20, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
172.21.0.0/24 * [Static/5] 5d 07:41:01
> to 172.20.101.10 via ge-0/0/4.0
172.21.1.0/24 * [Static/5] 5d 07:41:01
> to 172.20.101.10 via ge-0/0/4.0
172.21.2.0/24 * [Static/5] 5d 07:41:01
> to 172.20.101.10 via ge-0/0/4.0
172.25.11.0/24 * [Direct/0] 3w0d 00:00:59
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 3w0d 00:00:59
192.168.1.1/32 * [Direct/0] 2w6d 22:54:00
> via loO.O
192.168.1.2/32 * [Static/5] 5d 07:41:01
> to 172.20.101.10 via ge-0/0/4.0
192.168.2.1/32 * [OSPF/10] 00:09:20, metric 1
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
192.168.2.2/32 * [OSPF/10] 00:09:20, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
224.0.0.5/32 * [OSPF/10] 2w6d 22:54:01, metric 1
MultiRecv
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, = Last Active, * Both
ff02::2/128 * [INET6/0] 3w0d 00:01:05

MultiRecv
Question: Does your device still show its OSPF neighbor adjacencies in
the Full state?
Answer: Yes, at this time vSRX-1 should show two OSPF neighbor
adjacencies in the Full state.

Question: Does vSRX-1 have the required route table entries to route
to all internal and external destinations?
Answer: Yes, at this time all student devices should have the required
route table entries to facilitate routing to both internal and external
destination prefixes.
Question: Which route entries have been learned using the OSPF
protocol?
Answer: You should see in the routing table OSPF routes to

192.168.2.1/32,192.168.2.2/32,and 172.20.102.0/2 4.
Part 2: Configuring and Monitoring Firewall Filters

In this lab part, you will configure and monitor firewall filters.
Step 2.1
On your vSRX-1 CLI session, navigate to the [edit firewall] hierarchy level. Issue the edit
family ? command and answer the following question:
[edit]
lab@vSRX-l# edit firewall
[edit firewall]
lab@vSRX-l# edit family ?
Possible completions:
> any Protocol-independent filter
> CCC Protocol family CCC for firewall filter
> ethernet-switching Protocol family Ethernet Switching for firewall filter
> evpn Protocol family EVPN for firewall filter
> inet Protocol family IPv4 for firewall filter
> inet6 Protocol family IPv6 for firewall filter
> mpls Protocol family MPLS for firewall filter
> vpls Protocol family VPLS for firewall filter
[edit firewall]
lab@vSRX-l#
Question: Based on the available options, which family designation

is used for IPv4 firewall filters?
Answer: The family inet firewall filter option is used for IPv4
firewall filters.
Step 2.2
Issue the edit family inet filter protect-host command in preparation to create a new
IPv4 firewall filter named protect-host.

[edit firewall]
lab@vSRX-l# edit family inet filter protect-host
[edit firewall family inet filter protect-host]

lab@vSRX-l#
Step 2.3
Create a term named limit-icmp that only permits inbound ICMP packets from the management
subnet only.
lab@vSRX-l# set term limit-icmp from protocol icmp

lab@vSRX-l# set term limit-icmp from source-address 172.25.11.0/24

lab@vSRX-l# set term limit-icmp then accept
Step 2.4
Create a term named limit-ssh that permits inbound SSH packets from the
172.25.11.0/24 subnet only.
lab@vSRX-l# set term limit-ssh from protocol tcp port ssh

lab@vSRX-l# set term limit-ssh from source-address 172.25.11.0/24

lab@vSRX-l# set term limit-ssh then accept
Step 2.5
Create a term named limit-telnet that permits inbound Telnet packets from the management
subnet only.
lab@vSRX-l# set term limit-telnet from protocol tcp port telnet

lab@vSRX-l# set term limit-telnet from source-address 172.25.11.0/24

lab@vSRX-l# set term limit-telnet then accept
Step 2.6
Navigate to the [edit interfaces loO] hierarchy level and apply the protect-host firewall filter
as an input filter. Issue the commit command to activate the configuration change.
lab@vSRX-l# top edit interfaces loO
[edit interfaces loO]

lab@vSRX-l# set unit 0 family inet filter input protect-host

lab@vSRX-l# commit

commit complete

lab@vSRX-l#
Step 2.7
Return to the open CLI session with vSRX-VR
From the open session with vSRX-VR , use the ping utility, from the Juniper-svvirtual router, to test
reachability to the vSRX-1 loopback address and the Internet host. Refer to the network diagram for the
destination addresses when performing the ping operations.
Note

name when sourcing ICMP traffic from a virtual router.

PING 192.168.1.1 (192.168.1.1): 56 data bytes


PING 172.31.15.1 (172.31.15.1): 56 data bytes
Question: Do both ping tests succeed? Is this result the expected

behavior?
Answer: Only one of the ping tests succeeds. As shown, the ping test
to the vSRX-1 loopback address does not succeed while the ping test
to the Internet host does succeed. Based on the current
configuration, this result is expected. Remember that our recently
added loopback filter only permits inbound ICMP traffic from the
management subnet. The new filter does not, however, affect transit
traffic.
Step 2.8
Attempt to establish SSH and Telnet sessions with vSRX-1. Use the loopback address assigned to vSRX-1
as the destination address.
Note

name when sourcing traffic from a virtual router.
Note
Use the Ctrl+c sequence to break unresponsive attempts for

SSH and Telnet sessions.

lab@vSRX-VR> ssh routing-instance Juniper-SV 192.168.1.1

Trying 192.168.1.1...
lab@vSRX-VR>
Question: Do the SSH and Telnet sessions successfully establish?

Given the current configuration, is this behavior expected?
Answer: As shown in the capture, none of the session attempts

successfully establishes. Because the session attempts do not use a
source address within the management subnet, the session attempts
should fail by design.
Step 2.9
To confirm that the firewall filter applied to your student device’s loopback interface permits inbound
ICMP echo requests, SSH, and Telnet traffic destined for the local host and sourced from the
management subnet, attempt the same tests performed in the previous two steps. Perform these tests
from your vSRX-VR CLI session, but do not specify a routing instance. Use the management IP address
assigned to vSRX-1 as the destination address. Refer to the management network diagram as needed.
lab@vSRX-VR> ping 172.25.11.1 rapid count 25
PING 172.25.11.1 (172.25.11.1): 56 data bytes

Question: Does the ping test succeed?
Answer: Yes, the ping test should now succeed because the ICMP
echo requests use a source address within the management subnet.
lab@vSRX-VR> ssh 172.25.11.1

The authenticity of host ’172.25.11.1 (172.25.11.1) ’ can’t be established.
ECDSA key fingerprint is SHA256:Ky8SDlsQVqFCRA82+RZ+hSfbfyOWPTrfHeTHkvQ4Gf4.
Password:
Last login: Fri Feb 7 17:40:58 2020 from 172.20.101.10
lab@vSRX-l> exit
lab@vSRX-VR> telnet 172.25.11.1

Trying 172.25.11.1...

Escape character is I A
]'.
login: lab
Password:
lab@vSRX-l> exit
lab@vSRX-VR>
Answer: Yes, because the session attempts use a source address

within the management subnet, the session attempts should now
succeed.
Question: Do the results of the verification tasks imply that the

loopback filter is working as designed?
Answer: Yes, based on the results of the verification tasks, the

applied loopback filter is working as designed.
Step 2.10
Return to the open CLI session with vSRX-1.
From the open CLI session with vSRX-1, issue the run show ospf neighbor and
run show route commands to verify the current state of the OSPF neighbors and route table entries.

inet.0: 17 destinations. 17 routes (17 active, 0 holddown, 0 hidden)

0.0.0.0/0 'k
[Static/5] 5d 07:47:28
> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 * [Direct/0] 5d 07:47:28
> via ge-0/0/1.0
172.18.1.2/32 *
[Local/0] 5d 07:47:28
172.20.66.0/30 * [Direct/0] 5d 07:47:28
> via ge-0/0/7.0
172.20.66.1/32 *
[Local/0] 5d 07:47:28
172.20.77.0/30 * [Direct/0] 5d 07:47:28

> via ge-0/0/8.0

172.20.77.1/32 ■k [Local/0] 5d 07:47:28
172.20.101.0/24 * [Direct/0] 5d 07:47:28
> via ge-0/0/4.0
172.20.101.1/32 * [Local/0] 5d 07:47:28
172.21.0.0/24 * [Static/5] 5d 07:47:28
> to 172.20.101.10 via ge-0/0/4.0
172.21.1.0/24 * [Static/5] 5d 07:47:28
> to 172.20.101.10 via ge-0/0/4.0
172.21.2.0/24 * [Static/5] 5d 07:47:28
> to 172.20.101.10 via ge-0/0/4.0
172.25.11.0/24 * [Direct/0] 3w0d 00:07:26
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 3w0d 00:07:26
192.168.1.1/32 * [Direct/0] 2w6d 23:00:27
> via loO.O
192.168.1.2/32 * [Static/5] 5d 07:47:28
> to 172.20.101.10 via ge-0/0/4.0
224.0.0.5/32 * [OSPF/10] 2w6d 23:00:28, metric 1
MultiRecv

ff02::2/128 k [INET6/0] 3w0d 00:07:32

MultiRecv
Question: Does your device show OSPF neighbor adjacencies or

routes learned through OSPF? Can you explain why?
Answer: As shown in the sample capture, vSRX-1 should not detect

any OSPF neighbors at this time. If you suspect the loopback filter is
the reason for the current state, you are correct. Although the
currently applied loopback filter limits traffic for the specified
protocols, it does not currently account for other host-bound traffic,
such as OSPF, and the firewall filter by default ends with an implied
then discard Stanza. You resolve this issue in subsequent lab
steps.
Step 2.11
Deactivate the firewall filter applied to the loopback interface on vSRX-1 and commit the configuration
change.
lab@vSRX-l# deactivate unit 0 family inet filter

lab@vSRX-l# show
unit 0 {

family inet {
inactive: filter {
input protect-host;
}
address 192.168.1.1/32;
}
}

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 2.12
Issue the run show ospf neighbor and run show route commands again to verify the state of
the OSPF neighbors and verify that the route table entries restored properly.
Address Interface State ID Pri Dead
172.20.77.2 ge-0/0/8.0 Full 192.168.2.1 128 38
172.20.66.2 ge-0/0/7.0 Full 192.168.2.1 128 31


0.0.0.0/0 [Static/5] 5d 07:48:22

> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 [Direct/0] 5d 07:48:22
> via ge-0/0/1.0
172.18.1.2/32 [Local/0] 5d 07:48:22
172.20.66.0/30 [Direct/0] 5d 07:48:22
> via ge-0/0/7.0
172.20.66.1/32 [Local/0] 5d 07:48:22
172.20.77.0/30 [Direct/0] 5d 07:48:22
> via ge-0/0/8.0
172.20.77.1/32 [Local/0] 5d 07:48:22
172.20.101.0/24 [Direct/0] 5d 07:48:22
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 5d 07:48:22
172.20.102.0/24 [OSPF/10] 00:00:04, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
172.21.0.0/24 [Static/5] 5d 07:48:22
> to 172.20.101.10 via ge-0/0/4.0
172.21.1.0/24 [Static/5] 5d 07:48:22
> to 172.20.101.10 via ge-0/0/4.0

172.21.2.0/24 ■k
[Static/5] 5d 07:48:22
> to 172.20.101.10 via ge-0/0/4.0
172.25.11.0/24 * [Direct/0] 3w0d 00:08:20
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 3w0d 00:08:20
192.168.1.1/32 * [Direct/0] 2w6d 23:01:21
> via loO.O
192.168.1.2/32 * [Static/5] 5d 07:48:22
> to 172.20.101.10 via ge-0/0/4.0
192.168.2.1/32 * [OSPF/10] 00:00:04, metric 1
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
192.168.2.2/32 * [OSPF/10] 00:00:04, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
224.0.0.5/32 * [OSPF/10] 2w6d 23:01:22, metric 1
MultiRecv

ff02::2/128 k [INET6/0] 3w0d 00:08:26

MultiRecv
Question: With the firewall filter inactive, does vSRX-1 again see OSPF
neighbor adjacencies and routes?
Answer: As shown in the sample capture, vSRX-1 should again see

OSPF neighbor adjacencies and OSPF routes.
Step 2.13
Navigate to the [edit firewall family inet filter protect-host] hierarchy level.
Restructure the protect-host firewall filter to accomplish the previously stated objectives and also
explicitly allows all other traffic through a term named else-accept that implicitly allows all other
traffic. Include a counter for each defined term. Name each of the counters count -x, where x is the
name of the associated term.
Note
In most firewall filter implementations, you will likely use the

discard action rather than the reject action to avoid
sending notifications back to potential attackers. In this lab, you
might choose the reject action to simplify your testing
verification.

lab@vSRX-l# top edit firewall family inet filter protect-host

lab@vSRX-l# set term limit-icmp from source-address 0/0

lab@vSRX-l# set term limit-icmp from source-address 172.25.11.0/24 except

lab@vSRX-l# set term limit-icmp then count count-limit-icmp

lab@vSRX-l# set term limit-icmp then discard

lab@vSRX-l# set term limit-ssh from source-address 0/0

lab@vSRX-l# set term limit-ssh from source-address 172.25.11.0/24 except

lab@vSRX-l# set term limit-ssh then count count-limit-ssh

lab@vSRX-l# set term limit-ssh then discard

lab@vSRX-l# set term limit-telnet from source-address 0/0

lab@vSRX-l# set term limit-telnet from source-address 172.25.11.0/24 except

lab@vSRX-l# set term limit-telnet then count count-limit-telnet

lab@vSRX-l# set term limit-telnet then discard

lab@vSRX-l# set term else-accept then count count-else-accept

lab@vSRX-l# set term else-accept then accept

lab@vSRX-l# show
term limit-icmp {
from {
source-address {
172.25.11.0/24 except;
0.0.0.0/0;
}
protocol icmp;
}
then {
count count-limit-icmp;
discard;
}
}
term limit-ssh {
from {

source-address {
172.25.11.0/24 except;
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
count count-limit-ssh;
discard;
}
}
term limit-telnet {
from {
source-address {
172.25.11.0/24 except;
0.0.0.0/0;
}
protocol tcp;
port telnet;
}
then {
count count-limit-telnet;
discard;
}
}
term else-accept {
then {
count count-else-accept;
accept;
}
}

lab@vSRX-l#
Step 2.14
Returntothe [edit interfaces loO] hierarchy level and reactivate the protect-host filter.
Issue the commit and-quit command to activate the configuration changes and return to operational
mode.
lab@vSRX-l# top edit interfaces loO

lab@vSRX-l# activate unit 0 family inet filter

lab@vSRX-l# show
unit 0 {
family inet {
filter {
input protect-host;
}
address 192.168.1.1/32;
}

commit complete
lab@vSRX-l>
Step 2.15
Issue the show ospf neighbor and show route commands again to verify that the state of the
OSPF neighbors is Full and that OSPF routes are still present.
lab@vSRX-l> show ospf neighbor
172.20.77.2 ge-0/0/8.0 Full 192.168.2.1 128 36
172.20.66.2 ge-0/0/7.0 Full 192.168.2.1 128 37
lab@vSRX-l> show route

0.0.0.0/0 [Static/5] 5d 07:50:40

> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 [Direct/0] 5d 07:50:40
> via ge-0/0/1.0
172.18.1.2/32 [Local/0] 5d 07:50:40
172.20.66.0/30 [Direct/0] 5d 07:50:40
> via ge-0/0/7.0
172.20.66.1/32 [Local/0] 5d 07:50:40
172.20.77.0/30 [Direct/0] 5d 07:50:40
> via ge-0/0/8.0
172.20.77.1/32 [Local/0] 5d 07:50:40
172.20.101.0/24 [Direct/0] 5d 07:50:40
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 5d 07:50:40
172.20.102.0/24 [OSPF/10] 00:02:22, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
172.21.0.0/24 [Static/5] 5d 07:50:40
> to 172.20.101.10 via ge-0/0/4.0
172.21.1.0/24 [Static/5] 5d 07:50:40
> to 172.20.101.10 via ge-0/0/4.0
172.21.2.0/24 [Static/5] 5d 07:50:40
> to 172.20.101.10 via ge-0/0/4.0
172.25.11.0/24 [Direct/0] 3w0d 00:10:38
> via ge-0/0/0.0
172.25.11.1/32 [Local/0] 3w0d 00:10:38
192.168.1.1/32 [Direct/0] 2w6d 23:03:39
> via loO.O

192.168.1.2/32 ■k
[Static/5] 5d 07:50:40
> to 172.20.101.10 via ge-0/0/4.0
192.168.2.1/32 * [OSPF/10] 00:02:22, metric 1
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
192.168.2.2/32 * [OSPF/10] 00:02:22, metric 2
to 172.20.77.2 via ge-0/0/8.0
> to 172.20.66.2 via ge-0/0/7.0
224.0.0.5/32 * [OSPF/10] 2w6d 23:03:40, metric 1
MultiRecv

ff02::2/128 k [INET6/0] 3w0d 00:10:44

MultiRecv
Question: With the firewall filter updated and reapplied, does your
assigned device still see OSPF neighbor adjacencies and OSPF
routes?
Answer: As shown in the sample capture, your student device should

still show OSPF neighbor adjacencies and OSPF routes.
Step 2.16
Return to the open CLI session with vSRX-VR.
From the open CLI session with vSRX-VR, attempt to ping the IP address assigned to the vSRX-1 loopback
interface from virtual router Juniper-sv.
Note
name when sourcing ICMP traffic from a virtual router.

PING 192.168.1.1 (192.168.1.1): 56 data bytes

25 packets transmitted. 0 packets received. 100% packet loss
Step 2.17
From Juniper-sv, attempt to establish SSH and Telnet sessions with vSRX-1. Use the vSRX-1 loopback
address as the destination address.
Note
name when sourcing traffic from a virtual router.
Note
Use the Ctrl+c sequence to break unresponsive attempts for
FTP, SSH, and Telnet sessions.

lab@vSRX-VR> ssh routing-instance Juniper-SV lab(3192.168.1.1

Trying 192.168.1.1...
lab@vSRX-VR>

Given the current configuration, is this behavior expected?
Answer: As shown in the capture, neither of the session attempts

successfully establishes. Because the session attempts do not use a
source address within the management subnet, the session attempts
should fail by design.
Step 2.18
To confirm that the firewall filter applied to your student device’s loopback interface permits inbound
ICMP echo requests, FTP, SSH, and Telnet traffic destined for the local host and sourced from the
management subnet, attempt the same tests performed in the previous two steps. Perform these tests
from vSRX-VR, but do not specify a routing instance. Use the management IP address assigned to vSRX-1
as the destination address. Refer to the management network diagram as needed.
lab@vSRX-VR> ping 172.25.11.1 rapid count 25
PING 172.25.11.1 (172.25.11.1): 56 data bytes

Question: Does the ping test succeed?
Answer: Yes, the ping test should now succeed because the ICMP
echo requests use a source address within the management subnet.
lab@vSRX-VR> ssh lab@172.25.11.1

Password:
Last login: Fri Feb 7 17:50:01 2020 from 172.25.11.9
lab@vSRX-l> exit
lab@vSRX-VR> telnet 172.25.11.1

Trying 172.25.11.1...
login: lab
Password:

lab@vSRX-l> exit
lab@vSRX-VR>
Answer: Yes, because the session attempts use a source address

within the management subnet, the session attempts should now
succeed.
Question: Do the results of the verification tasks imply that the

loopback filter is working as designed?
Answer: Yes, based on the results of the verification tasks, the applied
loopback filter is working as designed.
Step 2.19
From the open CLI session with vSRX-1, issue the show firewall command to determine if the
counters are incrementing.
lab@vSRX-l> show firewall
Filter: default bpdu filter
Filter: protect-host
Counters:
Name Bytes Packets
count-else-accept 45561 569
count-limit-icmp 1848 22
count-limit-ssh 128 2
count-limit-telnet 64 1
Question: Are the counters for the protect-host filter

incrementing?
Answer: Yes, as illustrated in the sample capture, all counters have a

non-zero value due to the recent tests.

Part 3: Configuring internet Access

In this lab part, you will load the starting configuration for lab parts 3 through 5. Then, you will configure
two VRs— Juniper-svand ACME-svon vSRX-1. These two VRs will connect via ge-0/0/4 and
ge-0/0/5 to the VRs on vSRX-VR of the same name. You will then configure Internet access for these VRs.
Step 3.1
From the open CLI session with vSRX-1, enter configuration mode and load the lab configuration file
using the load override ajsec/lab2-part3-start . configcommand. After the
configuration has been loaded, commit the changes before proceeding.
[edit]
lab@vSRX-l# load override ajsec/Iab2-part3-start.config
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Step 3.2
Return to the CLI session with vSRX-2.
From the open CLI session with vSRX-2, enter configuration mode and load the lab configuration file
using the load override ajsec/lab2-part3-start . configcommand. After the configuration
has been loaded, commit the changes and exit to operational mode.
[edit]
lab@vSRX-2# load override ajsec/Iab2-part3-start.config
[edit]
commit complete
lab@vSRX-2
Step 3.3
From the open CLI session with vSRX-1, navigate to the [edit routing-instances] hierarchy
level. Configure two VRs— Juniper-sv and acme-sv. The Juniper-svW should contain the
ge-0/0/4 interface that directly connects the vSRX-1 device with the Juniper-SV device. Then, the
ACME-SV VR should contain the ge-0/0/5 interface that directly connects the vSRX-1 device with the
ACME-SV device.
[edit]
lab@vSRX-l# edit routing-instances

[edit routing-instances]
lab@vSRX-l# set Jun±per-SV instance-type virtual-router
lab@vSRX-l# set Juniper-SV interface ge-0/0/4
lab@vSRX-l# set ACME-SV instance-type virtual-router
lab@vSRX-l# set ACME-SV interface ge-0/0/5
lab@vSRX-l# show
ACME-SV {
instance-type virtual-router;
}
Juniper-sv {
lab@vSRX-l
Step 3.4
Configure a security policy named internet-access to permit all traffic from the Juniper-sv zone
to the untrust zone. When you are finished, commit your configuration.
lab@vSRX-l# top edit security policies from-zone Juniper-SV to-zone untrust policy
Internet-access
[edit security policies from-zone Juniper-SV to-zone untrust policy

Internet-access]

Internet-access]

Internet-access]

Internet-access]

Internet-access]
lab@vSRX-l# show
match {
source-address any;
application any;

}
then {
permit;
}

Internet-access]
lab@vSRX-l# commit
commit complete

Internet-access]
lab@vSRX-l#
Step 3.5
Return to the open CLI session with vSRX-VR
From the open CLI session with vSRX-VR, ping the Internet host by issuing the ping 172.31.15.1
routing-instance Juniper-SV count 2 command.
lab@vSRX-VR> ping 172.31.15.1 routing-instance Juniper-SV count 2
PING 172.31.15.1 (172.31.15.1): 56 data bytes
36 bytes from 172.20.101.1: Destination Net Unreachable
Vr HL TOS Len ID Fig off TTL Pro cks Dst
4 5 00 0054 385e 0 0000 40 01 760c 172.20.101.10 172.31.15.1

Vr HL TOS Len ID Fig off TTL Pro cks Dst
4 5 00 0054 3861 0 0000 40 01 7609 172.20.101.10 172.31.15.1

Question: Why are the pings not successful?
Answer: The message shows that the next upstream router, the
vSRX-1 device, cannot reach the Internet host.
Step 3.6
Return to the open CLI session established with the vSRX-1 device.
From the open CLI session with vSRX-1, navigate to the [edit routing-instances] hierarchy and
issue the run show route table juniper-sv. inet. 0 and run show route table
acme-sv. inet. 0 commands.
Note
Even though the routing table names have capital letters, it is
not necessary to capitalize any part of the previous commands.

Internet-access]

lab@vSRX-l# top edit routing-instances
lab@vSRX-l# run show route table juniper-sv.inet.0
Juniper-SV.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

172.20.101.0/24 ■k[Direct/0] 00:37:54

> via ge-0/0/4.0
172.20.101.1/32 * [Local/0] 00:37:54
lab@vSRX-l# run show route table acme-sv.inet.0
ACME-SV.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

172.20.201.0/24 k [Direct/0] 00:46:57

> via ge-0/0/5.0
172.20.201.1/32 * [Local/0] 00:46:57
Question: Why is traffic that is destined for the Internet host being
discarded?
Answer: The previous output reveals there is no routing information to

direct traffic towards the Internet host.
Step 3.7
Configure the Juniper-svar\6 ACME-SV routing instances to use the main routing instance’s inet.O
routing table for unknown destinations. When you are finished, commit the configuration.
lab@vSRX-l# set Juniper-SV routing-options static route 0/0 next-table inet.O
lab@vSRX-l# set ACME-SV routing-options static route 0/0 next-table inet.O
lab@vSRX-l# commit
commit complete
Step 3.8
Issue the commands run show route table juniper-sv. inet. 0 and
run show route table acme-sv.inet.0.
0.0.0.0/0 * [Static/5] 00:00:18

to table inet.O
172.20.101.0/24 [Direct/0] 00:49:07
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 00:49:07
lab@vSRX-l# run show route table acme-sv. inet.0

0.0.0.0/0 [Static/5] 00:00:32

to table inet.O
172.20.201.0/24 [Direct/0] 00:49:21
> via ge-0/0/5.0
172.20.201.1/32 [Local/0] 00:49:21
Question: How are the default static routes in the VRs resolving the
next hop?
Answer: The next hop is resolving through the inet.O routing table.
Step 3.9
Return to the open CLI session established with the vSRX-VR device.
From the open CLI session with vSRX-VR, ping the Internet host by issuing the ping 172.31.15.1
routing-instance Juniper-SV count 2 command.
PING 172.31.15.1 (172.31.15.1): 56 data bytes
64 bytes from 172.31.15.1: icmp_seq=0 ttl=63 time=14.789 ms
64 bytes from 172.31.15.1: icmp seq=l ttl=63 time=1.036 ms

Question: Why is the ping test successful?
Answer: The VRs have a default route that resolves through the main
routing instance’s inet.O routing table.
Step 3.10
From the open CLI session with vSRX-1, issue the run show route table inet. 0 command and
examine the routing table.

lab@vSRX-l# run show route table inet.O

0.0.0.0/0 ■k
[Static/5] 00:17:06
> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 * [Direct/0] 00:17:06
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] 00:17:06
172.25.11.0/24 * [Direct/0] 01:13:12
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 01:13:12
192.168.1.1/32 * [Direct/0] 3w0d 00:59:54
> via loO.O
Question: Is there a route in the inet.O routing table to accommodate

for the return ping traffic?
Answer: No. The inet.O routing table does not have a route to either
attached device.
Question: How is the return traffic reaching the attached devices?
Answer: When the session is initially created the return path is

calculated. The return traffic uses the fast path of the flow services
module that bypasses the routing in the inet.O routing table.
Part 4: Configuring inter-VR Communication

In this lab part, you will configure inter-VR communication through the use of the logical tunnel interface.
Step 4.1
From the open CLI session with vSRX-VR, test communication between the Juniper-SV and ACME-SV
customer devices that are directly connected to the vSRX-1 device. Issue the ping 172.20.201.10
routing-instance Juniper-SV count 2 and telnet 172.20.201.10
routing-instance Juniper-SVcommands.
PING 172.20.201.10 (172.20.201.10): 56 data bytes


lab@vSRX-VR> telnet 172.20.201.10 routing-instance Juniper-SV

Trying 172.20.201.10...
telnet: connect to address 172.20.201.10: Operation timed out
telnet: Unable to connect to remote host
Question: What does the communication attempts reveal?
Answer: The attempts reveal that the Juniper-SV and ACME-SV

devices cannot communicate using Telnet or Ping.
Step 4.2
From the open CLI session with vSRX-1, issue the run show route table junlper-sv. inet. 0
and run show route table acme-sv. inet. 0 commands.
lab@vSRX-l# run show route table jun±per-sv.inet.0

0.0.0.0/0 [Static/5] 00:51:07

to table inet.O
172.20.101.0/24 [Direct/0] 01:39:56
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 01:39:56

0.0.0.0/0 [Static/5] 00:51:23

to table inet.O
172.20.201.0/24 [Direct/0] 01:40:12
> via ge-0/0/5.0
172.20.201.1/32 [Local/0] 01:40:12
Question: Why is the communication between the Juniper-SV device

and ACME-SV device failing?
Answer: The VRs do not have routes to each other's directly

connected LANs.

Question: What can you do to fix this issue?
Answer: RIB groups or a logical tunnel (It) interface can be used to

provide communication between the VRs. Also, do not forget that you
should configure a security policy to allow the traffic.
Step 4.3
Navigating to the [edit interfaces lt-0/0/0] hierarchy level. Configure unit 1 with the IP
address of 172.21.1.1/30, and unit 2 with the IP address of 172.21.1.2/30. Configure peering between
the two units, and configure both units with Ethernet encapsulation.
lab@vSRX-l# up 1 edit interfaces lt-0/0/0
[edit interfaces lt-0/0/0]

lab@vSRX-l# set unit 1 family inet address 172.21.1.1/30

lab@vSRX-l# set unit 1 peer-unit 2

lab@vSRX-l# set unit 1 encapsulation ethernet


lab@vSRX-l# set unit 2 peer-unit 1

lab@vSRX-l# set unit 2 encapsulation ethernet

lab@vSRX-l# show
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 172.21.1.1/30;
}
}
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 172.21.1.2/30;
}
}

lab@vSRX-l#

Step 4.4
Associate the lt-0/0/0.1 interface with the Juniper-svinstance. Associate the lt-0/0/0.2 interface
with the ACME-VR instance.
lab@vSRX-l# up 2 edit routing-instances
lab@vSRX-l# set Juziiper-SV interface lt-0/0/0.1
lab@vSRX-l# set ACME-SV interface lt-0/0/0.2
lab@vSRX-l#
Step 4.5
Configure OSPF in the Juniper-svan6 acme-svWs. Place the lt-0/0/0.1 and the
ge-0/0/4 interface inside area 0 in the Juniper-sv\/R. Place the lt-0/0/0.2 and the
ge-0/0/5 interface inside area 0 in the acme-svVR. Add the passive option to both
ge-0/0/4 and ge-0/0/5 interfaces inside of OSPF for their respective VRs. When you are finished
commit the configuration.
lab@vSRX-l# set Juniper-SV protocols ospf area 0 interface lt-0/0/0.1
lab@vSRX-l# set Juniper-SV protocols ospf area 0 interface ge-0/0/4 passive
lab@vSRX-l# set ACME-SV protocols ospf area 0 interface lt-0/0/0.2
lab@vSRX-l# set ACME-SV protocols ospf area 0 interface ge-0/0/5 passive
lab@vSRX-l# show
ACME-SV {
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface lt-0/0/0.2;
interface ge-0/0/5.0 {
passive;
}
}
}
}

}
Juniper-SV {
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;
}
}
protocols {
ospf {
area 0.0.0.0 {
passive;
}
}
}
}
}
lab@vSRX-l# commit
commit complete
Step 4.6
Issue the run show ospf interface command.
lab@vSRX-l# run show ospf interface
OSPF instance is not running
Question: Why is the OSPF instance not running?
Answer: OSPF is configured under the Juniper-svar\6 acme-sv

VRs. The previous command is displaying OSPF information for the
main routing instance.
Step 4.7
Issue the run show ospf interface instance Juniper-SV3^6 run show ospf
interface instance ACME-SVcommands.
lab@vSRX-l# run show ospf interface instance Juniper-SV
Interface state Area DR ID BDR ID Nbrs
ge-0/0/4.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lt-0/0/0.1 DR 0.0.0.0 172.20.101.1 0.0.0.0 0

lab@vSRX-l# run show ospf interface instance ACME-SV
Interface State Area DR ID BDR ID Nbrs
ge-0/0/5.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lt-0/0/0.2 DR 0.0.0.0 172.20.201.1 0.0.0.0 0
Question: Are any OSPF neighbors detected on the lt-0/0/0

interfaces?
Answer: No OSPF neighbors are detected on the lt-0/0/0 interfaces.
Step 4.8
Test connectivity between the Juniper-VR and acme-vr instances by issuing the run ping
172.21.1.2 routing-instance Juniper-SV count 2command.
lab@vSRX-l# run ping 172.21.1.2 routing-instance Jiiniper-SV count 2
PING 172.21.1.2 (172.21.1.2): 56 data bytes

Question: What is a possible reason for the ping test and the OSPF
adjacency failures?
Answer: A possible reason for the ping test and OSPF adjacency
failures is a security zone issue.
Step 4.9
Issue the run show security zones command.
lab@vSRX-l# run show security zones
Security zone: ACME-SV
Interfaces bound: 1
Interfaces:
ge-0/0/5.0

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


Interfaces bound: 1
Interfaces:
ge-0/0/1.0

Interfaces bound: 0
Interfaces:
Question: Are the logical tunnel interfaces bound to any security

zones?
Answer: No. The logical tunnel interfaces are not bound to any security
zones.
Step 4.10
Bind the lt-0/0/0.1 interface to the Juniper-svzone. Bind the lt-0/0/0.2 interface to the acme-sv
zone. Allow both logical tunnel interfaces to process ping requests and OSPF packets. When you are
finished, commit the configuration.
lab@vSRX-l# top edit security zones security-zone Junlper-SV
[edit security zones security-zone Juniper-SV]

lab@vSRX-l# set interfaces lt-0/0/0.1 host-inbound-traffic system-services ping

lab@vSRX-l# set interfaces lt-0/0/0.1 host-inbound-traffic protocols ospf

lab@vSRX-l# up 1 edit security-zone ACME-SV
[edit security zones security-zone ACME-SV]

lab@vSRX-l# set interfaces lt-0/0/0.2 host-inbound-traffic system-services ping

lab@vSRX-l# set interfaces lt-0/0/0.2 host-inbound-traffic protocols ospf

lab@vSRX-l# up

lab@vSRX-l# show security-zone Juniper-SV
interfaces {
ge-0/0/4.0;
lt-0/0/0.1 {
system-services {
ping;

}
protocols {
ospf ;
}
}
}
}

lab@vSRX-l# show security-zone ACME-SV
interfaces {
ge-0/0/5.0;
lt-0/0/0.2 {
system-services {
ping;
}
protocols {
ospf ;
}
}
}
}

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 4.11
Test connectivity between the Juniper-svand acme-svinstances by issuing the
run ping 172.21.1.2 routing-instance Juniper-SV count 2 command.
lab@vSRX-l# run ping 172.21.1.2 routing-instance Jiiniper-SV count 2
PING 172.21.1.2 (172.21.1.2): 56 data bytes

Question: Is the ping test successful?
Answer: Yes. The ping test is successful.
Step 4.12
Issue the run show ospf interface instance Juniper-SV a nd run show ospf
interface instance ACMB-SVcommands.

lab@vSRX-l# run show ospf interface instance Juniper-SV
ge-0/0/4.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lt-0/0/0.1 BDR 0.0.0.0 172.20.201.1 172.20.101.1 1

lab@vSRX-l# run show ospf interface instance ACME-SV
ge-0/0/5.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lt-0/0/0.2 DR 0.0.0.0 172.20.201.1 172.20.101.1 1
Question: Are any OSPF neighbors detected on the lt-0/0/0

interfaces?
Answer: Yes. OSPF neighbors are detected on the

lt-0/0/0 interfaces.
Step 4.13
Check the status of the OSPF neighbor adjacencies by issuing the run show ospf neighbor
instance all command.
Note
It might take a minute for the OSPF adjacencies to reach the
Full state.

lab@vSRX-l# run show ospf neighbor instance all
Instance: ACME-SV
172.21.1.1 lt-0/0/0.2 Full 172.20.101.1 128 34
Instance: Juniper-SV
172.21.1.2 lt-0/0/0.1 Full 172.20.201.1 128 33
Question: Which states are the OSPF adjacencies in?
Answer: The OSPF adjacencies should reach the Full state.
Step 4.14
Examine the Juniper-svar\6 acme-SV VR routing tables.


0.0.0.0/0 [Static/5] 01:15:42

to table inet.0
172.20.101.0/24 [Direct/0] 02:04:31
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 02:04:31
172.20.201.0/24 [OSPF/10] 00:03:39, metric 2
> to 172.21.1.2 via lt-0/0/0.1
172.21.1.0/30 [Direct/0] 00:12:19
> via lt-0/0/0.1
172.21.1.1/32 [Local/0] 00:12:19
Local via lt-0/0/0.1
224.0.0.5/32 [OSPF/10] 00:12:21, metric 1
MultiRecv


0.0.0.0/0 [Static/5] 01:16:05

to table inet.0
172.20.101.0/24 [OSPF/10] 00:04:02, metric 2
> to 172.21.1.1 via lt-0/0/0.2
172.20.201.0/24 [Direct/0] 02:04:54
> via ge-0/0/5.0
172.20.201.1/32 [Local/0] 02:04:54
172.21.1.0/30 [Direct/0] 00:12:42
> via lt-0/0/0.2
172.21.1.2/32 [Local/0] 00:12:42
224.0.0.5/32 [OSPF/10] 00:12:44, metric 1
MultiRecv
Question: Are OSPF routes being shared between the Juniper-sv

and ACME-svVRs?
Answer: Yes. OSPF routes are being shared.
Step 4.15
Configure a security policy named intra-VR-access-Jio permit all traffic from the Juniper-sv
zone to the Juniper-sv zone.
lab@vSRX-l# top edit security policies from-zone Juniper-SV to-zone Juniper-SV
policy Intra-VR-access-J
[edit security policies from-zone Juniper-SV to-zone Juniper-SV policy

Intra-VR-access-J]


Intra-VR-access-J]

Intra-VR-access-J]

Intra-VR-access-J]

Intra-VR-access-J]
lab@vSRX-l# show
match {
source-address any;
application any;
}
then {
permit;
}

Intra-VR-access-J]
lab@vSRX-l#
Step 4.16
Configure a security policy named intra-VR-access-Alo permit all traffic from the acme-sv zone to
the ACME-SV zone. When you are finished, commit your configuration.
Intra-VR-access-J]
lab@vSRX-l# up 2 edit from-zone ACME-SV to-zone ACME-SV policy Intra-VR-access-A
[edit security policies from-zone ACME-SV to-zone ACME-SV policy Intra-VR-access-A]





lab@vSRX-l# show
match {
source-address any;
application any;
}
then {
permit;
}
[edit security policies from-zone ACME-SV to-zone ACME-SV policy

Intra-VR-access-A]
lab@vSRX-l# commit
commit complete
[edit security policies from-zone ACME-SV to-zone ACME-SV policy

Intra-VR-access-A]
lab@vSRX-l#
Question: Why was it necessary to create two intra-zone security

policies to accommodate the intra-VR traffic?
Answer: Each VR is considered a different routing device and so

traffic enters and leaves in the same zone of each VR.
Step 4.17
From the open CLI session with vSRX-VR, test communication between the Juniper-SV and ACME-SV
customer devices that are directly connected to the vSRX-1 device. Issue the
telnet 172.20.201.10 routing-instance Juniper-SV com ma nd.
lab@vSRX-VR> telnet 172.20.201.10 routing-instance Juniper-SV
Trying 172.20.201.10...
login:
Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.
Step 4.18
Log in to the vSRX-VR device with username lab and password labl23 to ensure that the Telnet
session does not time out.
login: lab
Password:
lab@vSRX-VR>
Step 4.19
Return to the open session established with the vSRX-1 device.

From the vSRX-1 device, find the recently created Telnet session in the session table.
Intra-VR-access-J]
lab@vSRX-l# run show security flow session application telnet
Session ID: 16746, Policy name: Inter-VR-access-J/6, Timeout: 1768, Valid
Pkts : 27, Bytes: 1570,
Out: 172.20.201.10/23 -- 172.20.101.10/50838 ; tcp. Conn Tag: 0x0, If: lt-0/0/0.1.
Pkts : 21, Bytes: 1392,
Session ID: 16747, Policy name: Inter-VR-access-A/7, Timeout: 1768, Valid

In: 172.20.101.10/50838 172.20.201.10/23;tcp. Conn Tag: 0x0, If: lt-0/0/0.2.
Pkts : 27, Bytes: 1570,
Out: 172.20.201.10/23 -- 172.20.101.10/50838 ; tcp. Conn Tag: 0x0, If: ge-0/0/5.0.
Pkts : 21, Bytes: 1392,
Total sessions: 2
Question: Why are two Telnet sessions shown in the output?
Answer: The Junos OS creates two sessions because each VR is

treated as a separate router.
Question: Which policies are being triggered by the Telnet traffic?
Answer: The Telnet traffic is using the inter-VR-access-Jand

the Inter-VR-access-A policies.
Step 4.20
From the open CLI session with vSRX-VR, exit the Telnet session.
lab@vSRX-VR> exit
lab@vSRX-VR>
Part 5: Configuring Filter-Based Forwarding

In this lab part, you will configure filter-based forwarding for traffic between the ACME-SV and ACME-WF
devices.
Step 5.1
From the open CLI session with vSRX-1, configure the ge-0/0/7 interface with the
172.19.1.1/30 prefix.


lab@vSRX-l# top edit interfaces ge-0/0/7
[edit interfaces ge-0/0/7]


lab@vSRX-l# show
unit 0 {
family inet {
address 172.19.1.1/30;
}
}

lab@vSRX-l
Step 5.2
Place the ge-0/0/7 interface in the untrust zone.
lab@vSRX-l# top edit security zones security-zone untrust
[edit security zones security-zone untrust]


lab@vSRX-l#
Step 5.3
Configure a new security policy named fbf-acme-svIo permit any traffic that is coming from the
ACME-SV zone and going towards the untrust zone.
lab@vSRX-l# top edit security policies from-zone ACME-SV to-zone untrust policy
FBF-ACME-SV
[edit security policies froiti-zone ACME-SV to-zone untrust policy FBF-ACME-SV]

lab@vSRX-l# set match source-address ACME-SV



[edit security policies from-zone ACME-SV to-zone untrust policy FBF-ACME-SV]

lab@vSRX-l#
Step 5.4
Configure a RIB group named acme-to-Main that will copy interface routes located in the
ACME-SV. inet.O table to the inet.O table. Configure the acme-svVR to place its interface routes into
the ACME-to-Main RIB group. When you are finished, commit the configuration.

[edit security policies from-zone ACME-SV to-zone untrust policy FBF-ACME-SV]

lab@vSRX-l# top edit routing-options rib-groups ACME-to-Main
[edit routing-options rib-groups ACME-to-Main]

lab@vSRX-l# set import-rib [ ACME-SV.inet.0 inet.O ]
[edit routing-options rib-groups]

lab@vSRX-l# up 2
[edit routing-options]
lab@vSRX-l# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
rib-groups {
ACME-to-Main {
import-rib [ ACME-SV.inet.0 inet.O ];
}
}
lab@vSRX-l# top edit routing-instances ACME-SV routing-options
[edit routing-instances ACME-SV routing-options]

lab@vSRX-l# set interface-routes rib-group inet ACME-to-Main

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 5.5
Issue the run show route command.
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

0.0.0.0/0 ■k
[Static/5] 00:08:37
> to 172.18.1.1 via ge-0/0/1.0
172.18.1.0/30 * [Direct/0] 00:08:37
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] 00:08:37
172.19.1.0/30 * [Direct/0] 00:00:03
> via ge-0/0/7.0
172.19.1.1/32 * [Local/0] 00:00:03
172.20.201.0/24 * [Direct/0] 00:00:03
> via ge-0/0/5.0
172.20.201.1/32 * [Local/0] 00:00:03

172.21.1.0/30 [Direct/0] 00:00:03

> via lt-0/0/0.2
172.21.1.2/32 [Local/0] 00:00:03
172.25.11.0/24 [Direct/0] 01:51:23
> via ge-0/0/0.0
172.25.11.1/32 [Local/0] 01:51:23
192.168.1.1/32 [Direct/0] 3w0d 01:38:05
> via loO.O

0.0.0.0/0 [Static/5] 00:50:52

to table inet.O
172.20.101.0/24 [OSPF/10] 00:33:12, metric 2
> to 172.21.1.1 via lt-0/0/0.2
172.20.201.0/24 [Direct/0] 00:50:52
> via ge-0/0/5.0
172.20.201.1/32 [Local/0] 00:50:52
172.21.1.0/30 [Direct/0] 00:35:21
> via lt-0/0/0.2
172.21.1.2/32 [Local/0] 00:35:21
224.0.0.5/32 [OSPF/10] 00:35:22, metric 1
MultiRecv

0.0.0.0/0 [Static/5] 00:50:52

to table inet.O
172.20.101.0/24 [Direct/0] 00:50:52
> via ge-0/0/4.0
172.20.101.1/32 [Local/0] 00:50:52
172.20.201.0/24 [OSPF/10] 00:33:12, metric 2
> to 172.21.1.2 via lt-0/0/0.1
172.21.1.0/30 [Direct/0] 00:35:21
> via lt-0/0/0.1
172.21.1.1/32 [Local/0] 00:35:21
224.0.0.5/32 [OSPF/10] 00:35:22, metric 1
MultiRecv
inet6.0: 1 destinations. 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 *[INET6/0] 3w0d 02:45:10

MultiRecv
ACME-SV.inet6.0: 1 destinations. 1 routes (1 active, 0 holddown, 0 hidden)


ff02::2/128 * [INET6/0] 00:50:52

MultiRecv
Juniper-SV.inet6.0: 1 destinations. 1 routes (1 active, 0 holddown, 0 hidden)

+ = Active Route, = Last Active, * = Both
ff02::2/128 ■k
[INET6/0] 00:50:52
MultiRecv
Question: Are the interface routes in the acme-sv. inet.O routing

table present in the inet.O routing table?
Answer: Yes. The interface routes in the acme-sv. inet.O routing

table should be present in the inet.O routing table.
Question: In the next several steps, you enable filter-based forwarding

to send traffic between the ACME-SV and ACME-WF devices over the
ge-0/0/7 interface. Why was it necessary to copy these routes into the
inet.O routing table on vSRX-1?
Answer: You will be sending traffic from the ACME-SV device to the
ACME-WF device and this traffic will return on the ge-0/0/7 interface
on the vSRX-1 device. This interface is located in the main routing
instance. The main routing instance uses the inet.O routing table to
resolve the destination address. Because the route to the ACME-SV
device is located inside the acme-sv. inet.O routing table, the main
routing instance does not have a method to send traffic to the
ACME-WF device by default. Copying routes from the acme-sv. inet.O
routing table to the inet.O routing table allows this traffic to be sent to
the ACME-SV device when it arrives on the vSRX-1 device.
Step 5.6
Configure a forwarding routing instance named FBF-ins tance. Configure a default static route that will
send all traffic to the vSRX-2 device over the ge-0/0/7 interface.
lab@vSRX-l# top edit routing-instances FBF-instance
[edit routing-instances FBF-instance]

lab@vSRX-l# set instance-type forwarding

lab@vSRX-l# set routing-options static route 0/0 next-hop 172.19.1.2


lab@vSRX-l# show
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.19.1.2;
}
}
lab@vSRX-l#
Step 5.7
Configure the fbf- filter firewall filter to send any traffic destined to the acme-wf device to the
FBF-instance routing instance. Configure a counter named FBF-counter to count any packets that
match the filter.
lab@vSRX-l# top edit firewall family inet filter FBF-filter term FBF
[edit firewall family inet filter FBF- ilter term FBF]

lab@vSRX-l# set from destination-address 172.20.202.10
[edit firewall family inet filter FBF-fliter term FBF]

lab@vSRX-l# set then routing-instance FBF-instance
[edit firewall family inet filter FBF-fliter term FBF]

lab@vSRX-l# set then count FBF-counter
[edit firewall family inet filter FBF- Liter term FBF]

lab@vSRX-l# up
[edit firewall family inet filter FBF-fliter]

lab@vSRX-l# show
term FBF{
from {
destination-address {
172.20.202.10/32;
}
}
then {
count FBF-counter;
routing-instance FBF-instance;
}
}
[edit firewall family inet filter FBF-filter]

lab@vSRX-l#
Step 5.8
Apply the fbf- filter firewall filter as an input filter on the ge-0/0/5 interface. When you are finished J
commit the configuration.

[edit firewall family inet filter FBF-fliter]
lab@vSRX-l# top edit interfaces ge-0/0/5 unit 0

[edit interfaces ge-0/0/5 unit 0]

lab@vSRX-l# set family inet filter input FBF-filter

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 5.9
From the open CLI session with vSRX-VR, issue the command ping 172.20.202.10
routing-instance ACME-sv count 2 to test communication between the ACME-SV and
ACME-WF customer devices.
lab@vSRX-VR> ping 172.20.202.10 routing-instance ACME-SV count 2
PING 172.20.202.10 (172.20.202.10): 56 data bytes
Vr HL TOS Len ID Fig off TTL Pro cks Src Dst
4 5 00 0054 b4dc 0 0000 40 01 daSe 172.20.201.10 172.20.202.10

4 5 00 0054 b4e9 0 0000 40 01 daSl 172.20.201.10 172.20.202.10
- 172.20.202.10 ping statistics ---

Answer: No. The ping test is not successful.
Step 5.10
Return to the open session established with the vSRX-1 device.
From the vSRX-1 device, issue the run show firewall filter fbf- filter command.
lab@vSRX-l# run show firewall filter FBF-filter
Filter: FBF-fliter
Counters:
Name Bytes Packets
FBF-counter 168 2

Question: Is the fbf-filter firewall filter being applied to this

traffic?
Answer: Yes. The filter is being applied to this traffic as the counter is
incrementing.
Question: Where is the fbf-filter sending this traffic?
Answer: The fbf-filter is sending this traffic to the

FBF-instance routing instance.
Step 5.11
Issue the run show route table FBF-instance. inet. 0 command.
lab@vSRX-l# run show route table FBF-instance.inet.0

lab@vSRX-l#
Question: Why is the FBF-instance failing to forward the traffic?
Answer: The FBF-instance routing instance does not have any

routing information in its inet.O routing table.
Question: How can you put the necessary routing information in this
routing instance?
Answer: The necessary routing information can be placed in the

FBF-instance routing instance through the use of RIB groups.
Step 5.12
Configure the Main-to-FBF RIB group to copy interface routes from the inet. 0 routing table to the
FBF-instance. Inet. 0 routing table. Configure a policy to allow only the
172.19.1.0/30 prefix to be copied from the inet. 0 routing table. When you are finished, commit the
configuration and exit to operational mode.
[edit interfaces vlan unit 201]
lab@vSRX-l# top edit policy-options policy-statement only-172.19.1.0/30 term
accept-route
[edit policy-options policy-statement only-112.19.1.0/30 term accept-route]

lab@vSRX-l# set from interface ge-0/0/7


lab@vSRX-l# set to rib FBF-instance.inet.0
[edit policy-options policy-statement only-112.19.1.0/30terTa accept-route]

lab@vSRX-l# set then accept

lab@vSRX-l# up
[edit policy-options policy-statement only-112.19.1.0/30]

lab@vSRX-l# set term reject-routes then reject

lab@vSRX-l# show
term accept-route {
from interface ge-0/0/7.0;
to rib FBF-instance.inet.0;
then accept;
}
term reject-routes {
then reject;
}
lab@vSRX-l# top edit routing-options rib-groups Main-to-FBF
[edit routing-options rib-groups Main-to-FBF]

lab@vSRX-l# set import-rib [ inet.O FBF-instance.inet.0 ]

lab@vSRX-l# set import-policy only-112.19.1.0/30

lab@vSRX-l# up 2
lab@vSRX-l# set interface-routes rib-group inet Main-to-FBF
lab@vSRX-l# show
interface-routes {
rib-group inet Main-to-FBF;
}
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
rib-groups {
ACME-to-Main {
import-rib [ ACME-SV.inet.0 inet.O ];
}
Main-to-FBF {
import-rib [ inet.O FBF-instance.inet.0 ];
import-policy only-172.19.1.0/30;
}
}

commit complete
lab@vSRX-l>
Step 5.13
Issue the show route table FBF-instance. Inet.Q connnnand and examinethe routing table.
lab@vSRX-l> show route table FBF-instance.0
FBF-instance.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

0.0.0.0/0 [Static/5] 00:01:21

> to 172.19.1.2 via ge-0/0/7.0
172.19.1.0/30 [Direct/0] 00:01:21
> via ge-0/0/7.0
Question: Why are only two routes in this routing table?
Answer: You placed the 172.19.1.0/30 prefix in the routing table

through the Main-to-FBFRIB group. The 0. 0. 0. O/Oprefw is now
resolvable because the next hop of 172.19.1,2. is reachable.
Step 5.14
From the open CLI session with vSRX-VR, issue the command ping 172.20.202.10
routing-instance ACME-sv count 2 to establish communication between the ACME-SV and
ACME-WF customer devices.
lab@vSRX-VR> ping 172.20.202.10 routing-instance ACME-SV count 2
PING 172.20.202.10 (172.20.202.10): 56 data bytes

Answer: Yes, the ping should be successful. If not check your

configuration or your instructor.
Step 5.15
Initiate a Telnet session from the ACME-SV device to the ACME-WF device. Issue the
telnet 172.20.202.10 routing-instance ACME-SVcommand.

lab@vSRX-VR> telnet 172.20.202.10 routing-instance ACME-SV

Trying 172.20.202.10...
Escape character is ] ' .
login:
Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.
Step 5.16
Log in to the vSRX-VR device with username lab and password labl23 to ensure that the Telnet
session does not time out.
login: lab
Password:
lab@vSRX-VR>
Step 5.17
From the open CLI session with vSRX-1, issue the command show security flow session
application telnet and examine the session table.
lab@vSRX-l> show security flow session application telnet
Session ID: 16191, Policy name: FBF-ACME-SV/4, Timeout: 1778, Valid
Pkts: 28, Bytes: 1620,
Out: 172.20.202.10/23 -- 172.20.201.10/53752;tcp. Conn Tag: 0x0, If: ge-0/0/7.0.
Pkts : 22, Bytes: 1440,
Total sessions: 1
Question: Which interfaces are in use for the Telnet traffic?
Answer: The ge-0/0/5 and the ge-0/0/7 interfaces are being used for
the Telnet session.
Step 5.18
From the open CLI session with vSRX-VR, exit the session and then log out of the vSRX-VR device.
lab@vSRX-VR> exit
Connection closed by foreign host
lab@vSRX-VR> exit

Step 5.19
From the open CLI session with vSRX-1, log out using the exit command.
lab@vSRX-l> exit
Step 5.20
Return to the open CLI session with vSRX-2
From the open CLI session with vSRX-2, log out using the exit command.
lab@vSRX-2 exit
STOP
Tell your instructor that you completed this lab.

rTyr;
I
vSRX-1 5
ATP Cloud
vSRX-2 ESS
O ge-0/0/0 (on all student devices)
rr^Ttr Physical
Virtual Desktop / Gateway Desktops
vSRX-VR tS 172.25.11.254 1
rrhTTi
1
Internet
vQFX-1 tataafg*! Console and
VNC Connections
Junos
Space Tt
Policy
Hypervisor
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
c
Lab Environment
3

Gateway 172.25.11.254
© 2020 Juniper Networks, Inc. All Rights Reserved

juniper
NETWORKS

Network Diagram: Firewall Filters Parts 1-2

Internet Host
c 3
Internet
172.31.15.1
%
-
\
** fda2;:/126 \
.1 •1)
Qe-QIQI7 .1 172,20,66,0/30 ,2) ge-0/0/7 \
vSRX-1 vSRX-2
loO: 192.168.1.1 loO: 192.168.2.1
t ge-0/0/8 (.1) 172.20.77.0/30 (.2) ge-0/0/8 1
fda9::1 fda9::2
(.1) fdal ;:/126 (.1) I
(•1) ge-0/0/4.0 ge-0/0/4.0 (.1) I
I
172.20.101.0/24 172.20.102.0/24
I
OSPFArea O.O.O.O
(.10) /
(.10)
172.21.0.0/24 I
Juniper-WF
172.21.1.0/24
Juniper-SV
loO: 192.168.2.2
loO: 192.168.1.2
172.21.2.0/24
© 2020 Juniper Networks, Inc. All Rights Reserved.

JuniperBusiness Use Only
juniper
NETWORKS
Network Diagram: Firewall Filters Parts 3-5

Internet Host
c ]
Internet
172.31.15.1
.-S’"
ge-0/0/7 (.1) 172.19.1.0/30 (.2) ge-QIQI7
vSRX-1
ge-0/0/4 /{A} (.1)\96‘0/0/5 ge-0/0/4 /( I) (.1)\ge-0/0/5
172.20.101.0/24 172.20.202.0/24
172.20.201.0/24 vSRX-VR 172.20.102.0/24
(•10) (•10) (.10) (•10)
Juniper-SV ACME-SV Juniper-WF ACME-WF

juniper
NETWORKS

Lab
Troubleshooting Security Zones and Policies
Overview
In this lab, you will troubleshoot zones and policies. You will use the Junos CLI to analyze trace log files to
determine the causes for detected problems. Then, you will define and implement the solutions to the
problems.
In this lab, you will perform the following tasks:
• Troubleshoot security zones.
• Troubleshoot security policies.
Implement solutions.
www.juniper.net Troubleshooting Security Zones and Policies • Lab 3-1

Part 1: Accessing Your Device and Verifying Connectivity

In this lab part, you will use the command-line interface (CLI) to log in to the vSRX-1, vSRX-2, and vSRX-VR
devices. Next, you will load the starting configuration for the lab.
Note
Depending on the class setup, the lab equipment might be

remote from your physical location. The instructor will provide
you the details needed to access your devices.
step 1.1
You will primarily configure the vSRX-1 device. The vSRX-2 and vSRX-VR devices are already configured for
you. Consult the Management Network Diagram to determine the management addresses of your
devices.

devices?
Answer: The answer varies between delivery environments. The

sample output examples in this lab are from the vSRX-1 device, which
has an IP address of 172.25.11.1.
Step 1.2
Access the CLI on the vSRX-1 device using SSH or console as directed by your instructor. Log in with the
username lab and password labl23. Enter configuration mode and load the lab3-start. config
from the a j sec directory. Commit the configuration when complete and exit to operational mode.
FreeBSD/amd64 (vSRX-1) (ttyuO)
login: lab
Password:
[edit]
lab@vSRX-l# load override a.jsec/lab3-start.config
load complete

commit complete
lab@vSRX-l>
Step 1.3
Lab 3-2 • Troubleshooting Security Zones and Policies www.juniper.net

Step 1.4
user name lab and password labl23. Enter configuration mode and load the lab3-stdrt. config
from the a J sec directory. Commit the configuration and exit to operational mode when complete.
Note
You might receive a warning message after committing the

configuration indicatingthattheSRXmust be rebooted. If this is
the case, then reboot the SRX by typing request system
reboot from operational mode.
login: lab
Password:
Last login: Fri May 1 21:07:26 2020 from 172.25.11.254
[edit]
load complete

commit complete
lab@vSRX-2
Step 1.5
Access the CLI on the vSRX-VR device using SSH or console as directed by your instructor. Log in with the
Note

FreeBSD/amd64 (vSRX-VR) (ttyuO)
login: lab
Password:
[edit]
lab@vSRX-VR# load override ajsec/lab3-start.config
load complete


commit complete
lab@vSRX-VR>
Step 1.6
From the open session with vSRX-1, check the status of your configured Gigabit Ethernet and loopback
interfaces using the show interfaces terse | match ’’ge I lo I fxp” command.
lab@vSRX-l> show interfaces terse | match ’’ge | lo | fxp"
Interface Admin Link Proto Local Remote
ge-0/0/0 down down
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.18.1.2/30
ge-0/0/2 up up
ge-0/0/3 up up
ge-0/0/4 up up
ge-0/0/4.0 up up inet 10.10.101.1/24
ge-0/0/5 up up
ge-0/0/5.0 up up inet 10.10.102.1/24
ge-0/0/6 up up
up up
up up
fxpO up up
fxpO.0 up up inet 172.25.11.1/24
loO up up
loO.O up up inet 192.168.1.1 0/0
100.16384 up up inet 127.0.0.1 0/0
100.16385 up up inet 10.0.0.1 0/0
100.32768 up up
Question: What is the administrative status and link status of your

configured interfaces?
Answer: As shown in the output, the administrative status and link

status of the configured interfaces should all indicate a status of up.
Question: What is the status of your management interface? (Refer to

the Management Network Diagram as needed.)
Answer: The management interface isfxpO.O and should also indicate

an administrative status and link status of up.

Step 1.7
Return to the established session with vSRX-VR.
On the vSRX-VR device, verify reachability from each routing instance to the directly connected interface
on the vSRX-1 device by using the ping command. Be sure to source your ping from the correct routing
instance.
lab@vSRX-VR> ping 10.10.101.1 count 3 routing-instance vrlOl
PING 10.10.101.1 (10.10.101.1): 56 data bytes
64 bytes from 10.10.101.1: icmp_seq=l ttl=64 time=0.998 ms
64 bytes from 10.10.101.1: icmp seq=2 ttl=64 time=0.884 ms

lab@vSRX-VR> ping 10.10.102.1 count 3 routing-instance vrl02

PING 10.10.102.1 (10.10.102.1): 56 data bytes

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

If you experience different behavior, then notify your instructor.
Part 2: Troubleshooting Zones

In this lab part, you will troubleshoot problems related to security zones. You first experience the problem
and use CLI tools to find the root cause. Then define the solution and resolve the problem.
Step 2.1
On the vSRX-VR device, test the connectivity from the vrlOl routing instance to the vSRX-1 device
loopback address.
PING 192.168.1.1 (192.168.1.1): 56 data bytes


Question: Was the ping successful?
Answer: As indicated by the output, the ping is not successful. If you

experience different behavior please notify your instructor.
Step 2.2
View the forwarding decision on vrlOl to the vSRX-1 device loopback address.
lab@vSRX-VR> show route 192.168.1.1 table vrlOl.inet.O
vrlO1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

0.0.0.0/0 [Static/5] 22:06:58

> to 10.10.101.1 via ge-0/0/7.0
Question: Does the vrlOl routing instance make a correct

forwarding decision?
Answer: As indicated by the output, vrl 01 has the correct route to

reach the vSRX-1 device loopback interface, as depicted in the lab
diagrams. If the route shown is incorrect, then notify your instructor.
Question: Based on the gathered information, can you tell which

device seems to be dropping the packets?
Answer: The pings are sent from vrl OllQ vSRX-1, and vrl 01 uses
the correct interface for vSRX-1, so the vSRX-1 seems to be the device
discarding the packets.
step 2.3
Return to the session established with the vSRX-1 device.
On the vSRX-1 device, check the zone assignment for the loopback interface loO . 0 and check to see if
ping is allowed in host-inbound-traffic.
lab@vSRX-l> show interfaces loO.O | find security
Security: Zone: Null
Protocol inet, MTU: Unlimited
Max nh cache: 0, New hold nh limit: 0, Curr nh ent: 0, Curr new hold ent: 0,
NH drop ent: 0
Flags: Sendbeast-pkt-to-re
Addresses, Flags: Is-Default Is-Primary
Local: 192.168.1.1

Question: What can you tell from the command output?
Answer: The loO. 0 interface is assigned to the Null zone and has
notallowed anything in host-inbound-traffic. If an interface
belongs to the Null zone, all traffic on that interface is dropped.
Question: What next step should you take?
Answer: The next step is to assign the loO . 0 interface to a security

zone.
Step 2.4
Enter configuration mode and assign the loO . 0 interface to the Juniper-sv zone. Check if the
zone-level host-inbound-traffic statement allows ping. Commit the configuration changesand
exit to operational mode.
[edit]
lab@vSRX-l# set security zones security-zone Juniper-SV interfaces loO.O
[edit]
lab@vSRX-l# show security zones security-zone Juniper-SV
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/4.0;
loO.O;
}
[edit]
commit complete
lab@vSRX-l>

Question: Is ping allowed in the Juniper-sv zone?
Answer: As shown in the output, the Juniper-sv zone has all

servicesand protocols allowed in host-inbound-traffic.
Step 2.5
Review the loO . 0 interface details again.
lab@vSRX-l> show interfaces loO.O | find security

Security: Zone: Juniper-SV
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp Idp msdp nhrp
ospf ospf3 pgm pirn rip ripng router-discovery rsvp sap vrrp dhep 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
Isping ntp sip dhcpv6 r2cp webapi-clear-text webapi-ssl tcp-encap
sdwan-appqoe 13-ha
Protocol inet, MTU: Unlimited
Max nh cache: 0, New hold nh limit: 0, Curr nh ent: 0, Curr new hold ent: 0,
NH drop ent: 0
Flags: Sendbeast-pkt-to-re
Addresses, Flags: Is-Default Is-Primary
Local: 192.168.1.1
Question: Does the loO . 0 interface belong to a security zone?
Answer: Yes, as shown in the output, the loO. 0 interface belongs to

the Juniper-sv zone.
Step 2.6
Return to the session established with the vSRX-VR device.
On the vSRX-VR device, test the reachability from vrlOl to the vSRX-1 device loopback address by using
the ping command. Be sure to source your ping from the vrlOl routing instance.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: iemp seq=2 ttl=64 time=1.043 ms


Answer: Yes, as shown in the output, the pings are successful.
Part 3: Troubleshooting Security Policies

In this lab part, you will troubleshoot problems related to security policies. You first experience the
problem and use CLI tools to determine the root cause. Then, define the solution and resolve the
problem.
Step 3.1
From the session established with vSRX-VR device, verify the reachability from the vrlOl routing
instance to the Internet host by using SSH.
Note
When the session does not establish after a few seconds, press the
Ctrl + c keyboard sequence to cancel the attempt.
lab@vSRX-VR> ssh 172.31.15.1 routing-instance vrlOl
lab@vSRX-VR>
Question: Is the SSH connection established?
Answer: As shown in the output, the SSH session is not successful.
Step 3.2
On the vSRX-1 device, test which security policy is used to handle the SSH connection from vrl Olio the
Internet host. Use the show security match-policies command. Use the 1024 source port in
the command.
lab@vSRX-l> show security match-policies from-zone Juniper-SV to-zone untrust
source-ip 10.10.101.10 destination-ip 172.31.15.1 protocol tcp source-port 1024
destination-port 22
Policy: Default-Policy, action-type: deny-all. State: enabled. Index: 2
Sequence number: 2
Question: Which security policy is handling the connection and what

is the action?
Answer: As shown in the output, the default policy is handling the

connection and the action is deny-all.

Question: What does this tell you?
Answer: The SSH connection is denied by the default policy. The

default policy is enforced only if there is no match in user-defined
security policies.
Step 3.3
View existing policies from the Juniper-sv to un trust zones context by using the detail option.
lab@vSRX-l> show security policies from-zone Juniper-SV to-zone untrust detail
Policy: internet-Juniper-SV, action-type: permit. State: enabled. Index: 4, Scope
Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: Juniper-sv, To zone: untrust
Source vrf group:
any
Destination vrf group:
any
Source addresses:
vrlOl(Juniper-SV): 10.10.101.0/24
Destination addresses:
internet-host(untrust): 172.31.16.1/32
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination ports: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
Question: Does the security device have any policies in the

Juniper-SVto untrust zone context?
Answer: As shown in the output, the policy internet-Juniper-sv

exists on the device.
Question: If yes, why is the policy not used to handle the SSH
connection?
Answer: As shown in the output, the destination address listed in the

policy does not match the IP address of the Internet host.
Lab 3-10 • Troubleshooting security Zones and Policies www.juniper.net

Question: What would you change 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 all traffic to the Internet host.
step 3.4
Modify the address book entry in the address book of the untrust zone for the Internet host. Commit
the change and exit to the operational mode.
[edit]
lab@vSRX-l# edit security address-book untrust
[edit security address-book untrust]

lab@vSRX-l# show
address internet-host 172.31.16.1/32;
attach {
zone untrust;
}

lab@vSRX-l# replace pattern 172.31.16.1 with 172.31.15.1

lab@vSRX-l# show
address internet-host 172.31.15.1/32
attach {
zone untrust;
}

commit complete
lab@vSRX-l>

Step 3.5
On the vSRX-VR device, establish an SSH connection from vrl 01 to the Internet host. If prompted about
an ECDSA key fingerprint respond yes. Login with a password of labl23
ECDSA key fingerprint is 4f:4b:49:30:e7:53:57:73:54:e2:ea:al:37:42:d5:27.
Password: labl23
Last login: Sun May 3 14:14:06 2020 from 172.18.1.2
lab@vSRX-VR>
Question: Was the SSH connection successful?
Answer: As shown in the output, the SSH connection is successful. If

you experience problems, check your configuration and notify your
instructor.
Step 3.6
On the vSRX-1 device, examine the session table for SSH sessions to the Internet host.
lab@vSRX-l> show security flow session destination-port 22 destination-prefix
172.31.15.1
Session ID: 8796, Policy name: internet-Juniper-SV/7, Timeout: 1726, Valid
Pkts : 18, Bytes: 3261,
Out: 172.31.15.1/22 10.10.101.10/61873;tcp. Conn Tag: 0x0, If: ge-0/0/3.0.
Pkts : 16, Bytes: 3773,
Total sessions: 1
lab@vSRX-l>
Question: Are there any sessions present?
Answer: As shown in the output, a session is present for the SSH

connection from vrl 01 to the Internet host, handled by the
internet-Juniper-SV security policy
Step 3.7
Return to the open session on the vSRX-VR device.
On the vSRX-VR device, exit out of the ssh session.
lab@vSRX-VR> exit
lab@vSRX-VR>

Step 3.8
Return to the open session on the vSRX-1 device.
Modify the internet- Juniper-sv policy into a unified policy with a dynamic application match
criteria of any. Also, modify the application match criteria to junos-defaults.
[edit]
lab@vSRX-l# edit security policies from-zone Juniper-SV to-zone untrust
[edit security policies from-zone Juniper-SV to-zone untrust]

lab@vSRX-l# show
policy internet-Juniper-sv {
match {
source-address vrlOl;
destination-address internet-host;
application any;
}
then {
permit;
}
}

lab@vSRX-l# set policy internet-Juniper-SV match application junos-defaults

lab@vSRX-l# delete policy internet-Juniper-SV match application any

lab@vSRX-l# set policy internet-Juniper-SV match dynamic-application any

lab@vSRX-l# show
policy internet-Juniper-sv {
match {
application junos-defaults;
dynamic-application any;
}
then {
permit;
}
}

commit complete
lab@vSRX-l>

Step 3.9
On the vSRX-VR device, establish an SSH connection from vrl 01 to the Internet host.
Password:labl23
Last login: Mon May 4 14:18:20 2020 from 172.18.1.2
lab@vSRX-VR>
Question: Did the SSH session connect to the Internet host?
Answer: Yes the change in the configuration did not impact the
connection to the Internet host.
Step 3.10
On the vSRX-VR device, exit from the established SSH session to the Internet host.
lab@vSRX-VR> exit
lab@vSRX-VR>
Step 3.11
On the vSRX-1 device, create a catch-all rule in the from-zone Juniper-sv to-zone untrust
hierarchy to drop and log all other packets that have not matched previous rules. Verify that it is at the
bottom of the list.
[edit]
lab@vSRX-l# edit security policies from-zone Juniper-SV to-zone untrust policy
catch-all-log
[edit security policies from-zone Juniper-SV to-zone untrust policy catch-all-log]




lab@vSRX-l# set then deny log session-init

lab@vSRX-l# up

lab@vSRX-l# show
policy internet-Juniper-SV {
match {
application junos-defaults;
}
then {
permit;
}
}
policy catch-all-log {
match {
source-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}

lab@vSRX-l#
Question: Is the catch-all-log policy at the end of the from-zone

Juniper-SVio-zone un trust context?
Answer: Yes, the new policy is at the bottom of the context list.

warning: Policy I catch-all-log I does not contain any dynamic-applications or
url-categories but is placed below policies that use them. Please insert policy
’catch-all-log I before your Unified policies.
commit complete
lab@vSRX-l>

Question: Did the configuration complete successfully?
Answer: Yes, the configuration completed successfully.
Question: Is there any warnings with the commit?
Answer: Yes, there is a warning that your new policy is not a Unified
policy but the policy context includes Unified policies. They could be
processed in a different order then top to bottom.
Step 3.12
ssh: connect to host 172.31.15.1 port 22: Operation timed out
lab@vSRX-VR>
Question: Did the SSH session connect to the Internet host?
Answer: No, the connection timed out.
Question: What could you do to fix this problem?
Answer: There are two options to fix this connection issue. First,
modify the ca tch-dll-log policy to be a Unified policy. Second
move the ca tch-all-log policy to the Global polices hierarchy and
only run standard policies there.
step 3.13
On the vSRX-1 device, modify the catch-all-log rule to include a dynamic application match criteria.
[edit]

lab@vSRX-l# edit security policies from-zone Juniper-SV to-zone untrust policy
catch-all-log

lab@vSRX-l# set match dynamic-application any

lab@vSRX-l# show
match {
source-address any;
application any;
}
then {
deny;
log {
session-init;
}
}

commit complete
lab@vSRX-l>
Step 3.14
Password:labl23
Last login: Mon May 4 14:18:20 2020 from 172.18.1.2
lab@vSRX-VR>
Question: Did changing the catch-all-logru\e impact the

outcome of the SSH session?
Answer: Yes, changing the catch-all -log rule to be a Unified

policy changed the order in which the polices were resolved.
Step 3.15
On the vSRX-VR device, exit out of the ssh session.

lab@vSRX-VR> exit
lab@vSRX-VR>
Part 4: Troubleshooting Local Host Traffic

In this lab part, you will troubleshoot problems related to local host traffic. You first experience the
problem and use CLI tools to determine the root cause. Then, define the solution and resolve the
problem.
Step 4.1
From the session established with the vSRX-VR device, try to open a SSH session from vrl 01 to the
vSRX-1 interface in the ACME-svzor\e.
Note
If the session does not establish after a few seconds, press the
Ctrl + c keyboard sequence to cancel the attempt.
lab@vSRX-VR>
Question: Does theSSH connection establish?
Answer: As shown in the output, the SSH connection is not successful.
Step 4.2
On the vSRX-1 device, test which security policy is used to handle the SSH connection from vrl 01 to the
vSRX-1 interface in the ACME-svzone. Use the show security match-policies command and
enter the 1024 value for the source port.
lab@vSRX-l> show security match-policies from-zone Juniper-SV to-zone ACME-SV
source-ip 10.10.101.10 destination-ip 10.10.102.1 protocol tcp source-port 1024
destination-port 22
Policy: Juniper-SV-to-ACME-SV, action-type: permit, state: enabled. Index: 6
0
Sequence number: 1
From zone: Juniper-SV, To zone: ACME-SV
Source vrf group:
any
any
Source addresses:
vrlOl(Juniper-SV): 10.10.101.0/24
vrl02(ACME-SV): 10.10.102.0/24
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Destination ports: [0-0]
Question: Which security policy is handling the connection and what

is the action?
Answer: As shown in the output, the Juniper-sv-to-ACME-sv

security policy is handling the connection and the action is permit.
Answer: The SSH connection is permitted, but because the SSH

connection is destined to the vSRX-1 device, the device takes further
processing steps before responding to it.
Step 4.3
Verify if SSH is allowed on the vSRX-1 interface in the ACME-svzor\e.
lab@vSRX-l> show interfaces ge-0/0/5.0 extensive | find security
Zone: ACME-SV
Allowed host-inbound traffic : any-service bfd bgp dvmrp igmp Idp msdp nhrp
ospf ospf3 pgm pirn rip ripng router-discovery rsvp sap vrrp
Question: Is the SSH service among the allowed

host-inbound-traffic services?
Answer: SSH service is allowed because of the presence of the

any-service Statement in Allowed host-inbound
traffic.
Step 4.4
Enter configuration mode and enable traceoptions for packet flow processing. Define flow-log as the
file name, set the flag to basic-datapath, and specify a packet filter named Fl that only matches
traffic destined to the interface in the ACMB-svzone. Commit your configuration and exit to the
operational mode when complete.
[edit]
lab@vSRX-l# set security flow traceoptions file flow-log

[edit]
lab@vSRX-l# set security flow traceoptions flag basic-datapath
[edit]
lab@vSRX-l# set security flow traceoptions packet-filter Fl destination-prefix
10.10.102.1/32
[edit]
lab@vSRX-l# show security flow
traceoptions {
file flow-log;
flag basic-datapath;
packet-filter Fl {
destination-prefix 10.10.102.1/32;
}
}
[edit]
commit complete
lab@vSRX-l>
Step 4.5
On the vSRX-VR device, establish a SSH connection from vrl QI to the vSRX-1 interface in the kCME-sv
zone.
Note
When the session does not establish after a few seconds, press
the Ctrl + c keyboard sequence to cancel the attempt.
lab@vSRX-VR>
Step 4.6
On the vSRX-1 device, examine the flow- log traceoptions file.
Note
For the sake of clarity and time, the interesting lines are bolded
in the output.
lab@vSRX-l> show log flow-log
May 3 15:53:52 15:53:52.286113:CID-0:RT:<10.10.101.10/64456->10.10.102.1/

22;6, 0x0 matched filter Fl:
Lab 3-20 • TroubleshootingSecurity Zones and Policies www.juniper.net

May 3 15:53:52 15:53:52.288673:CID-0:RT: routed (x dst ip 10.10.102.1) from

Juniper-SV (ge-0/0/4.0 in 0) to ge-0/0/5.0. Next-hop: 10.10.102.1
May 3 15:53:52 15:53:52.288676:CID-0:RT:flow_first_policy_search: policy search

from zone Juniper-SV- zone ACME-SV (0x0,0xfbc80016,0x16)
May 3 15:53:52 15:53:52.288683:CID-0:RT:Policy Ikup: vsys 0 zone(12:Juniper-SV)

-> zone(13:ACME-SV) scope:0
src vrf (0) dsv vrf (0) scope:13100073
May 3 15:53:52 15:53:52.288696:CID-0:RT: 10.10.101.10/64456 -

10.10.102.1/22 proto 6
May 3 15:53:52 15:53:52.288787:CID-0:RT:flow_f irst_policy_search:

dynapp_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data:
0x0
May 3 15:53:52 15:53:52.288804:CID-0:RT: app 22, timeout 1800s, curr ageout 20s
May 3 15:53:52 15:53:52.288806:CID-0:RT: permitted by policy

Juniper - SV- to - ACME - S V (6)
May 3 15:53:52 15:53:52.288806:CID-0:RT: packet passed. Permitted by policy.
May 3 15:53:52 15:53:52.288809:CID-0:RT: flow conn track ent lookup: zone

connection track Oxd
May 3 15:53:52 15:53:52.289453:CID-0:RT:flow first src xlate: nat src xlated:

False, nat src xlate failed: False
May 3 15:53:52 15:53:52.290211:CID-0:RT:flow_first_src_xlate: incoming src port

is : 64456.
May 3 15:53:52 15:53:52.290218:CID-0:RT:flow first src xlate: src nat returns

status: 0, rule/pool id: 0/0, pst nat: False, nat eim: False.
May 3 15:53:52 15:53:52.290219:CID-0:RT: dip id = 0/0, 10.10.101.10/

64456->10.10.101.10/64456 protocol 0
May 3 15:53:52 15:53:52.290224:CID-0:RT: choose interface ge-0/0/5.0(P2P) as

outgoing phy if
May 3 15:53:52 15:53:52.290227:CID-0:RT:is_loop_pak: Found loop on ifp ge-0/0/

5.0, addr: 10.10.102.1, rtt idx: 0 addr type:0x3.
May 3 15:53:52 15:53:52.290700:CID-0:RT:flow_first_loopback_check: Setting

interface: ge-0/0/5.0 as loop ifp.
May 3 15:53:52 15:53:52.290722:CID-0:RT:[JSF]Normal interest check, regd plugins

42, enabled impl mask OxOApr 13 17:46:17
17:46:17.317033:CID-0:THREAD ID-01:RT:flow first src xlate: nat src xlated:
False, nat src xlate failed: False

May 3 15:53:52 15:53:52.290918:CID-0:RT:[JSF]Plugins(0x0, count 0) enabled for

session = 506227, impli mask(OxO), post nat ent 0 sve req(0x400)
May 3 15:53:52 15:53:52.290919:CID-0:RT:-jsf : no plugin interested for session

506227, free sess plugin info
May 3 15:53:52 15:53:52.290920:CID-0:RT:jsf pre int check result 0000
May 3 15:53:52 15:53:52.290921:CID-0:RT: service lookup identified service 22.
May 3 15:53:52 15:53:52.290921:CID-0:RT: flow first final check: in <ge-0/0/4.0>,

out <ge-0/0/5.0>
May 3 15:53:52 15:53:52.290923:CID-0:RT:In flow first complete session
May 3 15:53:52 15:53:52.290964:CID-0:RT:flow_first_complete_session, pak_ptr:

0x7ffffebfb8f0, nsp: 0xbf207a80, in tunnel: 0x0
May 3 15:53:52 15:53:52.290966:CID-0:RT:before copy: nsp vec list 0x0, nsp2

vec list 0x2
May 3 15:53:52 15:53:52.290966:CID-0:RT:after copy: nsp vec list 0x2, nsp2

vec list 0x2
May 3 15:53:52 15:53:52.290967:CID-0:RT:construct v4 vector for nsp2 and nsp
May 3 15:53:52 15:53:52.290968:CID-0:RT: existing vector list 0x2-0x6a7fe520.
May 3 15:53:52 15:53:52.291386:CID-0:RT:vector index for nsp2: 2
May 3 15:53:52 15:53:52.291386:CID-0:RT: existing vector list 0x2-0x6a7fe520.
May 3 15:53:52 15:53:52.291387:CID-0:RT:vector index for nsp: 2
May 3 15:53:52 15:53:52.291387:CID-0:RT: Session (id:506227) created for first

pak 2
May 3 15:53:52 15:53:52.291388:CID-0:RT:first pak processing successful
May 3 15:53:52 15:53:52.291389:CID-0:RT: flow first install session

0xbf207a80
May 3 15:53:52 15:53:52.291390:CID-0:RT: nsp 0xbf207a80, nsp2 0xbf207b40
May 3 15:53:52 15:53:52.291425:CID-0:RT:flow proc loop back:In loopback session

processing
May 3 15:53:52 15:53:52.291427:CID-0:RT:duplicate local pak: duplicated pak has

zone: Unknown, ifp: none, vsys: root-logical-system, 10.10.101.10->10.10.102.1,
Iports fbc80016, tlen 64
May 3 15:53:52 15:53:52.292255:CID-0:RT:flow xlate pak
May 3 15:53:52 15:53:52.292260:CID-0:RT: post addr xlation:

10.10.101.10->10.10.102.1.

May 3 15:53:52 15:53:52.292262:CID-0:RT:proc_loopback_common: Found loop if ge-0/

0/5.0
May 3 15:53:52 15:53:52.292287:CID-0:RT:check self-traffic on ge-0/0/5.0,

in tunnel 0x0 dp 22
May 3 15:53:52 15:53:52.292304:CID-0:RT:retcode: 0x1604
May 3 15:53:52 15:53:52.292305:CID-0:RT:pak for self : proto 6, dst port 5632,

action 0x4
May 3 15:53:52 15:53:52.292306:CID-0:RT: flow first create session
May 3 15:53:52 15:53:52.292309:CID-0:RT:Loopback first path alloc pending

session, natp=0xbf207d80, id=506228
May 3 15:53:52 15:53:52.292310:CID-0:RT: flow first in dst nat: in <ge-0/0/5.0>,

out <N/A> dst adr 10.10.102.1, sp 64456, dp 22
May 3 15:53:52 15:53:52.292312:CID-0:RT: chose interface ge-0/0/5.0 as incoming

nat if.
May 3 15:53:52 15:53:52.292315:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate:

0.0.0.0(0) to 10.10.102.1(22)
May 3 15:53:52 15:53:52.292316:CID-0:RT:[JSF] Do ingress interest check, regd

ingress plugins(1)
May 3 15:53:52 15:53:52.292318:CID-0:RT: [JSF] [0]plugins (0x0) enabled for session

506228 implicit mask(0x0), service request(0x0)
May 3 15:53:52 15:53:52.292319:CID-0:RT:-jsf : no plugin ingress interested for

session 506228
May 3 15:53:52 15:53:52.292320:CID-0:RT:flow_first_routing: vr_id 0, call
flow_route_lookup(): src_ip 10.10.101.10, x_dst_ip 10.10.102.1, in ifp ge-0/0/
5.0, out ifp N/A sp 64456, dp 22, ip proto 6, tos 0
May 3 15:53:52 15:53:52.292322:CID-0:RT:Doing DESTINATION addr route-lookup
May 3 15:53:52 15:53:52.292327:CID-0:RT:flow_ipv4_rt_lkup success 10.10.102.1,

iifl 0x4d, oifl 0x0
May 3 15:53:52 15 : 53:52.292329:CID-0:RT:flow_first_routing: setting out_vrf_id in

Ipak to 0, grp 0
May 3 15:53:52 15:53:52.292330:CID-0:RT: routed (x dst ip 10.10.102.1) from

ACME-SV (ge-0/0/5.0 in 0) to .local..0, Next-hop: 10.10.102.1
May 3 15:53:52 15:53:52.292332:CID-0:RT:flow_first_policy_search: policy search

from zone ACME-SV- zone junos-host (0x0,0xfbc80016,0x16)
May 3 15:53:52 15:53:52.292353:CID-0:RT:Policy Ikup: vsys 0 zone(13:ACME-SV)

zone(2:junos-host) scope:0
src vrf (0) dsv vrf (0) scope:13100073

May 3 15:53:52 15:53:52.292355:CID-0:RT: 10.10.101.10/64456 -

10.10.102.1/22 proto 6
May 3 15:53:52 15:53:52.292365:CID-0:RT:flow_first_policy_search:

dynapp_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0
May 3 15:53:52 15:53:52.292366:CID-0:RT: policy has timeout 900
May 3 15:53:52 15:53:52.292366:CID-0:RT: app 22, timeout 1800s, curr ageout 20s
May 3 15:53:52 15:53:52.292367:CID-0:RT: packet dropped, denied by policy
May 3 15:53:52 15:53:52.292371:CID-0:RT: denied by policy deny-ssh(5), dropping

pkt
May 3 15:53:52 15:53:52.292372:CID-0:RT: packet dropped. policy deny.
May 3 15:53:52 15:53:52.292375:CID-0:RT:flow_first_install_session : Loopback

session processing aborted
Question: How is the SSH connection attempt handled and why?
Answer: As shown in the output, the security policy

Juniper-SV-to-ACME-SVpermits the packet. However, because
the SSH connection is destined for the device itself, another set of
policies is examined in the from-zone acme-sv to-zone
junos-host context. In this context, a security policy named
deny-ssh denies the connection.
Step 4.7
View the security policies from the ACME-svto junos-host zone context by using the detail
command.
lab@vSRX-l> show security policies from-zone ACME-SV to-zone junos-host detail
Policy: deny-ssh, action-type: deny. State: enabled. Index: 5, Scope Policy: 0
Sequence number: 1
From zone: ACME-SV, To zone: j unos-host
Source vrf group:
any
any
Source addresses:
any-ipv4(ACME-SV): 0.0.0.0/0
any-ipv6(ACME-SV): ::/0
any-ipv4(global): 0.0.0.0/0
any-ipv6(global): ::/0

Application: junos-ssh
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Destination ports: 22
Question: Does the security device have any policies from the
ACME-svio junos-host zone context?
Answer: As shown in the output, a security policy exists named

deny-ssh that is denying SSH connections.
Question: What can be done to allow SSH connections?
Answer: There are several possible solutions. You could change the
action on the deny-ssh policy to permit, create a new policy higher
in the ordered list that allows this particular host to use SSH, or you
could delete the deny-ssh policy, because the default action for
connections to the j unos -hos t zone is permit.
Step 4.8
Enter configuration mode and delete the deny-ssh security policy. Commit the configuration and exit to
operational mode when complete.
[edit]
lab@vSRX-l# edit security policies
[edit security policies]

lab@vSRX-l# delete from-zone ACME-SV to-zone junos-host

commit complete
lab@vSRX-l>
Step 4.9
Return to the session established with the vSRX-VR device
On the vSRX-VR device, establish the SSH connection from vrlOl to the vSRX-1 interface in the
ACME-SV zone. Login with password labl23.
Password:labl23


lab@vSRX-l>
Question: Is the SSH connection successful?
Answer: As shown in the output, the SSH connection is successful. If

not, double-check your configuration and notify your instructor.
Step 4.10
On the vSRX-VR device, use the exit command to disconnect from the established SSH session.
Terminate the session with the vSRX-VR by issuing exit again.
lab@vSRX-l> exit
lab@vSRX-VR> exit
Step 4.11
On the vSRX-1 device, remove the traceoptions configuration used for the troubleshooting process.
Commit the change and exit configuration mode.
[edit]
lab@vSRX-l# delete security flow traceoptions
[edit]
commit complete
lab@vSRX-l>
Step 4.12
On vSRX-1, terminate the session by issuing the exit command.
lab@vSRX-l> exit
login:
Step 4.13
Return to the active session with the vSRX-2 device.
On the vSRX-2 device, issue the exit command to terminate the session.

lab@vSRX-2 exit
login:
STOP

vSRX-1
ATP Cloud
vSRX-2 ge-0/0/0 (on all student devices)
Physical
vSRX-VR aSx 172.25.11.254
I T 1
1
Internet SU
vQFX-1 Console and a

VNC Connections
Junos
Space
Policy
Hypervisor
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
c
Lab Environment
D.

Gatevyay 172.25.11.254
©2020 Juniper Networks, Inc. Al Rights Reserved.

juniper


Troubleshooting Zones and Policies
c ]
Internet
Internet Host
V 172.31.15.1
untrust zone untrustzone

(9^
vSRX-1 vSRX-2
loO; 192.168.1.1 loO: 192.168.2.1
ge-0/0/5
10.10.101.0/24 10.10.102.0/24 10.10.201.0/24 10.10.202..0/24
(.10) (.10) (.10) (.10)
vrlOl vrl02
vSRX-VR vr201 vr202
Juniper-SVzone ACM E-SV zone Juniper-WFzone ACM E-WF zone

juniper
NETWORKS

Lab
Hub-and-Spoke VPNs
Overview
In this lab you will configure a hub-and-spoke VPN by using the Junos CLI. You will configure the vSRX-VR
device as the hub, and the vSRX-1 and vSRX-2 devices as spokes.
• Configure the hub for a hub-and-spoke VPN.
• Configure the spokes for a hub-and-spoke VPN.
• Monitor the effects of your configuration.
www.juniper.net Hub-and-Spoke VPNs • Lab 4-1

Part 1: Inspecting Existing VPN Configuration

devices. Next, you will load the starting configuration for the lab.
Note
step 1.1
You will primarily configure the vSRX-1 and vSRX-VR devices. The vSRX-2 device is already configured for
devices.

devices?

Step 1.2
Access the CLI on the vSRX-1 device using SSH or console as directed by your instructor. On the vSRX-1
device, login with the username lab and password labl23. Enter configuration mode and load the
lab4-start. config from the ajsec directory. Commit the configuration when complete.
login: lab
Password:
Last login: Mon Mar 2 16:35:47 2020 from 172.25.11.254

[edit]
load complete
[edit]
lab@vSRX-l# commit
commit complete
Step 1.3
Access the command-line interface (CLI) for the vSRX-2 device as directed by your instructor.
On the vSRX-2 device, login with the username lab and password labl23. Enter configuration mode
and load the lab4-start, conf igr from the aj sec directory. Commit the configuration when
complete.
Lab 4-2 • Hub-and-Spoke VPNs www.juniper.net

login: lab
Password:

[edit]
load complete
[edit]
lab@vSRX-2# commit
commit complete
Step 1.4
Access the command-line interface (CLI) for the vSRX-VR device using SSH or console as directed by your
instructor.
Log in with the username lab and password labl23. Enter configuration mode and load the
ldb4-start, confighom the ajsec directory. Commit the configuration when complete.
login: lab
Password:

[edit]
load complete
[edit]
lab@vSRX-VR# commit
commit complete
Step 1.5
Verify that the necessary routing information is available to reach the virtual routing instances vrlOl
vrl02, vr201 and vr202.
[edit]
lab@vSRX-VR# show routing-options static
route 10.10.101.0/24 next-hop 172.18.1.2;
route 10.10.102.0/24 next-hop 172.18.1.2;
route 10.10.202.0/24 next-hop 172.18.2.2;
route 10.10.201.0/24 next-hop 172.18.2.2;
[edit]
lab@vSRX-VR# run show route 10.10.0.0/16 table inet.O


■k
10.10.101.0/24 [Static/5] 00:00:54
> to 172.18.1.2 via ge-0/0/1.0
k
10.10.102.0/24 [Static/5] 00:00:54
> to 172.18.1.2 via ge-0/0/1.0
k
10.10.201.0/24 [Static/5] 00:00:54
> to 172.18.2.2 via ge-0/0/2.0
10.10.202.0/24 [Static/5] 00:00:54
> to 172.18.2.2 via ge-0/0/2.0
[edit]
lab@vSRX-VR#
Question: Why are no static routes to the vSRX-1 or vSRX-2 devices

configured?
Answer: In this environment the vSRX-VR device is directly connected

to both the vSRX-1 and vSRX-2 devices and we are using physical
interface addresses to peer. Therefore no static routes are necessary
to reach these devices.
Part 2: Configuring the Hub Device

In this lab part, you will configure the IPSec VPN settings on the hub device. You will configure the local
StO interface as multipoint and configure static routes to the remote virtual router devices to use the
appropriate remote stO interface IPs.
Step 2.1
Configure the StO interface with an IP address of 10.25.0.9/24. Configure the multipoint setting. Add
the StO.O interface to the vpn security zone.
[edit]
lab@vSRX-VR# edit interfaces
[edit interfaces]
lab@vSRX-VR# set stO unit 0 family inet address 10.25.0.9/24
[edit interfaces]
lab@vSRX-VR# set stO unit 0 multipoint
[edit interfaces]
lab@vSRX-VR# top set security zones security-zone vpn interfaces stO.O
[edit interfaces]
lab@vSRX-VR#

Step 2.2
On the vSRX-VR device, navigate to the [edit security ike] configuration hierarchy and configure
the IKE proposal settings for the hub-and-spoke VPN. The proposal should use the following parameters:
Authentication method: pre-shared-keys;
dh-group: group2;
authentication algorithm: sha-2 56;
encryption algorithm: aes-256-cbc; and
lifetime: 8 64 00.
[edit interfaces]
lab@vSRX-VR# top edit security ike proposal phasel-proposal
[edit security ike proposal phasel-proposal]

lab@vSRX-VR# set authentication-method pre-shared-keys

lab@vSRX-VR# set dh-group group2

lab@vSRX-VR# set authentication-algorithm sha-256

lab@vSRX-VR# set encryption-algorithm aes-256-cbc

lab@vSRX-VR# set lifetime-seconds 86400

lab@vSRX-VR# show
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha-256;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;

lab@vSRX-VR#
Step 2.3
Configure an IKE Phase 1 policy named phasel -policy. The policy should use the following
parameters:
Mode: main
Proposal: phasel -proposal', and
Pre-shared Key: ascii-text juniper
lab@vSRX-VR# up 1 edit policy phasel-policy
[edit security ike policy phasel-policy]

lab@vSRX-VR# set mode main

lab@vSRX-VR# set proposals phasel-proposal

lab@vSRX-VR# set pre-shared-key ascii-text juniper

lab@vSRX-VR# show
mode main;
proposals phasel-proposal;
pre-shared-key ascii-text "$9$QoV33/tlRSM87u087-V4oz36"; ## SECRET-DATA

lab@vSRX-VR#
Step 2.4
Configure an IKE gateway named vSRX-1. Configure the gateway with the following parameters:
Ike Policy: phasel -policy
Address: 172.18.1.2
Dead Peer Detection Interval: 2 0
Dead Peer Detection Threshold: 5 ; and
External Interface: loO . 0
Copy the settings fro the vSRX-1 gateway to a gateway named vSRX-2. Change the address setting to
172.18.1.2
lab@vSRX-VR# up 1 edit gateway vSRX-1
[edit security ike gateway vSRX-1]

lab@vSRX-VR# set ike-policy phasel-policy

lab@vSRX-VR# set address 172.18.1.2

lab@vSRX-VR# set dead-peer-detection interval 20

lab@vSRX-VR# set dead-peer-detection threshold 5

lab@vSRX-VR# set external-interface loO.0

lab@vSRX-VR# show
ike-policy phasel-policy;
address 172.18.1.2;
dead-peer-detection {
interval 20;
threshold 5;
}
external-interface loO.O;

lab@vSRX-VR# up
[edit security ike]

lab@vSRX-VR# copy gateway vSRX-1 to gateway vSRX-2
[edit security ike]

lab@vSRX-VR# edit gateway vSRX-2

lab@vSRX-VR# replace pattern 172.18.1.2 with 172.18.2.2

lab@vSRX-VR# up
[edit security ike]

lab@vSRX-VR# show
proposal phasel-proposal {
dh-group group2;
}
policy phasel-policy {
mode main;
pre-shared-key ascii-text "$9$/z0yAulSrv7-wRh-wYgUD9Ap"; ## SECRET-DATA
}
gateway vSRX-1 {
address 172.18.1.2;
interval 20;
threshold 5;
}
}
gateway vSRX-2 {
address 172.18.2.2;
interval 20;
threshold 5;
}
}
[edit security ike]

lab@vSRX-VR#
Step 2.5
Navigate to the [edit security ipsec] configuration hierarchy and define an IKE Phase 2
proposal named phase2-proposal. Configure the proposal with the following parameters:
Protocol: esp

• Authentication Algorithm: hmac-sha-256-128
Encryption Algorithm: aes-256-cbc/ and
Lifetime: 32 00
[edit security ike]
lab@vSRX-VR# up 1 edit ipsec proposal phase2-proposal
[edit security ipsec proposal phase2-proposal]

lab@vSRX-VR# set protocol esp

lab@vSRX-VR# set authentication-algorithm hmac-sha-256-128

lab@vSRX-VR# set encryption-algorithm aes-256-cbc

lab@vSRX-VR# set lifetime-seconds 3200

lab@vSRX-VR# show
protocol esp;
authentication-algorithm hmac-sha-256-128;

lab@vSRX-VR#
step 2.6
Create a Phase 2 policy named phase2-policy. Configure Perfect Forward Secrecy (PFS) to use
Diffie-Hellman Group 14 and reference the Phase 2 proposal you created in the last step.
lab@vSRX-VR# up 1 edit policy phase2-policy
[edit security ipsec policy phase2-policy]

lab@vSRX-VR# set perfect-forward-secrecy keys groupl4

lab@vSRX-VR# set proposals phase2-proposal

lab@vSRX-VR# show
perfect-forward-secrecy {
keys groupl4;
}
proposals phase2-proposal;

lab@vSRX-VR#

Step 2.7
Configure two IPsec VPN tunnels named to-vSRX-1 and to-vSRX-2, one to each remote VPN. Bind
the stO.O interface to this tunnel. Associate the IKE Phase 1 gateway and Phase 2 policy with the VPN
tunnel. Ensure the VPN tunnel is established without the need for a triggering mechanism.
lab@vSRX-VR# up 1 edit vpn to-vSRX-1
[edit security ipsec vpn to-vSRX-1]

lab@vSRX-VR# set bind-interface stO.O

lab@vSRX-VR# set ike gateway vSRX-1

lab@vSRX-VR# set ike ipsec-policy phase2-policy

lab@vSRX-VR# set establish-tunnels immediately

lab@vSRX-VR# up
[edit security ipsec]

lab@vSRX-VR# copy vpn to-vSRX-1 to vpn to-vSRX-2

lab@vSRX-VR# edit vpn to-vSRX-2

lab@vSRX-VR# show
bind-interface stO.O;
ike {
gateway vSRX-1;
ipsec-policy phase2-policy;
}
establish-tunnels immediately;

lab@vSRX-VR# replace pattern vSRX-1 with vSRX-2

lab@vSRX-VR# up

lab@vSRX-VR# show
proposal phase2-proposal {
protocol esp;
}
policy phase2-policy {
keys groupl4;

}
proposals phase2-proposal;
}
vpn to-vSRX-1 {
ike {
gateway vSRX-1;
}
}
vpn to-vSRX-2 {
ike {
gateway vSRX-2;
}
}

lab@vSRX-VR#
Step 2.8
Navigateto [edit routing-options static] and replace the existing Static routes to the remote
instances subnets. Configure new routes that use the remote secure tunnel interfaces as their next-hop.

lab@vSRX-VR# top edit routing-options static
[edit routing-options static]

lab@vSRX-VR# show
route 10.10.101.0/24 next-hop 172.18.1.2;
route 10.10.102.0/24 next-hop 172.18.1.2;
route 10.10.202.0/24 next-hop 172.18.2.2;
route 10.10.201.0/24 next-hop 172.18.2.2;

lab@vSRX-VR# delete
Delete everything under this level? [yes,no] (no) yes

lab@vSRX-VR# set route 10.10.101.0/24 next-hop 10.25.0.1





lab@vSRX-VR# show
route 10.10.101.0/24 next-hop 10.25.0.1;
route 10.10.102.0/24 next-hop 10.25.0.1;
route 10.10.201.0/24 next-hop 10.25.0.2;
route 10.10.202.0/24 next-hop 10.25.0.2;

lab@vSRX-VR#
Step 2.9
To allow intra-zone traffic to flow from one branch VPN tunnel to the other branch VPN tunnel within the
vpn zone, configure a security policy that allows traffic from the vpn zone to the vpn zone.

lab@vSRX-VR# top edit security policies global policy vpn-to-vpn
[edit security policies global policy vpn-to-vpn]

lab@vSRX-VR# set match source-address any

lab@vSRX-VR# set match destination-address any

lab@vSRX-VR# set match application any

lab@vSRX-VR# set match from-zone vpn

lab@vSRX-VR# set match to-zone vpn

lab@vSRX-VR# set then permit

lab@vSRX-VR# show
match {
source-address any;
application any;
from-zone vpn;
to-zone vpn;
}
then {
permit;
}

lab@vSRX-VR#

Step 2.10
Commit the changes and exit configuration mode.
commit complete
lab@vSRX-VR>
Part 3: Configuring the Spoke Devices

In this lab part, you will configure the vSRX-1 spoke device for the hub-and-spoke VPN. The vSRX-2 has
already been configured. The settings on the two devices will be identical, except for the gateway address.
Step 3.1
Return to the existing session with the vSRX-1 device.
On the vSRXl device. Configure the stO interface with an IP address of 10.25.0.1/24.
[edit]
[edit interfaces]
lab@vSRX-l# set stO unit 0 family inet address 10.25.0.1/24
[edit interfaces]
lab@vSRX-l#
Step 3.2
Navigate to the [edit security ike] configuration hierarchy and configure IKE proposal settings
for the hub-and-spoke VPN. The proposal should use the following parameters:
Authentication method: pre-shared-keys;
dh-group: group2;
authentication algorithm: sha-256;
encryption algorithm: aes-2 56-cbc; and
lifetime: 8 6400.
[edit interfaces]
lab@vSRX-l# top edit security ike proposal phasel-proposal

lab@vSRX-l# set authentication-method pre-shared-keys

lab@vSRX-l# set dh-group group2

lab@vSRX-l# set authentication-algorithm sha-256

lab@vSRX-l# set encryption-algorithm aes-256-cbc


lab@vSRX-l# set lifetime-seconds 86400

lab@vSRX-l# show
dh-group group2;

lab@vSRX-l#
Step 3.3
Configure an IKE Phase 1 policy named phasel -policy. The policy should use the following
parameters:
Mode: main
Proposal: phasei -proposal', and
lab@vSRX-l# up 1 edit policy phasel-policy

lab@vSRX-l# set mode main

lab@vSRX-l# set proposals phasel-proposal

lab@vSRX-l# set pre-shared-key ascii-text jiiniper

lab@vSRX-l# show
mode main;
pre-shared-key ascii-text "$9$5znC01hKMXtuMX7-2gTz3"; ## SECRET-DATA

lab@vSRX-l#
Step 3.4
Configure an IKE gateway named hub-ga teway. Configure the gateway with the following parameters:
Ike Policy:phasel-policy
Address: 192.168.9.1
Dead Peer Detection Interval: 2 0
Dead Peer Detection Threshold: 5 ; and

External Interface: ge-0/0/1.0


lab@vSRX-l# up 1 edit gateway hub-gateway
[edit security ike gateway hub-gateway]

lab@vSRX-l# set ike-policy phasel-policy

lab@vSRX-l# set address 192.168.9.1

lab@vSRX-l# set dead-peer-detection interval 20

lab@vSRX-l# set dead-peer-detection threshold 5

lab@vSRX-l# set external-interface ge-0/0/1

lab@vSRX-l# show
address 192.168.9.1;
interval 20;
threshold 5;
}
external-interface ge-0/0/1;

lab@vSRX-l#
Step 3.5
Navigate to the [edit security ipsec] configuration hierarchy and define an IKE Phase 2 proposal
named phase2-proposal. Configure the proposal with the following parameters:
Protocol: esp
Authentication Algorithm: hmac-sha-2 56-128
Encryption Algorithm: aes-256-cbc/ and
Lifetime: 32 00

lab@vSRX-l# up 2 edit ipsec proposal phase2-proposal

lab@vSRX-l# set protocol esp

lab@vSRX-l# set authentication-algorithm hmac-sha-256-128


lab@vSRX-l# set lifetime-seconds 3200


lab@vSRX-l# show
protocol esp;

lab@vSRX-l#
Step 3.6
Create a Phase 2 policy named phase2-policy. Configure Perfect Forward Secrecy (PFS) to use
Diffie-Hellman Group 14 as the method the device uses to generate the encryption key. Use the Phase 2
proposal you created in the last step.
lab@vSRX-l# up 1 edit policy phase2-policy

lab@vSRX-l# set perfect-forward-secrecy keys groupl4

lab@vSRX-l# set proposals phase2-proposal

lab@vSRX-l#
Step 3.7
Configure the IPsec VPN tunnel named hub-device and bind the stO.O interface to this tunnel.
Associate the IKE Phase 1 gateway and Phase 2 policy with the VPN tunnel. Ensure the VPN tunnel is
established without the need for a triggering mechanism.
lab@vSRX-l# up 1 edit vpn hub-device
[edit security ipsec vpn hub-device]

lab@vSRX-l# set bind-interface stO.O

lab@vSRX-l# set ike gateway hub-gateway

lab@vSRX-l# set ike ipsec-policy phase2-pol±cy

lab@vSRX-l# set establish-tunnels immediately

lab@vSRX-l#

Step 3.8
Navigate to the [edit routing-options static] and create Static routes to the remote subnets
containing the vr201 and vr202 virtual router instances to use the stO interface as a next hop.
lab@vSRX-l# top edit routing-options static

lab@vSRX-l# set route 10.10.201.0/24 next-hop stO.O

lab@vSRX-l# set route 10.10.202.0/24 next-hop stO.O

lab@vSRX-l# show
route 0.0.0.0/0 next-hop 172.18.1.1;
route 10.10.201.0/24 next-hop stO.O;

lab@vSRX-l#
step 3.9
To allow traffic to flow from the Juniper-svar\6 ACME-svzor\es through the VPN interface towards
the remote virtual router instances you must add the stO. 0 interface to a security zone. Name this zone
vpn. Then configure a security policy that allows traffic from the Juniper-svar\6 ACME-svzor\es to
the vpn zone.
lab@vSRX-l# top edit security zones security-zone vpn
[edit security zones security-zone vpn]

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

lab@vSRX-l# top edit security policies global policy local-to-vpn
[edit security policies global policy local-to-vpn]




lab@vSRX-l# set match from-zone Juniper-SV

lab@vSRX-l# set match from-zone ACME-SV

lab@vSRX-l# set match to-zone vpn



lab@vSRX-l# show
match {
source-address any;
application any;
from-zone [ Juniper-SV ACME-SV ];
to-zone vpn;
}
then {
permit;
}

lab@vSRX-l#
Step 3.10
In order to allow the IKE negotiation to take place, enable IKE as an allowed host inbound service on
interface ge-0/0/1.0.
lab@vSRX-l# top edit security zones security-zone untrust interfaces ge-0/0/1.0
[edit security zones security-zone untrust interfaces ge-0/0/1.0]

lab@vSRX-l# set host-inbound-traffic system-services ike

lab@vSRX-l# set host-inbound-traffic system-services ping

lab@vSRX-l#
Step 3.11
Commit the changes and exit configuration mode.
commit complete
lab@vSRX-l>

Part 4: Verifying and Monitoring the Hub-and-Spoke VPN

In this lab part, you will verify that the Hub-and-Spoke VPN tunnels have been established. You will
validate that traffic from the vrlOl and vrl02 instances destined to the vr201 and vr202 instances is
routed through the vSRX-VR hub device across the established tunnels.
Step 4.1
On the vSRX-1 device, verify that the IKE Phase 1 security association has been formed by issuing show
security ike security-associations. Verify that the IKE Phase 2 security associations have been formed by
issuing show security ipsec security-associations.
lab@vSRX-l> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
4541199 UP 2037edl8d212630b 2c7de6de7656a55f Main 192.168.9.1
lab@vSRX-l> show security ipsec security-associations

Total active tunnels: 1 Total Ipsec sas: 1
ID Algorithm SPI Life:sec/kb Mon Isys Port Gateway
<131073 ESP:aes-cbc-256/sha256 418a560c 861/ unlim - root 500 192.168.9.1
>131073 ESP:aes-cbc-256/sha256 365631e 861/ unlim - root 500 192.168.9.1
Step 4.2
Return to the existing session with the vSRX-VR device.
On the vSRX-VR device, verify that the IKE Phase 1 security association has been formed by issuing show
security ike security-associations. Verify that the IKE Phase 2 security associations have been formed by
issuing show security ipsec security-associations.
lab@vSRX-VR> show security ike security-associations
4338774 UP 2037edl8d212630b 2c7de6de7656a55f Main 172.18.1.2
4337537 UP 3e8439aa224eldl4 815b98d302a68cf5 Main 172.18.2.2
lab@vSRX-VR> show security ipsec security-associations

Total active tunnels: 2
<131073 ESP:aes-cbc-256/sha256 365631e 1695/ unlim - root 500 172.18.1.2
>131073 ESP:aes-cbc-256/sha256 418a560c 1695/ unlim - root 500 172.18.1.2
<131074 ESP:aes-cbc-256/sha256 442cd414 1699/ unlim - root 500 172.18.2.2
>131074 ESP:aes-cbc-256/sha256 3a07a828 1699/ unlim - root 500 172.18.2.2
Step 4.3
On the vSRX-VR device, check that the routes to the remote subnets will use the IPsec tunnels by issuing
the show route protocol static table inet. 0 command.
lab@vSRX-VR> show route protocol static table inet.O

10.10.101.0/24 ■k
[Static/5] 23:29:23
> to 10.25.0.1 via stO.0
10.10.102.0/24 * [Static/5] 23:29:23
> to 10.25.0.1 via stO.0
10.10.201.0/24 * [Static/5] 23:29:23

> to 10.25.0.2 via stO.O

10.10.202.0/24 [Static/5] 23:29:23
> to 10.25.0.2 via stO.O
lab@vSRX-VR>
Step 4.4
On the vSRX-1 device, check the routes used to reach the remote instance subnets by issuing the
show route protocol static table inet. 0 command.
lab@vSRX-l> show route protocol static table inet.O

0.0.0.0/0 [Static/5] 16:52:31

> to 172.18.1.1 via ge-0/0/1.0
10.10.201.0/24 [Static/5] 00:54:44
> via stO.O
10.10.202.0/24 [Static/5] 00:54:44
> via StO.O
Step 4.5
Clear the IPsec statistics with the clear security ipsec statistics command. Check the
statistics counters with show security ipsec statistics command.
lab@vSRX-l> clear security ipsec statistics
lab@vSRX-l> show security ipsec statistics

ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
Encrypted packets: 0
Decrypted packets: 0
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0

Step 4.6
On the vSRX-VR device, clear the IPsec statistics with the clear security ipsec statistics
command. Check the statistics counters with show security ipsec statistics.
lab@vSRX-VR> clear security ipsec statistics
lab@vSRX-VR> show security ipsec statistics

ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
Step 4.7
Test the IPsec tunnel routing by issuing a ping from each local virtual router (vrl 01, vrl 02) to each
remote virtual router {vr201, vr202).
lab@vSRX-VR> ping 10.10.201.10 routing-instance vrlOl rapid
PING 10.10.201.10 (10.10.201.10): 56 data bytes
I I I I I
lab@vSRX-VR> ping 10.10.201.10 routing-instance vrl02 rapid

PING 10.10.201.10 (10.10.201.10): 56 data bytes
I I I I I

PING 10.10.202.10 (10.10.202.10): 56 data bytes
I I I I I

PING 10.10.202.10 (10.10.202.10): 56 data bytes
I I I I I

lab@vSRX-VR>
Step 4.8
Verify that the packets between the remote virtual router instances traversed the vSRX-VR device with
the show security ipsec statistics command.
lab@vSRX-VR> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 6240
Decrypted bytes: 3360
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
Question: What happened to the ESP Statistics counters? What does

this tell you about how the traffic generated in the previous step was
routed?
Answer: The counters should have increased. If the preceding steps

were followed exactly, the counters for encrypted packets and
decrypted packets should both be 40. This matches the 40 total
packets generated by the ping tests.
Step 4.9
On the vSRX-1 device, check the IPsec statistics with the show security ipsec statistics
command.
ESP Statistics:
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:


Question: How do the counters on vSRX-1 compare to what your

observed on the vSRX-VR device? What does this indicate?
Answer: The hub device increments at twice the rate of the spokes
because of the traffic using and ingress and egress tunnel on the hub.
This is consistent with the expected routing path where packets from
the vrl 01 and vrl 02 to the vr201 and vr202 virtual routers are
encapsulated on the vSRX-1 device and routed across the stO tunnel
to the vSRX-VR device en route to vSRX-2.
Step 4.10
On the vSRX-1 device, logout using the exit command.
lab@vSRX-l> exit
login:
Step 4.11
lab@vSRX-2 exit
login:
Step 4.12
Return to the active session with the vSRX-VR device.
On the vSRX-VR device, issue the exit command to terminate the session.
lab@vSRX-VR> exit
login:
STOP Tell your instructor that you have completed this lab.


vSRX-1
ATP Cloud
Physical
Virtual Desktop! Gateway Desktops
vSRX-VR SiS 172,25.11.254
Internet
vQFX-1 ] Console and
VNC Connections
Junos
Space
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
AD/NTP/DNS Server Lab Environment ATP On-Prem 172.25.11.120
AD/NTPZDNS Server 172.25.11.130
Gateway 172.25.11.254
©2020 Juniper Networks, Inc. All Rights Reserved.

jumper
Nf'ACKXS
Lab Network Diagram: Hub-and-Spoke VPNs
vSRX-VR
loO: 192.168.9.1
(.9)
St0.1
untrust zone untrust zone
♦
10.25.0.0/24
% %
-5/
vSRX-1 ge-0/0/7 public zone ge-QIQI7 vSRX-2

loO: 192.168.1.1 (.129) loO: 192.168.2.1
(.1) 10.0.1.0/24
ge-0/0/4 ge-0/0/5 ge-OZO/4
10.10.101.0/24 10.10.102.0/24 10.10.201.0/24 10.10.202..0/24
(.10) (.loy (.10) (.10)
vr102
vSRX-VR vr202
vr101 vr201
Juniper-SV zone ACME-SV zone Juniper-WF zone ACME-WF zone

jumper
NETWORKS


Lab
Advanced NAT
Overview
In this lab, you will implement Network Address Translation (NAT) in several advanced scenarios. You will
use the Junos CLI to configure source and destination NAT. You will see how NAT rules work together with
security policies to address different objectives. Then, you will examine how routing behavior can impact
some NAT implementations and then resolve those issues. You will then configure devices for NAT46 and
NAT64 operations.
• Configure and monitor pool-based destination NAT.
• Configure and monitor NAT for local routed and local switched environments.
• Configure and monitor NAT46.
• Configure and monitor NAT64.
www.juniper.net Advanced NAT • Lab 5-1


device. Next, you will load the starting configuration for the lab.
Note

step 1.1
devices.

devices?

Step 1.2
username lab and password labl23. Enter configuration mode and load the labS-start. config
from the ajsec directory. Commit the configuration when complete.
login: lab
Password:

[edit]
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Lab 5-2 • Advanced NAT www.juniper.net

Step 1.3
user name lab and password labl23. Enter configuration mode and load the lab5-stdrt. config
from the ajsec directory. Commit the configuration and exit to operational mode when complete.
Note

login: lab
Password:
Last login: Mon Apr 25 19:50:22 2020 from 172.25.11.254

[edit]
load complete

commit complete
lab@vSRX-2
Step 1.4
from the ajsec directory. Commit the configuration and exit to operational mode when complete.
Note

login: lab
Password:
Last login: Mon Apr 25 19:50:22 2020 from 172.25.11.254


[edit]
load complete

commit complete
lab@vSRX-VR>
Step 1.5
From the open session with vSRX-1, on the vSRX-1 device, review the routing tables and determine which
routes are used to reach the remote device networks.
[edit]

0.0.0.0/0 ■k
[Static/5] 4d 03:39:09
> to 172.18.1.1 via ge-0/0/1.0
10.10.101.0/24 * [Direct/0] 4d 03:39:09
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 4d 03:39:09
10.10.102.0/24 * [Direct/0] 4d 03:39:09
> via ge-0/0/5.0
10.10.102.1/32 * [Local/0] 4d 03:39:09
172.18.1.0/30 * [Direct/0] 4d 03:39:09
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] 4d 03:39:09
172.25.11.0/24 * [Direct/0] 4d 03:39:09
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 4d 03:39:09
192.168.1.1/32 * [Direct/0] 4d 03:40:41
> via loO.O
Question: Which route is currently used to reach the remote

networks?
Answer: The default route (0.0.0.0/0) that is statically configured is

used to reach the remote networks.
Step 1.6
Configure the ge-0/0/7 interface with the 10.0.1.1/24 address as shown in the lab network diagram.

[edit]
[edit interfaces]
lab@vSRX-l# set ge-0/0/7 unit 0 family inet address 10.0.1.1/24
[edit interfaces]
lab@vSRX-l#
Note
We use a /24 prefix to emulate real-world environments where
a range of public-facing IP addresses might exist. NAT allows
you to use public-facing IP addresses without needing to assign
them to the interface.
The vSRX-1 device will own the 10.0.1.0/25 address range
in this topology. The vSRX-2 device will own the
10.0.1.128/25 address range.
Step 1.7
Create a new security zone named public and add the ge-0/0/7 interface to the zone.
[edit interfaces]
lab@vSRX-l# top edit security zones

lab@vSRX-l# set security-zone public interfaces ge-0/0/7

lab@vSRX-l#
Step 1.8
Create a new security policy named Juniper-sv-to-public. This policy allows SSH traffic from the
vrl 01 routing instance to initiate sessions to any external SSH server through the ge-0/0/7 interface.
Use the existing vrlOl address book entry for the source address. Use the predefined application
jlinos-ssh for the application.

lab@vSRX-l# top edit security policies from-zone Jun±per-SV to-zone public
[edit security policies from-zone Juniper-SV to-zone public]

lab@vSRX-l# edit policy JSV-to-public
[edit security policies from-zone Juniper-SV to-zone public policy JSV-to-public]

lab@vSRX-l# set match source-address vrlOl





lab@vSRX-l# show
match {
}
then {
permit;
}

lab@vSRX-l#
Step 1.9
Delete the existing static default route and create a new static default route for the vSRX-1 device. The
new route should use the IP address of the ge-0/0/7 interface on vSRX-2 as the next hop. Commit the
configuration when you are finished.
[edit security policies global policy Juniper-SV-to-public]
lab@vSRX-l# top edit routing-options
lab@vSRX-l# delete static route 0/0
lab@vSRX-l# set static route 0/0 next-hop 10.0.1.129
lab@vSRX-l# show static
route 0.0.0.0/0 next-hop 10.0.1.129;
lab@vSRX-l# commit
commit complete
lab@vSRX-l#
Part 2: Configuring Pool-based Destination NAT with Port Forwarding

In this lab part, you set up a port-forwarding implementation of pool-based destination NAT. The
implementation will allow external hosts to SSH to a resource on your internal network through a
public-facing IP address associated with the ge-0/0/7 interface of the vSRX-1 device.
Step 2.1
Navigate to the [edit security address-book global] hierarchy level. Configure address book
entries for vSRX-lfor Juniper-svan6 acme-svzones, and vSRX-2 Juniper-WFan6 acme-wf
zones. Place the vSRX-2 address book entries into an address set named remote-partner.
lab@vSRX-l# top edit security address-book global

[edit security address-book global]

lab@vSRX-l# set address Jun±per-WF 10.10.201.0/24

lab@vSRX-l# set address ACME-WF 10.10.202.0/24

lab@vSRX-l# set address-set remote-partner address ACME-WF

lab@vSRX-l# set address-set remote-partner address Juniper-WF

lab@vSRX-l# set address Jun±per-SV 10.10.101.0/24

lab@vSRX-l# set address ACME-SV 10.10.102.0/24

lab@vSRX-l# show
address vr201 10.10.201.10/32;
address vr202 10.10.202.10/32;
address internet-host 172.31.15.1/32;
address vrlOl 10.10.101.10/32;
address vrl02 10.10.102.10/32;
address 100.0.0.1/32 100.0.0.1/32;
address 192.168.1.1/32 192.168.1.1/32;
address Juniper-WF 10.10.201.0/24;
address ACME-WF 10.10.202.0/24;
address Juniper-SV 10.10.101.0/24;
address ACME-SV 10.10.102.0/24;
address-set remote-partner {
address ACME-WF;
address Juniper-WF;
}

lab@vSRX-l#
Step 2.2
Navigate to the [edit security nat destination] hierarchy. Configure the destination NAT
pool ssh-server with the virtual router address associated with the vrl02 instance.
lab@vSRX-l# top edit security nat destination
[edit security nat destination]

lab@vSRX-l# set pool ssh-server address 10.10.102.10/32

lab@vSRX-l#
Step 2.3
Configure a destination NAT rule set named rule-set from-public with a directional context that
will perform NAT on traffic coming from the public zone.

Note
Directional context for destination NAT can only be established
with a from statement. No route-lookup takes place to
determine an egress interface until after destination NAT has
been processed.

lab@vSRX-l# edit rule-set from-pviblic
[edit security nat destination rule-set from-public]

lab@vSRX-l# set from zone ptiblic

lab@vSRX-l#
Step 2.4
Configure a rule named to-ssh-serverio match SSH traffic sourced from the Juniper-ivrand
ACME-WFnetworks using the remote-partner address set. Then, apply the rule to traffic destined for
the vSRX-1 external NAT address of 10.0.1.126.
lab@vSRX-l# edit rule to-ssh-server
[edit security nat destination rule-set from-public rule to-ssh-server]

lab@vSRX-l# set match source-address-name remote-partner

lab@vSRX-l# set match destination-address 10.0.1.126/32

lab@vSRX-l# set match destination-port 22

lab@vSRX-l# set then destination-nat pool ssh-server

lab@vSRX-l# show
match {
source-address-name remote-partner;
destination-address 10.0.1.126/32;
destination-port {
22;
}
}
then {
destination-nat {
pool {
ssh-server;
}
}
}


lab@vSRX-l#
Question: Will a host from the remote vr202 be able to SSH to your
SSH server after you commit the current changes?
Answer: No external hosts will be able to access your SSH server yet.
There are no security policies are in place that allow traffic originating
from the zone public. You will create the appropriate security policy
in a subsequent step
Question: Will the host-inbound-services statement need to

be configured for the ge-0/0/7 interface of the vSRX-1 device?
Answer: No. The host-inbound-services statement is not

required for our implementation. Destination NAT is applied to traffic
before the route lookup occurs. When the new flow is evaluated, it will
be evaluated as transit traffic, not as traffic destined for the device
itself.
Question: Will proxy-arp need to be configured for our

implementation?
Answer: Yes. The target destination IP address is one of many in the

10.0.1.0/25 address range that is not configured on the
ge-0/0/7 interface. In our topology, the vSRX-2 device will recognize
the destination IP address as being on a local segment and send out
an ARP request. Without proxy-arp, no reply is given to the ARP
request because the IP address is not assigned to any host on the
network.
step 2.5
Configure proxy-arp on the vSRX-1 device. The vSRX-1 device should respond to any ARP requests for
the 10.0.1.2 to 10.0.1.126 range on the ge-0/0/7 interface.
lab@vSRX-l# up 3
[edit security nat]

lab@vSRX-l# set proxy-arp interface ge-0/0/7 address 10.0.1.2 to 10.0.1.126
[edit security nat]

lab@vSRX-l# show proxy-arp
address {
10.0.1.2/32 to 10.0.1.126/32;
}
}
[edit security nat]

lab@vSRX-l#

Step 2.6
Configure a security policy named ssh-server that will allow SSH traffic from the Juniper-WFand
ACME-WFcustomer networks to the local vrl 02 instance. Configure the source address to match the
address-set remote -partner and use the existing vrl 02 address book entry for the destination
address. Next, commit the configuration and exit to operational mode.
[edit security nat]
lab@vSRX-l# top edit security policies from-zone public to-zone ACME-SV policy
ssh-server
[edit security policies froiti-zone public to-zone ACME-SV policy ssh-server]

lab@vSRX-l# set match source-address remote-partner

lab@vSRX-l# set match destination-address vrl02


[edit security policies from-zone public to-zone ACME-SV policy ssh-server]

lab@vSRX-l# show
match {
source-address remote-partner;
destination-address vrl02;
}
then {
permit;
}

commit complete
lab@vSRX-l>
Step 2.7
From the open session with vSRX-VR, test your recently configured NAT implementation by initiating an
SSH connection from the vr201 device to the 10.0.1.126 address. Source the connection from the
vr201 routing instance and do not log in.
lab@vSRX-VR> ssh 10.0.1.126 routing-instance vr201
Password:

Question: What is the result of the SSH session?
Answer: As shown in the output, the SSH session should be

successfully established.
Step 2.8
On the vSRX-1 device, issue the show security flow session application ssh command.
lab@vSRX-l> show security flow session application ssh
Session ID: 10501, Policy name: allow-to-ssh-server/8, Timeout: 1794, Valid
Pkts : 17, Bytes: 3209,
Pkts : 16, Bytes: 3773,
Total sessions: 1
Note
The total sessions could be greater than one if you are connected
using SSH instead of console.
Question: Which input and output interfaces are used for the SSH
session?
Answer: The ge-0/0/7 interface is used as the input interface. The

ge-0/0/5 interface is used as the output interface.
Step 2.9
On the vSRX-VR device, press the Ctrl + c keyboard sequence to end the SSH session.
lab@vSRX-VR> ssh 10.0.1.126 routing-instance vr201
Password: C
lab@vSRX-VR>
Part 3: Configuring NAT for a Local Routed and Local Switched

Environment
In this lab part, you expand your implementation to allow internal hosts to reach internal resources that
are publicly available by connecting to the public-facing IP address on the vSRX-1 device.
You will learn how this implementation works in a routed environment and how it differs in a switched
environment.

Step 3.1
From the session established with the vSRX-VR device, initiate a SSH session to the external NAT address
on the ge-0/0/7 interface for the vSRX-1 device (10.0.1.126). Source the SSH connection from the
vrlOl routing instance. Press the Ctrl + c keyboard sequence to cancel when the session does not
establish after a few seconds.
Question: What is the result of the SSH session? Is NAT occurring?
Answer: As shown in the output, the SSH session does not establish.
This likely indicates that NAT is not occurring.
Question: What are some possibilities that could prevent NAT from
occurring?
Answer: One possibility is that the initiating flow is not being evaluated
for NAT. Another possibility is the initiating flow does not match the
criteria set in the NAT rule.
Step 3.2
On the vSRX-1 device, enter configuration mode and review the existing NAT implementation to see if you
can identify the problem.
[edit]
lab@vSRX-l# edit security nat destination rule-set from-pviblic

lab@vSRX-l# show
from zone public;
rule to-ssh-server {
match {
source-address-name remote-partner;
destination-port {
22;
}
}
then {
destination-nat {
pool {
ssh-server;
}
}
}
}

lab@vSRX-l#
Question: Can you identify the problem?
Answer: The rule-set from-public NAT currently applies only

to traffic originating in the zone public. Also, the rule is only
matching traffic from the vr201 and vr202 networks. Other traffic
is not being evaluated for NAT.
Step 3.3
Modify the existing rule set from-public so sessions initiated from the vrlOl and vrl02 networks
will be evaluated for NAT. Commit the changes.
lab@vSRX-l# set from zone Juniper-SV

lab@vSRX-l# set from zone ACME-SV

lab@vSRX-l# set rule to-ssh-server match source-address-name Juniper-SV

lab@vSRX-l# set rule to-ssh-server match source-address-name ACME-SV

lab@vSRX-l# show
from zone [ ACME-SV public Juniper-SV ];
rule to-ssh-server {
match {
source-address-name [ remote-partner Juniper-SV ACME-SV ];
destination-port {
22;
}
}
then {
destination-nat {
pool {
ssh-server;
}
}
}
}

lab@vSRX-l# commit
commit complete


lab@vSRX-l#
Step 3.4
On the vSRX-VR device, initiate a SSH session to the external NAT address on the ge-0/0/7 interface for
the vSRX-1 device (10.0.1.126). Source the SSH connection from the vrlOl routing instance and do not
log in.
Password:
Answer: As shown in the output, the SSH session is successful.
Step 3.5
On the vSRX-1 device, issue the run show security flow session application ssh
command.
lab@vSRX-l# run show security flow session application ssh
Session ID: 10537, Policy name: Juniper-SV-to-ACME-SV/9, Timeout: 1796, Valid
In: 10.10.101.10/64081 10.0.1.126/22;top. Conn Tag: 0x0, If: ge-0/0/4.0.
Pkts : 10, Bytes: 2197,
Pkts : 8, Bytes: 1977,
Total sessions: 1
Question: Is the SSH session found in the session table?
Answer: Yes. The SSH session is found in the session table.
Step 3.6
On the vSRX-VR device, press the Ctrl + c keyboard sequence to terminate the SSH session.
Password:
lab@vSRX-VR>
Step 3.7

On the vSRX-1 device, use the run show security nat destination summary command to
confirm that traffic initiated from the ACME customer zone will be evaluated by the rule-set
from-in ternet NAT.
lab@vSRX-l# run show security nat destination summary
Total pools: 1
Pool name Address Routing Port Total
Range Instance Address
ssh-server 10.10.102.10 10.10.102.10 0 1
Total rules: 1
Rule name Rule set From Action
to-ssh-server from-public ACME-SV ssh-server
public
Juniper-sv
Question: Which zones is the destination NAT rule matching on?
Answer: The destination NAT rule is matching on the Juniper-sv,

ACME-SV, and public zones.
Step 3.8
intra-ACME-sv policy to permit traffic from the ACME-svzor\e that is destined to the
Configure the
ACME-SVzone. Ensure that you allow hosts from the acme-sv network to initiate sessions to hosts on
the ACME-SV network. When you are finished, commit the configuration.

lab@vSRX-l# top edit security policies from-zone ACME-SV to-zone ACME-SV policy
intra-ACME-sv
[edit security policies from-zone ACME-SV to-zone ACME-SV policy intra-ACME-SV]

lab@vSRX-l# set match source-address ACME-SV

lab@vSRX-l# set match destination-address ACME-SV



lab@vSRX-l# show
match {
source-address ACME-SV;
destination-address ACME-SV;
application any;
}
then {
permit;


lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 3.9
the vSRX-1 device (10.0.1.126). Source the SSH connection from the vrI02 routing instance. Issue the
Ctrl + c key combination to exit the attempt.
lab@vSRX-VR> ssh 10.0.1.126 routing-instance v’rI02
Answer: As shown in the output, the SSH session does not establish.
Step 3.10
command.
Session ID: 10548, Policy name: intrazone-ACME-SV/10, Timeout: 12, Valid
Pkts : 0, Bytes: 0,
Total sessions: 1
Question: What information does this output provide?
Answer: The output indicates NAT is occurring. However, there is a

problem with the return flow of the session. If there is no session it
might have timed out. Return to the vSRX-VR and rerun the last step
again.

Note
Note
The source and destination IP address in the return flow of the
output are the same because the same host is acting as both
source and destination.
The source and destination IP address will not usually be the
same in switched networks. However, they will share a common
network.
Question: What are some possibilities that could prevent the session
from establishing?
Answer: The initiating flow is destined for a host on another network.

The originating host determines the packet must be sent to the
next-hop gateway. Upon arrival at the device, destination NAT is
performed and the initiating flow is senton to the disguised host. This
is shown in the first flow of the output.
The target host receives the packet and sets up the session locally.
The target host then responds directly to the originating host. The
originating host is on the same network; the target host responds
directly using the Layer 2 information from its local ARP table.
The originating host receives an unsolicited syn-ack from an

unexpected device and drops the packet. The session never
establishes.
Question: What are some options that can resolve this issue?
Answer: The return flow must transit the device for the required
reverse NAT to occur. This can be accomplished by adding source NAT
to the implementation. Switched environments require this double
NAT implementation.
Step 3.11
Configure double NAT by adding interface-based source NAT to disguise the IP address of the originating
host. Name the NAT rule set acconunoda te-swi tched-network. Name the rule
ndt-return-flow. The rule should only apply source NAT to intrazone traffic. The rule should not
make exclusions based on the destination address. When you are finished, navigate to the top of the
command hierarchy, and commit the configuration.
lab@vSRX-l# top edit security nat source
[edit security nat source]

lab@vSRX-l# edit rule-set accoj HIH odate-switched-network

[edit security nat source rule-set accommodate-switched-network]
lab@vSRX-l# set from interface ge-0/0/5

lab@vSRX-l# set to interface ge-0/0/5

lab@vSRX-l# edit rule nat-return-flow
[edit security nat source rule-set accommodate-switched-network rule

nat-return-flow]
lab@vSRX-l# set match source-address 10.10.102.0/24

nat-return-flow]
lab@vSRX-l# set then source-nat interface

nat-return-flow]
lab@vSRX-l# show
match {
source-address 10.10.102.0/24;
}
then {
source-nat {
interface;
}
}

nat-return-flow]
lab@vSRX-l# top
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Step 3.12
the vSRX-1 device (10.0.1.126). Source the SSH connection from the vrl02 routing instance.
lab@vSRX-VR> ssh 10.0.1.126 routing-instance vrl02
Password:

Answer: As shown in the output, the SSH session is successful.
Step 3.13
command.
[edit]
Session ID: 10579, Policy name: intrazone-ACME-SV/10, Timeout: 1792, Valid
Pkts : 10, Bytes: 2197,
Total sessions: 1
Question: What does the output display?
Answer: The output displays that NAT has modified the source IP
address as the packet traversed the device. The destination host will
use the Layer 2 information associated with the vSRX-1 device for
delivery
Note
The return flow will now transit the vSRX-1 device. The device
will perform reverse NAT operations and the originating host will
receive the SYN-ACK from the expected IP address.
Step 3.14
lab@vSRX-VR> ssh 10.0.1.126 routing-instance vrI02
Password: C
lab@vSRX-VR>

Part 4: Implementing IPv6 NAT—NAT46
In this lab part, you configure and verify NAT46 operations. This NAT implementation requires both
destination NAT and source NAT for proper operation. You will configure source and destination NAT to
perform NAT46, to translate the IPv4 addresses to IPv6 addresses.
The IPv6 NAT implementation will allow an IPv4 host within the acme-svcustomer network on the
vSRX-VR device to SSH to an IPv6 host on the Internet (2001:db2::100) through a public-facing IP address
associated with the ge-0/0/1 interface.
step 4.1
Return to the established session with the vSRX-1 device.
Configure the ge-0/0/1 interface to use the 2001:db2::l/64 IPv6 address.
[edit]
lab@vSRX-l# edit interfaces ge-0/0/1

lab@vSRX-l# set unit 0 family inet6 address 2001:db2::1/64
Step 4.2
Navigate to the [edit routing-options rib inet 6.0] hierarchy and configure a IPv6 default
static route that uses the 2001:db2::100 as the next hop.
lab@vSRX-l# top edit routing-options rib inet6.0
[edit routing-options rib inetO.O]

lab@vSRX-l# set static route ::/0 next-hop 2001:db2::100
Step 4.3
You will configure source NAT to translate the 10.10.102.10 IPv4 address of the vrl 02 instance to an
IPv6 address that will be used for NAT46.
Navigate to the [edit security nat source] hierarchy. Configure a source NAT pool named
na t4 6-source-pool with the 2001:db2::2 address that will be used for NAT46.
[edit routing-options rib inetO.O]

lab@vSRX-l# set pool nat46-source-pool address 2001:db2::2
Step 4.4
Configure a source NAT rule set named na t4 6-dest with a directional context that will perform NAT on
traffic coming from the ACME-svzone and going to the un trust zone.
lab@vSRX-l# edit rule-set nat46-source
[edit security nat source rule-set nat46-source]


lab@vSRX-l# set to zone untrust

Step 4.5
Configure a rule within the rule set na t46-source named 46-source to match traffic sourced from
the 10.10.102.10 address and destined for 2001:db2::100 address. Note that the 10.10.102.10
address is an IP address that is local to the acme-sv network. Then specify that the source address of
the matching traffic will be translated to the pool na t4 6-source-pool.
lab@vSRX-l# edit rule 46-source
[edit security nat source rule-set nat46-source rule 46-source]

lab@vSRX-l# set match source-address 10.10.102.10

lab@vSRX-l# set match destination-address 2001:db2::100/128

lab@vSRX-l# set then source-nat pool nat46-source-pool

lab@vSRX-l#
Step 4.6
Configure proxy-arp on the ge-0/0/5 interface connected to the acme-svcustomer network for
10.10.102.5.
lab@vSRX-l# top set security nat proxy-arp interface ge-0/0/5 address
10.10.102.5/32
Step 4.7
For steps 5.8-5.10, you will configure NAT46 to translate the destination IPv4 address to an IPv6
address.
Navigate to the [edit security nat destination] hierarchy. Configure a destination NAT pool
named nat46-dst-pool with the IPv6 2001:db2::100/128 address.
lab@vSRX-l# top edit security nat destination

lab@vSRX-l# set pool nat46-dst-pool address 2001:db2::100/128

lab@vSRX-l#
Step 4.8
Configure a NAT rule-set named nat4 6-dst with a directional context that will perform source NAT on
traffic coming from the ACME-svzone.
lab@vSRX-l# edit rule-set nat46-dest
[edit security nat destination rule-set nat46-dest]


Step 4.9
Configure a destination NAT rule for the nat 4 6-dst rule-set named na t4 6-dst to match traffic to the
10.10.102.5 host. Then, specify that the destination address of the matching traffic will be translated to
the pool nat46-dst-pool.
[edit security nat destination rule-set nat46-dest]
lab@vSRX-l# edit rule nat46-dest
[edit security nat destination rule-set nat46-dest rule nat46-dest]


lab@vSRX-l# set then destination-nat pool nat46-dst-pool

lab@vSRX-l#
step 4.10
Configure NDP proxy at the [edit security nat] hierarchy. The vSRX-1 device should respond to
any NDP requests for the IPv6 address 2001:db2::2/128 on the ge-0/0/1 interface.
lab@vSRX-l# top set security nat proxy-ndp interface ge-0/0/1 address
2001:db2::2/128
Step 4.11
Create a global address book entry named na t4 6-src for the 10.10.102.10 address. Create another
global address book entry named na 14 6-Inet-hos t for the 2001:db2::100 address.
lab@vSRX-l# top edit security address-book global

lab@vSRX-l# set address nat46-src 10.10.102.10

lab@vSRX-l# set address nat46-lnet-host 2001:db2::100

lab@vSRX-l#
Step 4.12
Navigate to the [edit security policies global] hierarchy. Configure a security policy named
allow-na t46 to allow SSH traffic from the ACME-svzone to the na t4 6-inet-host address for
NAT46 on the untrust zone. Configure the source-address to match the nat4 6-src
address-book entry. Then, configure the destination-address to match the nat46-inet-host
address book entry. Commit the configuration and exit to operational mode when you are finished.
lab@vSRX-l# top edit security policies from-zone ACME-SV to-zone untrust policy
allow-nat46
[edit security policies froiti-zone ACME-SV to-zone untrust policy allow-nat46]

lab@vSRX-l# set match source-address nat46-src

[edit security policies global policy allow-nat46]

lab@vSRX-l# set match destination-address nat46-lnet-host



commit complete
lab@vSRX-l>
Step 4.13
Verify your recently configured NAT46 implementation. Return to the session established with the
vSRX-VR device.
On the vSRX-VR device, initiate a new SSH session to the 10.10.102.5 address. Source the SSH
connection from the vrl02 routing instance.
Note
If the SSH session fails, please try again, the first session might
fail due to IPv6 neighbor discovery not occurring yet.

Password:
Answer: As shown in the output, the SSH session should establish

successfully.

Step 4.14
Session ID: 10694, Policy name: allow-nat46/12, Timeout: 1790, Valid
Out: 2001:db2::100/22 - 2001:db2::2/28595;tcp. Conn Tag: 0x0, If: ge-0/0/1.0.
Total sessions: 1
Answer: The output shows that NAT46 is occurring as expected.
Step 4.15
Close out of the established SSH session by entering cntr + c.
Password: c
lab@vSRX-VR>
Part 5: Implementing IPv6 NAT—NAT64

In this lab part, you configure and verify operations for NAT64.This IPv6 NAT implementation requires both
destination NAT and source NAT for proper operation. You will configure the same IPv6 subnet addressing
within the local Juniper-sv network, and will perform NAT64 to properly translate the IPv6 addresses
to IPv4 addresses.
The IPv6 NAT implementation will allow an IPv6 host within the Juniper-svzone on the vSRX-VR device
to SSH to an IPv4 host resource on the remote acme-wfcustomer network through a public-facing IP
address associated with the ge-0/0/7 interface of the vSRX-1 device.
Step 5.1
Return to the open session with the vSRX-1 device.
On the vSRX-1 device, enter configuration mode. Configure the ge-0/0/4 interface associated with the
vrlOl network with the IPv6 address 2001:db8::l/64.
[edit]
lab@vSRX-l# set interfaces ge-0/0/4 unit 0 family inet6 address 2001:dbS::1/64
Step 5.2
Delete the IPv4 address from the interface associated with your vrlOl network.

[edit]
lab@vSRX-l# delete interfaces ge-0/0/4 unit 0 family inet
Step 5.3
Configure destination NAT64 to translate the IPv6 destination traffic to an IPv4 address.
Navigate to the [edit security nat destination] hierarchy. Configure a destination NAT pool
named ipv6-dest-pool with the IP address of the 10.10.202.10 NAT address.
[edit]
lab@vSRX-l# edit security nat destination

lab@vSRX-l# set pool ipv6-dest-pool address 10.10.202.10

lab@vSRX-l#
Step 5.4
Configure a destination NAT rule set named ipv6-dest with a directional context that will perform NAT
on traffic coming from the Juniper-sv zone.
lab@vSRX-l# edit rule-set ipv6-dest
[edit security nat destination rule-set ipv6-dest]

Step 5.5
Configure a rule within the rule set ipv6-dest named ipv6-local to match traffic destined for the
IPv6 address 2001:db8::5/128. Next, specify that the destination address of the matchi ng traffic will be
translated to the pool ipv6-dest-pool. Then configure the ipv6-source-pool to reference the
10.0.1.1 address.
[edit security nat destination rule-set ipv6-dest]
lab@vSRX-l# edit rule ipv6-local
[edit security nat destination rule-set ipv6-dest rule ipv6-local]

lab@vSRX-l# set match destination-address 2001:dbS::5/128

lab@vSRX-l# set then destination-nat pool ipv6-dest-pool


lab@vSRX-l# set pool ipv6-source-pool address 10.0.1.1

lab@vSRX-l#

Step 5.6
Configure a source NAT rule set named ipv6-source with a directional context that will perform NAT on
traffic coming from the Juniper-svzone and destined for the public zone.
lab@vSRX-l# edit rule-set ±pv6-source
[edit security nat source rule-set ipv6-source]


lab@vSRX-l# set to zone public
Step 5.7
Configure a source NAT rule named ipv6-host to match traffic from the source address 2001:db8::8/
128. Specify the rule to match the destination address of 10.10.202.10. Also specify that the source
address of the matching traffic will be translated to the pool ipv6-source-pool.
lab@vSRX-l# edit rule ipv6-host
[edit security nat source rule-set ipv6-source rule ipv6-host]

lab@vSRX-l# set match source-address 2001:dbS::8/128

lab@vSRX-l# set match destination-address 10.10.202.10

lab@vSRX-l# set then source-nat pool ipv6-source-pool

lab@vSRX-l# show
match {
source-address 2001:db8::8/128;
}
then {
source-nat {
pool {
ipv6-source-pool;
}
}
}

lab@vSRX-l#
step 5.8
Create a global address book entry named ipv6-address for the IPv6 address 2001:db8;:8/128.
lab@vSRX-l# top set security address-book global address ipv6-address
2001:db8::8/128

Step 5.9
Create another global address book entry named remote-public for the 10.0.1.0/24 subnet.
lab@vSRX-l# top set security address-book global address remote-pviblic 10.0.1.0/24
Step 5.10
Configure N DP proxy at the [edit security nat] hierarchy. The device should respond to any NDP
requests for the IPv6 address 2001:db8;:5/128 on the ge-0/0/4 interface.
lab@vSRX-l# top edit security nat
[edit security nat]

lab@vSRX-l# set proxy-ndp interface ge-0/0/4 address 2001:db8::5/128
[edit security nat]

lab@vSRX-l# show proxy-ndp
address {
2001:db2::2/128;
}
}
address {
2001:db8::5/128;
}
}
Step 5.11
Navigate to the [edit security policies global] hierarchy. Configure a security policy named
dllow-ipv6-ssh from the Juniper-SVzone to the public zone to allow only SSH traffic.
Configure the source address to match the address book entry ipv6-dddress. Specify the destination
address as any.
[edit security nat]
lab@vSRX-l# top edit security policies from-zone Juniper-SV to-zone public policy
allow-ipv6
[edit security policies froiti-zone Juniper-SV to-zone public policy allow-ipv6]

lab@vSRX-l# set match source-address ipv6-address




[edit security policies from-zone Juniper-SV to-zone public policy allow-ipv6]

lab@vSRX-l# show
match {
source-address ipv6-address;
}
then {
permit;
}
[edit security policies from-zone Juniper-SV to-zone public policy allow-ipv6]

commit complete
lab@vSRX-l>
Step 5.12
Verify the flow module status by issuing the show security flow status command.
lab@vSRX-l> show security flow status
Flow forwarding mode:
Inet forwarding mode: flow based
Inet6 forwarding mode: flow based
MPLS forwarding mode: drop
ISO forwarding mode: drop
Tap mode: disabled (default)
Flow trace status
Flow tracing status: off
Flow session distribution
Distribution mode: Hash-based
GTP-U distribution: Disabled
Flow ipsec performance acceleration: off
Flow packet ordering
Ordering mode: Hardware
Flow power mode IPsec: Disabled
Fat core group status: off
Question: What is the forwarding status for IPv6 traffic?
Answer: The inet6 forwarding mode shows a status of flow

based in the output. This status means the flow module can service
IPv6 traffic. This is the default setting for the SRX Series device.

Step 5.13
Test your recently configured NAT64 implementation. Return to the session established with the vSRX-VR
device.
On the vSRX-VR device, initiate an IPv6 SSH session to the IPv6 address 2001:db8::5. Source the SSH
connection from the vrlOl routing instance.
Note
If the SSH session fails, please try again, the first session might
fail due to IPv6 neighbor discovery not occurring yet.
lab@vSRX-VR> ssh inet6 2001:db8::5 routing-instance vrlOl

Password:
Answer: As shown in the output, the SSH session should establish

successfully.
Step 5.14
Session ID: 10630, Policy name: allow-ipv6/ll, Timeout: 1788, Valid
In: 2001:db8::8/56397 2001:db8::5/22;top. Conn Tag: 0x0, If: ge-0/0/4.0.
Pkts : 11, Bytes: 2469,
Out: 10.10.202.10/22 10.0.1.1/1785;tcp. Conn Tag: 0x0, If: ge-0/0/7.0. Pkts:
8, Bytes: 1977,
Total sessions: 1
Question: What does the output display?
Answer: The output displays that NAT has modified both the source
and destination of the IPv6 address as the packet traversed the
device.
Note
The return flow will now transit the vSRX-1 device. The device
will perform reverse NAT operations and the originating host will
receive the SYN-ACK from the expected IP address.

Step 5.15
Issue the show security nat destination rule all command.
lab@vSRX-l> show security nat destination rule all
Total destination-nat rules: 3
Total referenced IPv4/lPv6 ip-prefixes: 6/1
Destination NAT rule: to-ssh-server Rule-set: from-public
Rule-Id 1
Rule position 1
From zone ACME-SV
public
Juniper-SV
Match
Source addresses : remote-partner
Juniper-SV
ACME-SV
Destination addresses : 10.0.1.126 10.0.1.126
Destination port : 22 22
Action : ssh-server
Translation hits : 9
Successful sessions : 9
Failed sessions : 0
Number of sessions : 0
Destination NAT rule: nat46-dest Rule-set: nat46-dest
Rule-Id 2
Rule position 2
From zone ACME-SV
Destination addresses 10.10.102.5 10.10.102.5
Action nat46-dst-pool
Translation hits 1
Successful sessions 1
Failed sessions 0
Number of sessions 0
Destination NAT rule: ipv6-local Rule-set: ipv6-dest
Rule-Id : 3
Rule position : 3
From zone : Juniper-SV
Destination addresses : 2001:db8::5 2001:db8::5
Action : ipv6-dest-pool
Translation hits : 2
Successful sessions : 2
Failed sessions : 0
Number of sessions : 1
lab@vSRX-l>
Question: Do you see translation hits occurring in the output for the
IPv6 NAT rules?
Answer: Yes, the output should display that NAT has modified both the
source and destination of the IPv6 address, and that translation hits
have occurred. The number of hits may vary from the number shown
in the example above.

Step 5.16
lab@vSRX-VR> ssh inet6 2001:db8::5 routing-instance vrlOl
Password: C
lab@vSRX-VR>
Step 5.17
lab@vSRX-VR> exit
login:
Step 5.18
Close the session with the vSRX-1 device by issuing the exit command.
lab@vSRX-l> exit
login:
Step 5.19
lab@vSRX-2 exit
login:
STOP Tell your Instructor that you have completed this lab.


vSRX-1
ATP Cloud
vSRX-2 I
35
L Lli11
ge-0/0/0 (on all student devices)
Physical
vSRX-VR SS 172.25.11,254
Internet
VNC Connections
1
Junos
Space •t J Management Addressing
Policy
Hypervisor
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
student Policy Enforcer 172.25.11.101
AD/NTP/DNS Server
c 3
Lab Environment ATP On-Prem 172.25.11.120

Gateway 172.25.11.254

jumper
NETWORKS
Lab Network Diagram: Advanced NAT

c ]
Internet
Internet Host
■Jj 172.31.15.1
O'
A
Sy untrust zone untrust zone 7
vSRX-1 ge-0/0/7 public zone ge-QIQI7

loO: 192.168.1.1 (•129) loO: 192.168.2.1
(.1) 10.0.1.0/24
(: ge-QIQI5 ge-0/0/4
10.10.101.0/24 10.10.102.0/24 10.10.201.0/24 10.10.202..0/24

2001;db8::/64
(:8) (.10) Cio\ (.10) (.10)
vr101 vr102
vSRX-VR vr201 vr202

jumper
Nf'ACKXS

Lab
Implementing Tenant Systems
Overview
In this lab, you configure two tenant systems along with the routing and security options to communicate
with each other using logical tunnels.
• Configure tenant systems interfaces and routing instances.
• Configure tenant systems security features.
• Understand session creation with tenant systems.
• Verify separate config and resource allotment.
www.juniper.net Implementing Tenant Systems • Lab 6-1

Part 1: Loading Start Configurations
In this lab part, you will use the command-line interface (CLI) to log in to the vSRX-1 and vSRX-VR devices.
Next, you will load the starting configuration for the lab.
Note

step 1.1
You will primarily configure the vSRX-1 device. The vSRX-VR device is already configured for you. Consult
the Management Network Diagram to determine the management addresses of your devices.

devices?

Step 1.2
from the a j sec directory. Commit the configuration when complete and exit to operational mode.
login: lab
Password:
[edit]
lab@vSRX-l# load override ajsec/lab6-start.conf±g
load complete
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Step 1.3
Access the CLI on the vSRX-VR device as directed by your instructor.
Lab 6-2 • Implementing Tenant Systems www.juniper.net

Step 1.4
username lab and password labl23. Enter configuration mode and load the lab6-stdrt.config
Note

login: lab
Password:
[edit]
load complete

commit complete
lab@vSRX-VR>
Part 2: Master Administrator Tasks
In this part, you will configure a security profile for two tenant systems, administrator logins for the tenant
systems, a routing instance for each tenant, and interfaces forthose routing instances.
Step 2.1
On the vSRX-1 device configure a tenant named tsysi .
[edit]
lab@vSRX-l# edit tenants TSYSI
[edit tenants TSYSl]

lab@vSRX-l#
Step 2.2
Configure a new login class called TSYSladminl and assign it to the TSYSI tenant. Make sure the class
gives configured users all permissions.
[edit tenants TSYSI]
lab@vSRX-l# top edit system login

[edit system login]

lab@vSRX-l# set class TSYSladminl tenant TSYSI
[edit system login]

lab@vSRX-l# set class TSYSladminl permissions all
[edit system login]

lab@vSRX-l#
Step 2.3
Configure an administrator login called TSYSladminl for tsysi that uses labl23 as the password
and assign it to the class TSYSladminl.
[edit system login]
lab@vSRX-l# set user TSYSladminl class TSYSladminl
[edit system login]

lab@vSRX-l# set user TSYSladminl authentication plain-text-password
New password: labl23
Retype new password: labl23
[edit system login]

lab@vSRX-l#
Step 2.4
Repeat the last two steps to create a new tenant system called TSYS2, a class called TSYS2adminl, and
an administrator called TSYS2adminl with a password of Iabl23.
[edit system login]
lab@vSRX-l# top set tenants TSYS2
[edit system login]

lab@vSRX-l# set class TSYS2adminl tenant TSYS2
[edit system login]

lab@vSRX-l# set class TSYS2adminl permissions all
[edit system login]

lab@vSRX-l# set user TSYS2adminl class TSYS2adminl
[edit system login]

lab@vSRX-l# set user TSYS2adminl authentication plain-text-password
New password: labl23
Retype new password: labl23
[edit system login]

lab@vSRX-l#
Step 2.5
Verify the configuration by viewing the [edit system login] hierarchy.
[edit system login]
lab@vSRX-l# show
class TSYSladminl {
tenant TSYSI;
permissions all;
}

class TSYS2adminl {
tenant TSYS2;
permissions all;
}
user TSYSladminl {
uid 2002;
class TSYSladminl;
authentication {
encrypted-password
"$6$KlQTIyRJ$Od32aP4MwpWrlZLcuIPIcr7rVux...PfOTOTyzMbKe."; ## SECRET-DATA
}
}
user TSYS2adminl {
uid 2003;
class TSYS2adminl;
authentication {
encrypted-password II $6$AzVE]ndsin$ . . . zTvZuuBiOQ2Inw/" ; ## SECRET-DATA
}
}
user lab {
uid 2000;
class super-user;
authentication {
encrypted-password II $1$84J5Maes$cni5Hrazbd/lEHr/50oY30"; ## SECRET-DATA
}
}
[edit system login]

lab@vSRX-l#
step 2.6
[edit system login]
lab@vSRX-l# commit
error: Check-out failed for Network security daemon (/usr/sbin/nsd) without
details
error: Check-out failed for Advanced Anti-Malware daemon (/usr/sbin/aamwd) without
details
error: tenant TSYSl has no profile assigned
error: Check-out failed for IFF daemon (/usr/sbin/ipfd) without details
error: configuration check-out failed
[edit system login]

lab@vSRX-l#
Question: Did the configuration commit successfully? Why not?
Answer: The configuration did not commit successfully because a

security profile needs to be attached to the tenant.

Step 2.7
Create a security profile that will be shared by tsysi and tsys2. Navigate to the [edit system
security-profile] hierarchy and configure a security profile named SP-Small. Set the maximum
to 100 and the reserve to 50 for the policy, zone, flow-session, nat-nopat-address, and
auth-entry settings.
[edit system login]
lab@vSRX-l# up 1 edit security-profile
[edit system security-profile]

lab@vSRX-l# set SP-Small policy maximum 100

lab@vSRX-l# set SP-Small policy reserved 50

lab@vSRX-l# set SP-Small zone maximum 100

lab@vSRX-l# set SP-Small zone reserved 50

lab@vSRX-l# set SP-Small flow-session maximum 100

lab@vSRX-l# set SP-Small flow-session reserved 50

lab@vSRX-l# set SP-Small nat-nopat-address maximum 100

lab@vSRX-l# set SP-Small nat-nopat-address reserved 50

lab@vSRX-l# set SP-Small auth-entry maximum 100

lab@vSRX-l# set SP-Small auth-entry reserved 50

lab@vSRX-l#
step 2.8
Assign the security profile SP-Small to tsysi and tsys2.

lab@vSRX-l# set SP-Small tenant TSYSI

lab@vSRX-l# set SP-Small tenant TSYS2
Step 2.9
Verify the security profile configuration using the show command.
lab@vSRX-l# show

SP-Small {
auth-entry {
maximum 100;
reserved 50;
}
policy {
maximum 50;
reserved 50;
}
zone {
maximum 50;
reserved 50;
}
flow-session {
maximum 100;
reserved 50;
}
nat-nopat-address {
maximum 100;
reserved 50;
}
tenant [ TSYSl TSYS2 ] ;
}

lab@vSRX-l#
Question: Could each tenant system have its own security profile?
Answer: Yes, a security profile could be made for each tenant system.
Any number of tenants may be assigned to this security profile.
Step 2.10
Commit the changes to the configuration.
commit complete
lab@vSRX-l>
Step 2.11
Open another SSH session from the dashboard to the vSRX-1 device using TSYSladminl as the
username and labl23 as the password.
# ssh TSYSladminlf^ 172.25.11.1
Password: labl23
TSYSladminl@vSRX-l:TSYS1>

Question: What can you understand from the prompt?
Answer: You can understand that you are logged into the vSRX-1
device as TSYSladminl, and that you are in the TSYSl tenant.
Question: What did you just confirm by logging in with the

TSYSladmin user?
Answer: That the tenant was created successfully and is functional.
Step 2.12
Verify the security-profile is set up correctly with the tenant. Use the show system
security-profile command.
TSYSladminl@vSRX-l:TSYS1> show system security-profile ?
Possible completions:
address-book Show address-book resource information
all-resource Show all resources information
auth-entry Show authentication resource information
cpu Show CPU utilization information
dslite-softwire-initiator Show security dslite softwire initiator resource
information
flow-gate Show flow gate resource information
flow-session Show flow session resource information
icap-redirect-profile Show ICAP redirect profile resource information
nat-cone-binding Show nat cone binding resource information
nat-destination-pool Show nat destination pool resource information
nat-destination-rule Show nat destination rule resource information
nat-interface-port-ol Show nat interface port overloading resource information
nat-nopat-address Show nat source nopat address resource information
nat-pat-address Show nat source pat address resource information
nat-pat-portnum Show nat source pat port number resource information
nat-port-ol-ipnumber Show nat port overloading resource information
nat-rule-referenced-prefix Show nat rule referenced IP-prefix information
nat-source-pool Show nat source pool resource information
nat-source-rule Show nat source rule resource information
nat-static-rule Show nat static rule resource information
policy Show policy resource information
policy-with-count Show resource information of policy with count
scheduler Show scheduler resource information
security-log-stream-number Show security log stream number information
zone Show zone resource information
TSYSladminl@vSRX-l:TSYS1>
Step 2.13
Look at the zone and policy settings to see the resource usage information.
TSYSladminl@vSRX-l:TSYS1> show system security-profile zone

logical-system tenant name security profile name usage reserved maximum
TSYSl SP-Small 0 50 100

TSYSladminl@vSRX-l:TSYSl show system security-profile policy
logical-system tenant name security profile name usage reserved maximum
TSYSl SP-Small 0 50 100
Question: How many zones and policies are used by the TSYSl
tenant?
Answer: There are no zones or policies used yet.
Step 2.14
Return to the open SSH session to vSRX-1 with the master administrator login.
Change to configuration mode. Move to the [edit tenants tsysI] hierarchy. Configure a routing
instance named rsysi, and the interface ge-0/0/4.0 with an IP address of 10.10.101.1/24
within tenant TSYSl.
[edit]
lab@vSRX-l# edit tenants TSYSl

lab@vSRX-l# set interfaces ge-0/0/4 unit 0 family inet address 10.10.101.1/24

lab@vSRX-l# set routing-instances RSYSI instance-type virtual-router

lab@vSRX-l# set routing-instances RSYSI interface ge-0/0/4.0

lab@vSRX-l#
Step 2.15
Move to the [edit tenants TSYS2] hierarchy and configure the following parameters:
Interface: ge-0/0/5.0
IPaddress: 10.10.102.1/24
Routing instance: rsys2
Attach the interface to the routing instance.
lab@vSRX-l# up 1 edit TSYS2
[edit tenants TSYS2]

lab@vSRX-l# set interfaces ge-0/0/5 unit 0 family inet address 10.10.102.1/24


lab@vSRX-l# set routing-instances RSYS2 instance-type virtual-router

lab@vSRX-l# set routing-instances RSYS2 interface ge-0/0/5.0

lab@vSRX-l#
Step 2.16
Verify the configuration by issuing the show com nnand at the [edit tenants] hierarchy.

lab@vSRX-l# up
[edit tenants]
lab@vSRX-l# show
TSYSl {
interfaces {
ge-0/0/4 {
unit 1 {
vlan-id 101;
family inet {
address 10.10.101.1/24;
}
}
}
}
routing-instances {
RSYSl {
}
}
}
TSYS2 {
interfaces {
ge-0/0/5 {
unit 2 {
vlan-id 102;
family inet {
address 10.10.102.1/24;
}
}
}
}
routing-instances {
RSYS2 {
}
}
}

Step 2.17
Nava gate to the top of the hierarchy and configure interface lt-0/0/0 unit 1 with an IP address of
10.1.1.1/24 and a peer unit of 2.
lab@vSRX-l# top
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 1 family inet address 10.1.1.1/24
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 1 peer-unit 2
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 1 encapsulation ethernet
[edit]
lab@vSRX-l#
Step 2.18
Configure interface lt-0/0/0 unit 2 with an IP address of 10.1.1.2/24 and a peer unit of 1.
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 2 family inet address 10.1.1.2/24
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 2 peer-unit 1
[edit]
lab@vSRX-l# set interfaces lt-0/0/0 unit 2 encapsulation ethernet
[edit]
lab@vSRX-l#
Step 2.19
Commit the configuration and exit to operational mode.
[edit tenants]
commit complete
lab@vSRX-l>
Part 3: Tenant Administrator Tasks
In this part you will configure tenant level options like security zones, security policies, and attaching
interfaces to the tenant routing instances. Then you will verify that the configuration is correct by sending
traffic across the network and verify flow sessions have been created.
Step 3.1
From the open session with vSRX-1. Switch to the TSYSl tenant as the administrator. Enter configuration
mode.

lab@vSRX-l> set cli tenant TSYSl

Tenant: TSYSl
lab@vSRX-l:TSYS1> configure
[edit]
lab@vSRX-l:TSYSl#
Step 3.2
Navigate to the [edit routing-instances RSYSl] hierarchy, and configure interface
lt-0/0/0.1 as part of the routing instance.
[edit]
lab@vSRX-l:TSYSl# edit routing-instances RSYSl
[edit routing-instances RSYSl]

lab@vSRX-l:TSYSl# set interface lt-0/0/0.1

lab@vSRX-l:TSYSl#
Step 3.3
Configure a security zone named to-ACME with host inbound system services set to all and add the
lt-0/0/0.1 interface .
lab@vSRX-l:TSYSl# top
[edit]
lab@vSRX-l:TSYSl# edit security zones security-zone to-ACME
[edit security zones security-zone to-ACME]

lab@vSRX-l:TSYSl# set host-inbound-traffic system-services all

lab@vSRX-l:TSYSl# set interfaces lt-0/0/0.1

lab@vSRX-l:TSYSl#
Step 3.4
Configure another security zone named Juniper-sv\N\ih host inbound system services set to all and
add the ge-0/0/4.0 interface.
lab@vSRX-l:TSYSl# up

lab@vSRX-l:TSYSl# edit security-zone Juniper-SV

lab@vSRX-l:TSYSl# set host-inbound-traffic system-services all

lab@vSRX-l:TSYSl# set interfaces ge-0/0/4.0


lab@vSRX-l:TSYSl#
Step 3.5
Verify the configuration fronn the [edit security zones] hierarchy with the show command.

lab@vSRX-l:TSYSl# show
security-zone to-ACME {
system-services {
all;
}
}
interfaces {
lt-0/0/0.1;
}
}
system-services {
all;
}
}
interfaces {
ge-0/0/4.0;
}
}

lab@vSRX-l:TSYSl#
Step 3.6
Commit the configuration and return to the operational mode prompt.
lab@vSRX-l:TSYSl# commit and-quit
commit complete
lab@vSRX-l:TSYS1>
Step 3.7
Run the show interfaces terse command to view the interfaces.
lab@vSRX-l:TSYS1> show interfaces terse
lt-0/0/0
lt-0/0/0.1 up up inet 10.1.1.1/24
ge-0/0/4
ge-0/0/4.0 up up inet 10.10.101.1/24

Question: Why are only 2 physical and 2 logical interfaces showing up

in the output?
Answer: The CLI was set to the tenant tsysi so it is the same as
logging in as the TSYSladminl user. Only the resources for that
tenant show up in output.
Step 3.8
Run the show route command to view the route tables.
lab@vSRX-l:TSYS1> show route
RSYSl.inet.0: 4 destinations. 4 routes (4 active, 0 holddown, 0 hidden)

10.1.1.0/24 ■k
[Direct/0] 16:08:24
> via lt-0/0/0.1
10.1.1.1/32 * [Local/0] 16:08:24
10.10.101.0/24 * [Direct/0] 00:16:42
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 00:16:42
RSYSl.inet6.0: 1 destinations. 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 *[INET6/0] 19:21:20

MultiRecv
lab@vSRX-l:TSYS1>
Note
Again only the route table associated with the tsysi tenant is
available to see from this prompt. If we cleared our tsysi tenant
prompt and went back to the master administrator all resources
would be visible.
Step 3.9
Return to the master administrator prompt by issuing the clear cli tenant command. Then run the
show interfaces terse and show route commands again.
lab@vSRX-l:TSYS1> clear cli tenant
Cleared default tenant
lab@vSRX-l> show interfaces terse

ge-0/0/0 up up
ge-0/0/0.0 up up inet 172.25.11.1/24

lt-0/0/0 up up
lt-0/0/0.1 up up inet 10.1.1.1/24
lt-0/0/0.2 up up inet 10.1.1.2/24
lt-0/0/0.32767 up up
mt-0/0/0 up up
sp-0/0/0 up up
sp-0/0/0.0 up up inet
inet6
sp-0/0/0.16383 up up inet
ge-0/0/1 up up
ge-0/0/1.0 up up inet 172.18.1.2/30
ge-0/0/2 up up
ge-0/0/3 up up
ge-0/0/4 up up
ge-0/0/4.0 up up inet 10.10.101.1/24
lab@vSRX-l> show route
inet.0: 6 destinations, 6 routes (6 active. 0 holddown, 0 hidden)

0.0.0.0/0 [Static/5] 6d 17:08:21

> to 172.18.1.1 via ge-0/0/1.0
10.1.1.0/24 [Direct/0] 16:26:01
> via lt-0/0/0.2
10.1.1.2/32 [Local/0] 16:26:01
172.18.1.0/30 [Direct/0] 6d 17:08:21
> via ge-0/0/1.0
172.18.1.2/32 [Local/0] 6d 17:08:21
172.25.11.0/24 [Direct/0] 6d 18:07:44
> via ge-0/0/0.0
172.25.11.1/32 [Local/0] 6d 18:07:44
192.168.1.1/32 [Direct/0] 6d 18:09:40
> via loO.O

10.1.1.0/24 [Direct/0] 16:26:01

> via lt-0/0/0.1
10.1.1.1/32 [Local/0] 16:26:01
10.10.101.0/24 [Direct/0] 00:34:19
> via ge-0/0/4.0
10.10.101.1/32 [Local/0] 00:34:19
RSYS2.inet.0: 4 destinations. 4 routes (4 active, 0 holddown, 0 hidden)

10.10.102.0/24 [Direct/0] 00:34:19

> via ge-0/0/5.0

10.10.102.1/32 * [Local/0] 00:34:19
inetO.O: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 * [INET6/0] 6d 18:09:41

MultiRecv
RSYSl.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 * [INET6/0] 19:38:57

MultiRecv
RSYS2.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 ■k
[INET6/0] 19:38:57
MultiRecv
lab@vSRX-l>
Question: What is the difference in output, between the TSYSl prompt

and the master administrator prompt?
Answer: The master administrator prompt shows all the resources on

the SRX Series device where the TSYSl prompt only shows the
resources for that single tenant.
step 3.10
Run the show security zones command to view all the security zones.
lab@vSRX-l> show security zones

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

Interfaces bound: 1
Interfaces:
ge-0/0/1.0


Interfaces bound: 0
Interfaces:
lab@vSRX-l>
Question: Why are the Juniper-SV and the to-ACME zones not being
displayed by the master administrator prompt?
Answer: The security hierarchy is independent so that the tenant

administrators can run each tenant individually.
Step 3.11
Return to the tsysi tenant prompt and run the show security zones command again.
lab@vSRX-l> set cli tenant TSYSI
Tenant: TSYSI
lab@vSRX-l:TSYS1> show security zones

Interfaces bound: 1
Interfaces:
ge-0/0/4.0
Security zone: to-ACME

Interfaces bound: 1
Interfaces:
lt-0/0/0.1
lab@vSRX-l:TSYS1>
Question: Did the Juniper-svar\6 the to-acme zones display this

time?
Answer: Yes, they did, they are part of the TS YSl tenant.
Question: Did the junos-host, untrust, or management zones

display with the tsysi prompt?
Answer: No, they are not part of the tsysi tenant and are not
displayed to the tenant administrator.

Step 3.12
Configure an address book entry for the Juniper-svar\6 the ACME-svsubnets so that a policy can be
configured to pass traffic. Configure two address books and attach them to the Juniper-svar\6 the
to-ACME zones.
[edit]
lab@vSRX-l:TSYSl# edit security address-book
[edit security address-book]

lab@vSRX-l:TSYSl# set Juniper address Juniper-SV-NET 10.10.101.0/24

lab@vSRX-l:TSYSl# set Juniper attach zone Juniper-SV

lab@vSRX-l:TSYSl# set ACME address ACME-SV-NET 10.10.102.0/24

lab@vSRX-l:TSYSl# set ACME attach zone to-ACME

lab@vSRX-l:TSYSl#
step 3.13
Configure a security policy named allow-acme, to allow all traffic that originates in the Juniper-sv
zone to pass to the to-acme zone.
[edit security]
lab@vSRX-l:TSYSl# edit policies from-zone Juniper-SV to-zone to-ACME
[edit security policies from-zone Juniper-SV to-zone to-ACME]

lab@vSRX-l:TSYSl# set policy allow-ACME match source-address Juniper-SV-NET

lab@vSRX-l: TSYSl# set policy allow-ACME match destination-address ACME-SV-NET

lab@vSRX-l:TSYSl# set policy allow-ACMB match application any

lab@vSRX-l:TSYSl# set policy allow-ACME then permit

lab@vSRX-l:TSYSl#
Step 3.14
Verify the security configuration using the show command.


lab@vSRX-l:TSYSl# up 2
[edit security]
lab@vSRX-l:TSYSl# show
address-book {
Juniper {
address Juniper-SV-NET 10.10.101.0/24;
attach {
zone Juniper-SV;
}
}
ACME {
address ACME-SV-NET 10.10.102.0/24;
attach {
zone to-ACME;
}
}
}
policies {
from-zone Juniper-SV to-zone to-ACME {
policy allow-ACME {
match {
source-address Juniper-SV-NET;
destination-address ACME-SV-NET;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone to-ACME {
system-services {
r
}
}
interfaces {
lt-0/0/0.1;
}
}
system-services {
r
}
}
interfaces {
ge-0/0/4.0;
}
}
}

[edit security]
lab@vSRX-l:TSYS1#
Step 3.15
Return to the established session with the vSRX-VR device.
Run the ping command to from the vrlOl host to the vrl02 host in the acme-sv zone io verify the
connection.
lab@vSRX-VR> ping 10.10.102.1 routing-instance vrlOl
PING 10.10.102.1 (10.10.102.1): 56 data bytes
4 5 00 0054 1015 0 0000 40 01 7f75 10.10.101.10 10.10.102.1
Question: Was the ping successful? If not what is the error message?
Answer: No, the ping was not successful. Host 10.10.101.1 which is
the gateway replied that the destination net is unreachable.
Step 3.16
Return to the established session on the vSRX-1 device.
Display the routes using the show route command.
[edit security]
lab@vSRX-l:TSYSl# run show route

10.1.1.0/24 ■k
[Direct/0] 18:36:57
> via lt-0/0/0.1
10.1.1.1/32 * [Local/0] 18:36:57
10.10.101.0/24 * [Direct/0] 02:45:15
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 02:45:15
RSYSl.inet6.0: 1 destinations. 1 routes (1 active, 0 holddown, 0 hidden)

ff02::2/128 *[INET6/0] 21:49:53

MultiRecv
[edit security]
lab@vSRX-l:TSYSl#

Question: Which route will 10.10.102.1 take?
Answer: None, there is no route for this prefix.
Step 3.17
Add a route for 10.10.102.0/24 that uses 10.1.1.2 as the next-hop address.
[edit security]
[edit]
lab@vSRX-l:TSYSl# edit routing-instances RSYSl routing-options
[edit routing-instances RSYSl routing-options]

lab@vSRX-l:TSYSl# set static route 10.10.102.0/24 next-hop 10.1.1.2

lab@vSRX-l:TSYSl#
Step 3.18
lab@vSRX-l:TSYSl# commit
commit complete

lab@vSRX-l:TSYSl#
Step 3.19
Test connectivity to the vrl 02 host from the vrl 01 host, using the ping command.
PING 10.10.102.1 (10.10.102.1): 56 data bytes
Question: Is there an error message returned?
Answer: No, there is no error message.
Step 3.20
Return to the established session on the vSRX-1 device.
Display the sesion table by running the show security flow session command.
lab@vSRX-l:TSYSl# run show security flow session
Session ID: 20437, Policy name: allow-ACME/4, Timeout: 2, Valid
In: 10.10.101.10/22043 10.10.102.1/117;icmp. Conn Tag: 0x0, If: ge-0/0/4.0.

Out: 10.10.102.1/117 10.10.101.10/22043;icmp. Conn Tag: 0x0, If: lt-0/0/0.1.

Pkts : 0, Bytes: 0,

Pkts : 1< Bytes: 84,
Out: 10.10.102.1/118 10.10.101.10/22043;icmp. Conn Tag: 0x0, If: lt-0/0/0.1.
Pkts : 0, Bytes: 0,
Question: Is there sessions for ICMP traffic from 10.10.101.10?
Answer: Yes, there are sessions originating from 10.10.101.10 to

10.10.102.1.
Answer: That the tsysi tenant is forwarding traffic to 10.10.102.1

out the lt-0/0/0.1 interface.
Step 3.21
Exit out of TSYSl cli and enter into tsys2 administrative prompt.
lab@vSRX-l:TSYSl# top
[edit]
lab@vSRX-l:TSYSl# exit
lab@vSRX-l:TSYS1> clear cli tenant

lab@vSRX-l> set cli tenant TSYS2

Tenant: TSYS2
lab@vSRX-l:TSYS2
Step 3.22
Use the show security policies command to view the policies in TSYS2.
lab@vSRX-l:TSYS2 show security policies
lab@vSRX-l:TSYS2

Question: What is the default policy for tsys2?
Answer: The default policy is to deny-all traffic that does not

match a security policy.
Step 3.23
Enter configuration mode and set the default policy of tsys2 to permit-all.
[edit]
lab@vSRX-l:TSYS2# set security policies default-policy permit-all
[edit]
lab@vSRX-l:TSYS2#
Step 3.24
Commit the changes.
[edit]
lab@vSRX-l:TSYS2# commit
commit complete
[edit]
lab@vSRX-l:TSYS2#
Step 3.25
Use the show security policies command to view the policies in tsys2.
[edit]
lab@vSRX-l:TSYS2# run show security policies
Default policy: permit-all
[edit]
lab@vSRX-l:TSYS2#
Step 3.26
Exitoutofthe tsys2 tenant prompt and run the show security policies command from the
master administrative prompt.
[edit]
labQvSRX-1:TSYS2# exit
lab@vSRX-l:TSYS2 clear cli tenant

lab@vSRX-l> show security policies


lab@vSRX-l>
Question: Did changing the default policy settings in tsys2 have any
impact on other tenants?
Answer: No, that policy change only impacted tsys2.
Step 3.27
Change to the tsys2 administrative prompt again and enter configuration mode.
lab@vSRX-l> set cli tenant TSYS2
Tenant: TSYS2
[edit]
lab@vSRX-l:TSYS2#
Step 3.28
Configure a route for the 10.10.101.0/24 prefix with the next hop of 10.1.1.1, and add the lt-0/0/0.2
interface into the rsys2 routing instance.
lab@vSRX-l:TSYS2# edit routing-instances RSYS2 routing-options
[edit routing-instances RSYS2 routing-options]

lab@vSRX-l:TSYS2# set static route 10.10.101.0/24 next-hop 10.1.1.1

lab@vSRX-l:TSYS2# up
[edit routing-instances RSYS2 ]

lab@vSRX-l:TSYS2# set interface lt-0/0/0.2
[edit routing-instances RSYS2 ]

lab@vSRX-l:TSYS2#
Step 3.29
Configure a zone named ACME-svwith host inbound traffic all and add interface ge-0/0/5.0 and
lt-0/0/0.2 into it.
lab@vSRX-l:TSYS2# top edit security zones

lab@vSRX-l:TSYS2# set security-zone ACME-SV host-inbound-traffic system-services

lab@vSRX-l:TSYS2# set security-zone ACME-SV interfaces ge-0/0/5.0

lab@vSRX-l:TSYS2# set security-zone ACME-SV interfaces lt-0/0/0.2


lab@vSRX-l:TSYS2#
Step 3.30
Go up to the security hierarchy level and verify the configuration with a show command.
lab@vSRX-l:TSYS2# up
[edit security]
labOvSRX-1:TSYS2# show
policies {
default-policy {
permit-all;
}
}
zones {
security-zone ACME-SV {
system-services {
r
}
}
interfaces {
ge-0/0/5.0;
lt-0/0/0.2;
}
}
}
[edit security]
lab@vSRX-l:TSYS2#
step 3.31
Commit the configuration changes.
[edit security]
lab@vSRX-l:TSYS2# commit
commit complete
[edit security]
lab@vSRX-l:TSYS2#
Step 3.32
Start an SSH session from vrlOl to 10.10.102.10. Log in as lab and say yes if any warnings come up
about adding the host to the list of known hosts.
ECDSA key fingerprint is SHA256:xL2BMAT2zVipnPkkUb2sHdfZ4ajFMzEz5sh/xOHGAlE .
Password: labl23


lab@vSRX-VR>
Question: Was the SSH connection successful?
Answer: Yes, the login completed.
Step 3.33
Return to the open session on the vSRX-1 device, and run the show security flow session from
each of the tenant systems to compare.
[edit security]
lab@vSRX-l:TSYS2# top
[edit]
lab@vSRX-l:TSYS2# exit
lab@vSRX-l:TSYS2 show security flow session

Session ID: 29447, Policy name: default-policy-logical-system-33/2. Timeout: 1778,
Valid
In: 10.10.101.10/58427 10.10.102.10/22;tcp. Conn Tag: 0x0, If: lt-0/0/0.2.
Pkts : 12, Bytes: 2389,
Out: 10.10.102.10/22 10.10.101.10/58427;top. Conn Tag: 0x0, If: ge-0/0/5.0.
Pkts : Bytes: 2305,
Total sessions: 1
lab@vSRX-l:TSYS2 clear cli tenant

lab@vSRX-l> set cli tenant TSYSl

Tenant: TSYSl
lab@vSRX-l:TSYS1> show security flow session

Out: 10.10.102.10/22 10.10.101.10/58427;top. Conn Tag: 0x0, If: lt-0/0/0.1.
Total sessions: 1
lab@vSRX-l:TSYS1>

Question: How many sessions were created for this single SSH
connection?
Answer: There are two sessions created. One in each of the tenant
systems.
Question: What are the session IDs for the two flows? Are they the
same session?
Answer: The session ID will be unique to your lab, but the session ID
from each of the tenant systems will be a different number showing
that two sessions are being used to forward this traffic.
step 3.34
Exit from the tenant system enter configuration mode and from the a J sec directory load the
ldb6-start. config. Commit the start config. This will remove the tenant systems from the vSRX-1
device. You will notice error messages about tenant systems configurations left in configuration. Exit out
of configuration mode.
lab@vSRX-l:TSYS1> clear tenant
[edit]
lab@vSRX-l# load override a.jsec/lab6-start.config
load complete
lab@vSRX-l# commit
[edit tenants TSYSl security address-book Juniper attach]
’ zone I
warning: patch removes statement that is not empty
[edit tenants TSYSl security address-book ACME attach]
’ zone I
[edit tenants TSYSl security]
’address-book’
warning: Load error seen when propagating changes into tenant database
commit complete
[edit]
lab@vSRX-l# exit
lab@vSRX-l>

Step 3.35
Return to the established session on the vSRX-VR device.
Close the SSH session.
lab@vSRX-VR> exit
lab@vSRX-VR>

vSRX-1 HS
ATP Cloud
rr?T7T Physical
vSRX-VR SiS 172.25.11.254 1
1
Internet
vQFX-1 Console and
VNC Connections
Junos
Space
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
Gateway 172.25.11.254
©2020 Juniper Networks, Inc. Al Rights Reserved.

juniper
NS-’ACPr,
“ir'ACPr-,


Implementing Tenant Systems
vSRX-VR
CD
172.18.1.0/30
(•2) ge-0/0/1
vSRX-1
(.1) 10.1.1.0/24 (.2)
TSYS1 lt-0/0/0.2
TSYS2
It-0/0/0.1
to-ACME zone ACME-SV zone
(.1) ge-0/0/4 ge-0/0/5 (.1)
10.10.101.0/24 10.10.102.0/24
(•10) (.10)
vrIOI vr102
Juniper-SV zone ACME-SV zone

juniper
NETWORKS


Lab
PKI and ADVPNs
Overview
In this lab, you will configure PKI and an Auto Discovery VPN (ADVPN). You will use the Junos CLI to
configure certificates on the devices. Then, you will configure an ADVPN to securely route traffic sourced
fromthe virtual routers {vrl 01, vrl02, vr201, vr202} through the vSRX-1, vSRX-2 and vSRX-VR
devices.
• Configure PKI settings on the devices.
• Generate and sign certificate requests from the devices.
• Configure an ADVPN.
• Monitor and test the function of the ADVPN.
www.juniper.net PKI and ADVPNs • Lab 7-1

Part 1: Configuring PKI Settings
devices. Next, you will load the starting configuration for the lab. You will then generate and sign the
certificates that will be used for the ADVPN configuration. Finally, you will configure the PKI settings on
the devices.
Note

Step 1.1
Consult the Management Network Diagram to determine the management addresses of your devices.

devices?
Answer: The answer varies between delivery environments. The sample

output examples in this lab are from the vSRX-1 device, which has an IP
address of 172.25.11.1.
Step 1.2
Access the student desktop using the virtual console. Use the user name lab and the password Iabl23.
Open a terminal session and browse to the Desktop/Certif icates directory. Ensure that only the
ca cert. pern file exists. Delete any other files in this directory. Do not delete the ca cert. pern file!
Last login: Fri Apr 20 13:36:29 2018 from 172.25.11.1
[labSdesktop ]$ Is Desktop/Certificates/
ca_cert.pern
[labSdesktop ]$
Step 1.3
Access the command-line interface (CLI) for the vSRX-1 device from the student desktop by opening a
terminal session and typing ssh 172.25.11.1.
Note
In this lab part, you will be required to copy and paste data from the vSRX
sessions to local files on the student desktop. For this reason, you will need
to access the vSRX devices using SSH by opening a GUI session with the
student desktop and using the terminal program.
Login with the username lab and password labl23. Enter configuration mode and load the
lab7-start, config^rora the ajsec directory. Commit the configuration when complete.
[labOdesktop ]$ ssh 172.25.11.1
Warning: Permanently added ’172.25.11.1’ (RSA) to the list of known hosts.
Password:
Last login: Wed Mar 14 19:47:41 2018 from 172.25.11.254
-- JUNOS 17.4R1.16 Kernel 64-bit JNPR-11.0-20171206.f4cad52 bull
Lab 7-2 • PKIandADVPNs www.juniper.net

[edit]
load complete
[edit]
lab@vSRX-l# commit
commit complete
Step 1.4
Access the command-line interface (CLI) for the vSRX-2 device from the student desktop by
opening a separate terminal session and typing ssh 172.25.11.2.
and load the lab7-start. conf igfrom the a j sec directory. Commit the configuration when
complete and exit to operational mode.
login: lab
Password:

[edit]
load complete
[edit]
commit complete
lab@vSRX-2
Step 1.5
Access the command-line interface (CLI) for the vSRX-VR device from the student desktop by
opening a separate terminal session and typing ssh 172.25.11.9.
On the vSRX-VR device, login with the username lab and password labl23. Enter configuration mode
and load the lab7-start. conf igfrom the aj sec directory. Commit the configuration when
login: lab
Password:


[edit]
load complete
[edit]
commit complete
Exiting configuration
lab@vSRX-VR>
Step 1.6
On the vSRX-1 device, configure the suiteB ca-prof ile to use a ca-identity of sui teB.
Disable revocation checks. Commit then exit to operational mode.
[edit]
lab@vSRX-l# edit security pki
[edit security pki]

lab@vSRX-l# set ca-profile SuiteB ca-identity suiteB
[edit security pki]

lab@vSRX-l# set ca-profile SuiteB revocation-check disable
[edit security pki]

commit complete
lab@vSRX-l>
Step 1.7
Use the SCP utility to retrieve the ca_cert .pem file from the Desktop/Certificates directory on
the student desktop device. Login with the username lab and password labl23.
lab@vSRX-l> scp 172.25.11.254:~/Desktop/Certificates/ca_cert.pem .
ECDSA key fingerprint is SHA256:fBR3Hkj5sGfZnk9XSkj/rUC/+OzRQEWWwtHW7qT5kOs.
Warning: Permanently added ’172.25.11.254 I (ECDSA) to the list of known hosts.
lab@172.25.11.254's password: labl23
ca cert.pem 100% 964 1.2MB/S 00:00
lab@vSRX-l>
Step 1.8
Use the SCP utility to retrieve the ca_cert .pern file from the Desktop/Certificates directory on
lab@vSRX-2 scp 172.25.11.254:~/Desktop/Certificates/ca_cert.pem .
ECDSA key fingerprint is SHA256:fBR3Hkj5sGfZnkOXSkj/rUC/+OzRQEWWwtHW7qT5kOs.


lab@172.25.11.254’s password: labl23
ca cert.pem 100% 964 1.2MB/S 00:00
lab@vSRX-2
Step 1.9
Use the SCP utility to retrieve the ca_cert .pem file from the Desktop/Certificates directory on
lab@vSRX-VR> scp 172.25.11.254:~/Desktop/Certificates/ca_cert.pem .
ECDSA key fingerprint is SHA256:fBRSHkj5sGfZnk9XSkj/rUC/+OzRQEWWwtHW7qT5kOs.
lab@172.25.11.254’s password: labl23
ca cert.pem 100% 964 1.2MB/S 00:00
lab@vSRX-VR>
Step 1.10
On the vSRX-1 device, delete any local certificates, certificate requests, and key pairs.
lab@vSRX-l> clear security pki local-certificate all
lab@vSRX-l> clear security pki certificate-request all
lab@vSRX-l> clear security pki key-pair all

Step 1.11
Load the ca cert .pern certificate as the ca-certif icate.
lab@vSRX-l> request security pki ca-certificate load ca-profile SuiteB filename
ca_cert .pem
Fingerprint:
7d:25:5c:91:87:5c:d4:c9:la:24:e2:b4:f8:d7:0b:8a:44:21:2a:73 (shal)
61:c2:c2:41:0f:12:95:8d:84:3c:a8:06:Of :3c:fa:01 (md5))
Do you want to load this CA certificate ? [yes,no] (no) yes
CA certificate for profile SuiteB loaded successfully

Step 1.12
Generate a new key-pair in the SuiteB CA profile using the ECDSA type with a size of 384 bits. Use a
certificate ID name of vSRX-1.
lab@vSRX-l> request security pki generate-key-pair type ecdsa size 384

certificate-id vSRX-l
Generated key pair vSRX-1, key size 384 bits
Step 1.13
On the vSRX-2 device, delete any local certificates, certificate requests, and key pairs.
lab@vSRX-2 clear security pki local-certificate all

lab@vSRX-2 clear security pki certificate-request all
lab@vSRX-2 clear security pki key-pair all
Step 1.14
Load the ca cert .pem certificate as the ca-certif icate.
lab@vSRX-2 request security pki ca-certificate load ca-profile SuiteB filename
ca_cert .pem
Fingerprint:
61:c2:c2:41:Of:12:95:8d:84:3c:a8:06:Of:3c:fa:01 (md5)

Step 1.15
Generate a new key-pair in the Sui teB CA profile using the ECDSA type with a size of 384 bits. Use a
certificate ID name of vSRX-2.
lab@vSRX-2 request security pki generate-key-pair type ecdsa size 384
certificate-id vSRX-2
Generated key pair vSRX-2, key size 384 bits
Step 1.16
On the vSRX-VR device, delete any local certificates, certificate requests, and key pairs.
lab@vSRX-VR> clear security pki local-certificate all
lab@vSRX-VR> clear security pki certificate-request all
lab@vSRX-VR> clear security pki key-pair all

Step 1.17
Load the ca cert .pem certificate as the ca-certif icate.
lab@vSRX-VR> request security pki ca-certificate load ca-profile SuiteB filename
ca_cert .pem
Fingerprint:
61:c2:c2:41:Of:12:95:8d:84:3c:a8:06:Of:3c:fa:01 (md5)

Step 1.18
Generate a new key-pair in the Sui teB CA profile using the ECDSA type with a size of 384 bits. Use a
certificate ID name of vSRX-vr.
lab@vSRX-VR> request security pki generate-key-pair type ecdsa size 384
certificate-id vSRX-VR
Generated key pair vSRX-VR, key size 384 bits

Step 1.19
On the vSRX-1 device, generate a certificate request using the key pair generated previously with the
following criteria:
• Certificate ID: vSRX-1
Subject: DC=vSRX-1 . j uniper. net, CN=vSRX-l. j uniper. net, 0U=Base,
0=Juniper L=SunnyvaleST=California,C=US
Email: ajsec@j uniper. net
lab@vSRX-l> request security pki generate-certificate-request certificate-id
vSRX-1 subject "DC=vSRX-l.juniper.net,CN=vSRX-l.juniper.net,0U=Base,
0=Juniper,L=Sunnyvale,ST=California,C=US" email ajsec@ juniper.net
Generated certificate request

----- BEGIN CERTIFICATE REQUEST-----
MIIBxzCCAUsCAQAwgZgxIjAgBgoJkiaJk/lsZAEZFhJ2UlJYLTEuanVuaXBlci5u
ZXQxGzAZBgNVBAMTEnZTUlgtMS5qdW5pcGVyLm51dDENMAsGAlUECxMEQmFzZTEQ
MA4GAlUEChMHSnVuaXBlcjESMBAGAlUEBxMJU3Vubnl2YWxlMRMwEQYDVQQIEwpD
YWxpZm9ybmlhMQswCQYDVQQGEwJVUzB2MBAGByqGSM49AgEGBSuBBAAiA2lABBly
ecedDT+QO216LF9JDndrin637KG9LMAS2pumzxAHORCdtsrrCSgqBEE4aCPbGqKhy
QYd7nU3RGHChO10/QW/UnLMIeOATIjxQinLiEVA9Yn7b42OpdSQghOljwhQNZWKAz
MDEGCSqGSIb3DQEJDjEkMCIwIAYDVR0RBBkwF4EVInN0dWRlbnRAanVuaXBlci5u
ZXQiMAwGCCqGSM49BAMCBQADaAAwZQIxAOUpsDFu9ujBDQDgcO5u/EDwLlShD2CZ
VBOixX2SKuuHHmiTWP3a5h8L+6lnHjsVKQIwaYvXsO3GdX6stg5EJHt4AtHjMIHY
ZOg+BvDulwlMjWmM9RbKiGMmpg8 9kz31lAat
----- END CERTIFICATE REQUEST-----
Fingerprint:
ca:84:eb:2d:8b:aa:5a:03:40:9e:20:da:d6:74:9d:35:f8:83 : 83 : 48 (shal)
9c:c6:98:9a:ee:04:d6:74:cb:3f:b6:a0:b6:e0:ff:e7 (md5)
lab@vSRX-l>
Step 1.20
On the vSRX-2 device, generate a certificate request using the key pair generated previously with the
following criteria:
• Certificate ID: vSRX-2
Subject: DC=vSRX-2 . j uniper. net
CN=vSRX-2.juniper.net, 0U=Base,0=Juniper,L=Sunnyvale,ST=Californi
a,C=US
lab@vSRX-2 request security pki generate-certificate-request certificate-id
vSRX-2 subject "DC=vSRX-2.juniper.net,CN=vSRX-2.juniper.net,0U=Base,
0=Juniper,L=Sunnyvale,ST=California,C=US" email ajsec@ juniper.net
ZXQxGzAZBgNVBAMTEnZTUlgtMi5qdW5pcGVyLm51dDENMAsGAlUECxMEQmFzZTEQ
YWxpZm9ybmlhMQswCQYDVQQGEwJVUzB2MBAGByqGSM49AgEGBSuBBAAiA2lABDgj
aY5vbhQHB3xshl6lSa6AdBb7xlmOPUCMWZMRLlPxT25h9WkE+10fvAuyYRm8jSzq

8z8c51cQutre7ElZMqsbhKdhX4ImPkfXIkgfiKRCtntfZins73Z 9j 63zfqx9JRKAz
ZXQiMAwGCCqGSM49B7kMCBQADaAAwZQIwCqAFquwn3YR41pYoUYCqlLfYw5Vt7h4V
8rhdVkKY5UWckvgVA9kzj j oZvyRrE7/uAj EA2TpWrcW+j 0j rkt+8h9Xb7nQTiMBr
rrFlIigThxHSTQdBJHgfVXSWoIs7TJ2C4STA
Fingerprint:
Of:64:5c:db:72:4d:If:2f:18:Id:85:Id:f7:bb:a8:99:50:94:82:e7 (shal)
58:3d:9f:6b:a0:c2:12:20:fc:14:c0:lf:29:8e:78:77 (mdS)
lab@vSRX-2
Step 1.21
On the vSRX-VR device, generate a certificate request using the key pair generated previously with the
following criteria:
• Certificate ID: vSRX-vr
Subject: DC=vSRX-VR . j uniper. net,
CP=vSRX-\iR. juniper, net, OU=Base, O=Juniper L=Sunnyvale ST=Californi
a, C=US
lab@vSRX-VR> request security pki generate-certificate-request certificate-id
vSRX-VR subject "DC=vSRX-VR.juniper.net,CN=vSRX-VR.juniper.net,OU=Base,
0=Juniper,L=Sunnyvale,ST=California,C=US" email aj sec@ juniper.net
MIIByTCCAUOCAQAwgZoxIzAhBgoJkiaJk/lsZAEZFhN2UlJYLVZSLmplbmlwZXIu
bmV0MRwwGgYDVQQDExN2UlJYLVZSLmplbmlwZXIubinV0MQ0wCwYDVQQLEwRCYXNl
MRAwDgYDVQQKEwdKdW5pcGVyMRIwEAYDVQQHEwlTdW5ueXZhbGUxEzARBgNVBAgT
CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMHYwEAYHKoZIzjOCAQYFK4EEACIDYgAE
czlD9AwJl/0NNvArS88BA3svVthdh2V9Zqml43XeuvWFljK8jb7jGR4XwcK96gLk
Qa3tYvUGYMPRqVos6TKet8cBhIS7MGj5bWPuE8JugntWRFVfr8NtsgfzTthckvJ2
oDMwMQYJKoZIhvcNAQkOMSQwIjAgBgNVHREEGTAXgRUic3RlZGVudEBqdW5pcGVy
Lm51dCIwDAYIKoZIzjOEAwIFAANoADBlAjEAz69tP62MyjJclZGLMRcAbDNj 8gcK
bAA62xj 4htuQLayVM2r0qp9WURSzI4MqWkH9AjAL4TUqZIvsfrBinAdRQxsgwGMn
eRlwMC0Qin+KdoNhTIFZWrilGiIOSzay4XL8zd60 =
Fingerprint:
b9:61:d8:86:dl:f3:bf:98:ad:b2:3c:08:33:70:3f:e5:42:99:13:6c (shal)
7e:9b:e5:a2:89:ab:58:la:08:bl:0c:f5:30:4f:83:29 (md5)
lab@vSRX-VR>
Step 1.22
Open a new terminal window on the student desktop and navigate to the Desktop/Certif icates/
folder.
Create a new file called vSRX-1. csr by using vi.
Copythe contents of the certificate request from the previous vSRX-1 session by highlight!ng the text from
the---------- BEGIN CERTIFICATE REQUEST statement to the END CERTIFICATE
REQUEST Statement and pressing the Ctrl + c keyboard sequence.

Return to the student desktop terminal and press i to edit the file. Right-click in the empty file to copy
the certificate request.
Save the file by pressing Esc, then typing : wq! and pressing Enter.
Note
An issue with the copy+paste operation will sometimes cause the first few
characters (hypens) to be left off of the pasted text. If these are missing, fill
in the first line of the certificate so that it matches the output below.
[lab@desktop ]$ cd Desktop/Certificates/
[lab@desktop Certificates]$ vi vSRX-l.csr
---- BEGIN CERTIFICATE REQUEST-----

MIIBxzCCAUsCAQAwgZgxIjAgBgoJkiaJk/lsZAEZFhJ2UlJYLTEuanVuaXBlciSu
ZXQxGzAZBgNVBAMTEnZTUlgtMS5qdW5pcGVyLm51dDENMAsGAlUECxMEQinFzZTEQ
YWxpZm9ybmlhMQswCQYDVQQGEwJVUzB2MBAGByqGSM49AgEGBSuBBAAiA2lABBly
ecedDT+QO216LF9JDndrm637KG9LMAS2pumzxAHORCdtsrrCSgqBEE4aCPbGqKhy
QYd7nU3RGHChO10/QW/UnLMIeOATIjxQmLiEVA9Yn7b42OpdSQghOljwhQNZWKAz
ZXQiMAwGCCqGSM49BAMCBQADaAAwZQIxAJjtC5X2YBmaIw4gFgMLejsrn/+zZUql
lnr8SXXPyh4IroPJ91EKeEAymYexWkxwgAIwf3VJjT4faCZ7 6hkEybSLIyFm7uza
CAanlKaZAchGACzDjVq+bNF7mnkFTeZUzJOU
---- END CERTIFICATE REQUEST-----
: wq!
Step 1.23
Create a new file called vSRX-2. csrby using vim.
Copy the contents of the certificate request from the previous vSRX-2 session by highlighting the text
from the BEGIN CERTIFICATE REQUEST statement to the END
CERTIFICATE REQUEST Statement and pressing the Ctrl + c keyboard sequence.
Return to the student desktop terminal and press i to edit the file. Right-click in the empty file to copy
the certificate request.
[lab@desktop Certificates]$ vi vSRX-2.csr
---- BEGIN CERTIFICATE REQUEST-----

ZXQxGzAZBgNVBAMTEnZTUlgtMi5qdW5pcGVyLm51dDENMAsGAlUECxMEQinFzZTEQ
YWxpZm9ybmlhMQswCQYDVQQGEwJVUzB2MBAGByqGSM49AgEGBSuBBAAiA2lABDgj
aY5vbhQHB3xshl6lSa6AdBb7xlinOPUCMWZMRLlPxT25h9WkE+10fvAuyYRm8jSzq
8z8c51cQutre7ElZMqsbhKdhX4ImPkfXIkgfiKRCtntfZins73Z 9j 63zfqx9JRKAz
ZXQiMAwGCCqGSM49B7kMCBQADaAAwZQIwCqAFquwn3YR41pYoUYCqlLfYw5Vt7h4V
8rhdVkKY5UWckvgVA9kz j j oZvyRrE7 /uAj EA2TpWrcW-l-j 0 j rkt+8h9Xb7nQTiMBr
rrFlIigThxHSTQdBJHgfVXSWoIs7TJ2C4STA
: wq!
Step 1.24
Create a new file called vSRX- vr . csr by using vim.
Copy the contents of the certificate request from the previous vSRX-VR session by highlighting the text
from the - BEGIN CERTIFICATE REQUEST statement to the END CERTIFICATE
REQUEST Statement and pressing the Ctrl + c keyboard sequence.
Return to the student desktop terminal and press i to edit the file. Right-click in the empty file to copy the
certificate request.
[labSdesktop Certificates]$ vi vSRX-VR.csr

MIIByTCCAU0CAQAwgZoxIzAhBgoJkiaJk/lsZAEZFhN2UlJYLVZSLmplbmlwZXIu
bmV0MRwwGgYDVQQDExN2UlJYLVZSLmplbmlwZXIubinVOMQOwCwYDVQQLEwRCYXNl
MRAwDgYDVQQKEwdKdW5pcGVyMRIwEAYDVQQHEwlTdW5ueXZhbGUxEzARBgNVBAgT
CkNhbGlmb3 JuaWExCzAJBgNVBAYTAlVTMHYwEAYHKoZIz j 0CAQYFK4EEACIDYgAE
czlD9AwJl/0NNvArS88BA3svVthdh2V9Zqml43XeuvWFljK8jb7jGR4XwcK96gLk
Qa3tYvUGYMPRqVos6TKet8cBhIS7MGj5bWPuE8JugntWRFVfr8NtsgfzTthckvJ2
oDMwMQYJKoZIhvcNAQkOMSQwIjAgBgNVHREEGTAXgRUic3RlZGVudEBqdW5pcGVy
LmSldCIwDAYIKoZIzjOEAwIFAANoADBlAjEAz69tP62MyjJclZGLMRcAbDNj 8gcK
bAA62xj 4htuQLayVM2r0qp9WURSzI4MqWkH9AjAL4TUqZIvsfrBinAdRQxsgwGMn
eRlwMC0Qm+KdoNhTIFZWrilGiIOSzay4XL8zd60=
: wq!
Lab 7-10 • PKI and ADVPNs www.juniper.net

Step 1.25
In this step, you will use the local CA on the student desktop to sign the certificate requests from the
previous steps.
From the terminal session on the student desktop, navigate to the /etc/ssl/SuiteBCA folder. Sign
the certificate request for the vSRX-1 device by using the sudo command. Use the labl23 password
when prompted.
[lab@desktop Certificates]$ cd /etc/ssl/SuiteBCA
[lab@desktop SuiteBCA]# sudo openssl ca -in /home/lab/Desktop/Certificates/

vSRX-l.csr -out certs/vSRX-1.pem -keyfile ec_key.pem -cert cacert.pem -md
SHA384 -extfile subalt.txt
[sudo] password for lab:labl23
Using configuration from /usr/lib/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1048576 (0x100000)
Validity
Not Before: Jun 2 19:58:37 2020 GMT
Not After : Jun 2 19:58:37 2021 GMT
Subject:
countryName = US
stateOrProvinceName = California
organ!zationName = Juniper
organ!zationalUnitName = Base
commonName = vSRX-l.juniper.net
X509v3 extensions:
X509v3 Subject Alternative Name:
email:aj sec@juniper.net
Certificate is to be certified until Jun 2 19:58:37 2021 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries
Data Base Updated
Step 1.26
Copy the generated certificate to /home/lab/Desktop/Certif icates/vSRX-1 .pem.
[lab@desktop jsecCA]# sudo cp certs/vSRX-1.pern /home/lab/Desktop/Certificates/
vSRX-1.pem
Step 1.27
previous steps.
From the terminal session on the student desktop, navigate to the /etc/pki/CA/jsecCA folder. Sign
the certificate request for the vSRX-2 device by using the sudo command.
[lab@desktop jsecCA]$ sudo openssl ca -in /home/lab/Desktop/Certificates/
vSRX-2.csr -out certs/vSRX-2.pem -keyfile ec_key.pem -cert cacert.pem -md


Signature ok
Serial Number: 1048577 (0x100001)
Validity
Subject:
countryName = US
stateOrProvinceName = California
organizationName = Juniper
organizationalUnitName = Base
commonName = vSRX-2.juniper.net
X509v3 extensions:
email: aj sec(3 juniper. net

Data Base Updated
Step 1.28
Copy the generated certificate to /home/lab/Desktop/Certif icates/vSRX-2 .pern
[lab(3desktop jsecCA]# sudo cp certs/vSRX-2 .pern /home/lab/Desktop/Certificates/
vSRX-2.pern
Step 1.29
previous steps.
From the terminal session on the student desktop, navigate to the /etc/pki/CA/ j secCA folder. Sign
the certificate request for the vSRX-VR device by using the sudo command.
[lab(3desktop jsecCA]$ sudo openssl ca -in /home/lab/Desktop/Certificates/
vSRX-VR.csr -out certs/vSRX-VR.pem -keyfile ec_key.pem -cert cacert.pem -md
Signature ok
Serial Number: 1048578 (0x100002)
Validity
Subject:
countryName = US
StateOrProvinceName = California
organizationName = Juniper
organizationalUnitName = Base
commonName = vSRX-VR.juniper.net
X509v3 extensions:

email:aj sec@juniper.net

Data Base Updated
Step 1.30
Copy the generated certificate to /home/lab/Desktop/Certif icates/vSRX-VR. pem
[labOdesktop jsecCA]# sudo cp certs/vSRX-VR.pem /home/lab/Desktop/Certificates/
vSRX-VR.pem
Step 1.31
Return to the session with the vSRX-1 device.
Use the SCP utility to retrieve the vSRX-1 .pem file from the student desktop.
lab@vSRX-l> scp 172.25.11.254:~/Desktop/Certificates/vSRX-1.pem .
lab@172.25.11.254’s password:
vSRX-1.pem 100% 2440 4.3mb/s 00:00
lab@vSRX-l>
Step 1.32
Import the signed certificate using the request command.
lab@vSRX-l> request security pki local-certificate load certificate-id vSRX-1
filename vSRX-l.pem
Local certificate loaded successfully
Step 1.33
Return to the session with the vSRX-2 device.
Use the SCP utility to retrieve the vSRX-2 .pemtWe from the student desktop.
lab@vSRX-2 scp 172.25.11.254:~/Desktop/Certificates/vSRX-2.pem .
vSRX-2.pem 100% 2440 4.3mb/s 00:00
lab@vSRX-2
Step 1.34
Import the signed certificate using the request command.
lab@vSRX-2 request security pki local-certificate load certificate-id vSRX-2
filename vSRX-2.pem
Step 1.35
Use the SCP utility to retrieve the vSRX-VR.pem file from the student desktop.
lab@vSRX-VR> scp 172.25.11.254:~/Desktop/Certificates/vSRX-VR.pem .
vSRX-VR.pem 100% 2440 4.3MB/S 00:00

lab@vSRX-l>
lab@vSRX-VR>
Step 1.36
Innport the signed certificate using the request command.
lab@vSRX-VR> request security pki local-certificate load certificate-id vSRX-VR
filename vSRX-VR.pem
Part 2: Configuring the ADVPN
In this lab part, you will configure ADVPN with the vSRX-VR device acting as the hub and the vSRX-1 and
vSRX-2 devices acting as the spokes.
Step 2.1
On the vSRX-1 device, enter configuration mode.
Navigate to the [edit security ike] hierarchy and configure the IKE policy with the following
settings:
Policy Name: advpn-poll
Local Certificate: vSRX-1
Proposal Set: suiteb-gcm-2 5 6
[edit]
lab@vSRX-l# edit security ike policy advpn-poll
[edit security ike policy advpn-poll]

lab@vSRX-l# set certificate local-certificate vSRX-1

lab@vSRX-l# set proposal-set suiteb-gcm-256

lab@vSRX-l# show
certificate {
local-certificate vSRX-1;
}
proposal-set suiteb-gcm-256;

lab@vSRX-l#
Step 2.2
Configure the gateway settings with the following parameters:
• Gateway Name: advpn-gwl
IKE Policy: advpn-poll

Address: 192.168.9.1
Local Identity: distinguished-name
Remote Identity: distinguished-name container O=Juniper
External Interface: ge-0/0/1.0
ADVPN Suggester: disable
Version: v2-only
lab@vSRX-l# up 1 edit gateway advpn-gwl
[edit security ike gateway advpn-gwl]

lab@vSRX-l# set ike-policy advpn-poll


lab@vSRX-l# set local-identity distinguished-name

lab@vSRX-l# set remote-identity distinguished-name container O=Juniper

lab@vSRX-l# set external-interface ge-0/0/1.0

lab@vSRX-l# set advpn suggester disable

lab@vSRX-l# set version v2-only

lab@vSRX-l# show
ike-policy advpn-poll;
address 192.168.9.1;
local-identity distinguished-name;
remote-identity distinguished-name container O=Juniper;
external-interface ge-0/0/1.0;
advpn {
suggester {
disable;
}
}
version v2-only;

lab@vSRX-l#

Question: What is the effect of disabling the advpn suggester

setting?
Answer: The suggester setting configures the device to act as the hub by
distributing suggested shortcut tunnels to the spoke devices. Since vSRX-1 is
a hub device you will disable this function.
Step 2.3
Navigate to the [edit security ipsec] configuration hierarchy. Configure the following VPN
settings:
VPN Name: advpn-vpn
Policy Name: standard.

Proposal set: suiteb-gcm-25 6
Bind Interface: stO . 0
IKE
Gateway: advpn-gwl
IPSec Policy: standard
Establish Tunnels: immediately
lab@vSRX-l# top edit security ipsec

lab@vSRX-l# set policy standard proposal-set suiteb-gcm-256

lab@vSRX-l# set vpn advpn-vpn bind-interface stO.O

lab@vSRX-l# set vpn advpn-vpn ike gateway advpn-gwl

lab@vSRX-l# set vpn advpn-vpn ike ipsec-policy standard

lab@vSRX-l# set vpn advpn-vpn establish-tunnels immediately

lab@vSRX-l# show
policy standard {
proposal-set suiteb-gcm-256;
}
vpn advpn-vpn {
##
## Warning: Referenced interface must be configured under [edit interfaces]
hierarchy
##

ike {
gateway advpn-gwl;
ipsec-policy standard;
}
}

lab@vSRX-l#
Step 2.4
Next you will configure the stO interface. Assign an IP address of 10.25.0.1/24. Assign the stO
interface to a security zone named vpn. Commit the changes and exit to operational mode when
finished.
lab@vSRX-l# top edit interfaces
[edit interfaces]
[edit interfaces]
lab@vSRX-l# set stO unit 0 multipoint
[edit interfaces]
lab@vSRX-l# top set security zones security-zone vpn interfaces stO.O
[edit interfaces]
commit complete
lab@vSRX-l>
Step 2.5
Verify that the phase 1 and phase 2 IKE SAs establish between the vSRX-1 device and the vSRX-VR
device by running show security ike security-associations and show security
ipsec security-associations.
7275110 UP 632881f212182d40 02928c33bfb3bl71 IKEv2 192.168.9.1

67108866 ESP:aes-gcm-256/None 54a337fc 3560/ unlim - root 500 192.168.9.1
67108866 ESP:aes-gcm-256/None 2ee6715f 3560/ unlim - root 500 192.168.9.1

Question: Do the outputs from the last step indicate a successful IKE
negotiation?
Answer: Yes. The presence of one IKE security association and two IPsec
security associations indicate that the negotiation between the vSRX-1 and
vSRX-VR devices was successful.
Step 2.6
Check the state of the IPsec next hop tunnels by issuing show security ipsec
next-hop-tunnels.
lab@vSRX-l> show security ipsec next-hop-tunnels

Next-hop gateway interface IPSec VPN name Flag IKE-ID
XAUTH username
10.25.0.9 stO . 0 instance-GT-ADVPN-advpn-vpn-67108865 67108866 Auto C=US,
ST=California. O=Juniper, OU=Base, CN=vSRX-VR.juniper.net Not-Available
Question: What can you determine from this output?
Answer: Currently, the only IPsec tunnel available connects to the vSRX-VR
device. This indicates that no shortcut tunnels have yet been established.
Step 2.7
On the vSRX-1 device, check the contents of the routing table to see which destinations use the stO
interface.
lab@vSRX-l> show route table inet.O

0.0.0.0/0 -k [Static/5] 03:20:10

> to 172.18.1.1 via ge-0/0/1.0
10.1.1.254/32 * [Local/0] 02:49:24
Reject
10.10.101.0/24 * [Direct/0] 03:20:10
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 03:20:10
10.10.102.0/24 * [Direct/0] 03:20:10
> via ge-0/0/5.0
10.10.102.1/32 * [Local/0] 03:20:10
10.11.10.0/24 * [Direct/0] 02:49:24
> via ge-0/0/3.0
10.11.10.1/32 * [Local/0] 02:49:24
10.25.0.0/24 * [Direct/0] 01:09:49
> via stO.O
10.25.0.1/32 * [Local/0] 01:09:49
Local via stO.O

172.18.1.0/30 [Direct/0] 03:20:10

> via ge-0/0/1.0
172.18.1.2/32 [Local/0] 03:20:10
172.25.11.0/24 [Direct/0] 03:20:10
> via ge-0/0/0.0
172.25.11.1/32 [Local/0] 03:20:10
192.168.1.1/32 [Direct/0] 03:21:59
> via loO.O
lab@vSRX-l>
Question: Are the routes to the remote vr201 and vr202 networks
using the IPsec tunnel as intended? Why or why not?
Answer: No. Currently, the vSRX-1 device will use the default route through
the ge-0/0/3 interface to reach the remote networks. Though the IKE
negotiation was successful, there is currently no routing information to direct
traffic to the remote networks into the tunnel.
Part 3: Configuring Tunnel Routing Parameters

In this lab part, you will configure the required routing parameters to secure traffic between the vrl 01
vrl 02 instances attached to the vSRX-1 device and the vr201 and vr202 instances attached to the
vSRX-2 device.
step 3.1
Navigate to [edit protocols ospf] and add the stO . 0 interface to area 0 with the following
settings:
interface-type p2mp
demand-circuit
dynamic-neighbors
ge-0/0/4 passive
ge-0/0/5 passive
[edit]
lab@vSRX-l# edit protocols ospf area 0
[edit protocols ospf area 0.0.0.0]

lab@vSRX-l# set interface ge-0/0/4 passive

lab@vSRX-l# set interface ge-0/0/5 passive


lab@vSRX-l# set interface stO.O interface-type p2mp

lab@vSRX-l# set interface stO.O demand-circuit

lab@vSRX-l# set interface stO.O dynamic-neighbors

commit complete
lab@vSRX-l>
Question: Why are we configuring stO. 0 as an OSPF interface in

area 0?
Answer: Because shortcut tunnels are established dynamically between

partners, the peer devices need to be able to dynamically add and remove
the tunnel routes. The best method to accomplish this is through a dynamic
routing protocol.
Question: Why are we adding the ge-0/0/4 and ge-0/0/5

interfaces to OSPF in passive mode?
Answer: Simply adding the stO interface to OSPF will only cause OSPF to
advertise the stO tunnel endpoint addresses. By adding the ge-0/0/4 and
ge-0/0/5 interfaces to OSPF, the attached vrlOl and vrl02 networks
will be advertised to peers with the stO interfaces as the next hop. The
passive option is used to prevent adjacency formation across these links.
Step 3.2
Validate that the OSPF neighbor relationships are active by issuing the show ospf neighbors
command.
10.25.0.9 StO. 0 Down 0.0.0.0 0 22

Question: Why is the adjacency formation failing?
Answer: There are several reasons this could be happening. In this case,
even though we configured the stO interface to be part of the ypn zone,
we did not add the host-inbound-traffic configuration required to
allow IKE through the zone.
Step 3.3
To allow the OSPF peering to establish over the stO interface, configure OSPF under
host-inbound-traf f ic forthe vpn security zone. Commit the change and exit to operational mode.
[edit]
lab@vSRX-l# set security zones security-zone vpn host-inbound-traffic protocols
ospf
[edit]
commit complete
lab@vSRX-l>
Step 3.4
Validate that the OSPF neighbor relationships are active by issuing the show ospf neighbors
command.
10.25.0.9 StO. 0 Full 192.168.9.1 128
Question: What OSPF adjacencies are present?
Answer: You should see a single OSPF neighbor at 10.25.0.9. This is the
vSRX-VR device. If you do not see this neighbor in the Full state, check with
your instructor.
Step 3.5
Check the contents of the routing table to verify that the stO interfaces are used to reach the remote
vr201 and vr202 networks.
lab@vSRX-l> show route table inet.O
inet.O: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)

0.0.0.0/0 'k
[Static/5] 03:23:21
> to 172.18.1.1 via ge-0/0/1.0
10.1.1.254/32 * [Local/0] 02:52:35

Reject
10.10.101.0/24 ■k
[Direct/0] 03:23:21
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 03:23:21
10.10.102.0/24 * [Direct/0] 03:23:21
> via ge-0/0/5.0
10.10.102.1/32 * [Local/0] 03:23:21
10.10.201.0/24 * [OSPF/10] 00:00:40, metric 3
> to 10.25.0.9 via stO.O
10.10.202.0/24 * [OSPF/10] 00:00:40, metric 3
> to 10.25.0.9 via stO.O
10.11.10.0/24 * [Direct/0] 02:52:35
> via ge-0/0/3.0
10.11.10.1/32 * [Local/0] 02:52:35
10.25.0.0/24 * [Direct/0] 01:13:00
> via StO.O
10.25.0.1/32 * [Local/0] 01:13:00
Local via stO.O
10.25.0.2/32 * [OSPF/10] 00:00:40, metric 2
> to 10.25.0.9 via stO.O
10.25.0.9/32 * [OSPF/10] 00:00:40, metric 1
> to 10.25.0.9 via stO.O
172.18.1.0/30 * [Direct/0] 03:23:21
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] 03:23:21
172.25.11.0/24 * [Direct/0] 03:23:21
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] 03:23:21
192.168.1.1/32 * [Direct/0] 03:25:10
> via loO.O
224.0.0.5/32 * [OSPF/10] 00:01:29, metric 1
MultiRecv
Question: Is the correct routing information now in place? What is the

next-hop IP used to reach the remote vr201 and vr202 virtual
routers?
Answer: Yes. The routes use the stO interface IP of the vSRX-VR device,
10.25.0.1, as their next-hop.

Question: Why do the next hops for these routes not use the directly
connected interface to vSRX-2?
Answer: Because not traffic has yet been sent using this route, the vSRX-VR
device has not yet been triggered to suggest the shortcut tunnel directly to
vSRX-2.
step 3.6
On the vSRX-VR device, test routing through the IPsec tunnel by pinging from vrlOl to vr201.
PING 10.10.201.10 (10.10.201.10): 56 data bytes

Question: Why is the ping operation failing?
Answer: There are several possible causes. In this case, we have not yet
configured security policies to allow transit through the vpn zone on the
vSRX-1 device.
Step 3.7
On the vSRX-1 device, configure a global security policy to allow traffic from the vpn zone to any other
zone and vice-versa. Commit the change and exit configuration mode.
[edit]
lab@vSRX-l# edit security policies global policy vpn-to-all
[edit security policies global policy vpn-to-all]

lab@vSRX-l# set match from-zone vpn






lab@vSRX-l# show
match {
source-address any;
application any;
from-zone vpn;
}
then {
permit;
}
[edit security policies global vpn-to-all]

lab@vSRX-l# up 1 edit policy all-to-vpn
[edit security policies global policy all-to-vpn]




lab@vSRX-l# set match to-zone vpn


commit complete
lab@vSRX-l>
Step 3.8
On the vSRX-VR device, test the tunnel routingagain by pinging from vrlOlio vr201.
PING 10.10.201.10 (10.10.201.10): 56 data bytes
I I I I I
lab@vSRX-VR>
Step 3.9

On the vSRX-1 device, check to see the route used to reach the vr201 instance. Check the status of
IPsec tunnels available on the device with the show security ipsec next-hop-tunnels
command.
lab@vSRX-l> show route 10.10.201.10

10.10.201.0/24 [OSPF/10] 00:00:16, metric 2

> to 10.25.0.2 via stO.O
lab@vSRX-l> show security ipsec next-hop-tunnels

Next-hop gateway interface IPSec VPN name Flag IKE-ID
XAUTH username
10.25.0.2 stO . 0 instance-GT-ADVPN-advpn-vpn-67108867 67108868 Auto
C=US, ST=California, O=Juniper, OU=Base, CN=vSRX-2.juniper.net Not-Available
10.25.0.9 StO . 0 instance-GT-ADVPN-advpn-vpn-67108865 67108866 Auto
C=US, ST=California. O=Juniper, OU=Base, CN=vSRX-VR.juniper.net Not-Available
Question: What is the next-hop IP address used to reach the remote

vr201 network? What is the significance of this change from the last
time you checked the next-hop?
Answer: The next-hop IP address is now the stO interface IP on the vSRX-2
device. This indicates that tunnel traffic has triggered the establishment of a
shortcut tunnel between the vSRX-1 and vSRX-2 devices.
Question: What can you tell from the output of show security
ipsec next-hop-tunnels?
Answer: There is now a second tunnel established which connects directly to

the vSRX-2 device at 10.25.0.3.
Step 3.10
Close the session with the vSRX-1 device by issuing exit.
lab@vSRX-l> exit
login:
Step 3.11

lab@vSRX-2 exit
login:
Step 3.12
lab@vSRX-VR> exit
login:


vSRX-1
ATP Cloud
vSRX-2 I
55 ge-0/0/0 (on all student devices)
Physical
vSRX-VR iSr
I I 172,25,11.254 1
1
Internet
vQFX-1 '■M
] Console and
VNC Connections
Junos
Space
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
c
Lab Environment
3


Gateway 172.25.11.254

juniper
NETWORKS

ADVPNs
vSRX-VR
loO: 192.168.9.1
(.9)
StO.O
untrust zone untrust zon^
10.25.0.0/24 %
vpn zone
I
t
Ji'
OSPFAreaO.0.0.0 % /
e-z /
vSRX-1 ge-0/0/7 public zone ge-QIQI7 vSRX-2
loO: 192.168.1.1 (.1) (.129) loO: 192.168.2.1
10.0.1.0/24
ge-O/OH ge-0/0/5 ge-0/0/4
10.10.101.0/24 10.10.102.Tr/2*------ ___ W.W.201.0/24 10.10.202..0/24
(.10) (.10)' (.10) (.10)

vSRX-VR vr202
vr101 vr102 vr201
© 2020 Juniper Nehvorks, Inc. All Rights Reserved

juniper
NETWORKS


Lab
Implementing Advanced IPsec VPN Solutions
Overview
In this lab, you will implement some advanced IPsec VPN solutions. You will use the Junos CLI to
configure baseline elements such as interfaces, zones, and security policies, and a route-based IPsec
VPN. You will then configure a generic routing encapsulation (GRE) tunnel to operate over the IPsec VPN.
After establishing the GRE tunnel, you will configure an OSPF adjacency with the peer device. Then, you
will configure static NAT to route traffic between overlapping address spaces.
• Configure an IPsec VPN.
• Configure a GRE tunnel.
• Configure OSPF over GRE.
• Monitor the effects of your OSPF over GRE over IPsec configuration.
• Configure static NAT for overlapping address spaces.
www.juniper.net Implementing Advanced IPsec VPN Solutions • Lab 8-1


devices. Next, you will load the starting configurations for the lab.
Note

step 1.1
devices.

devices?

Step 1.2
username lab and password labl23. Enter configuration mode and load the labS-start. config
login: lab
Password:
Last login: Tue May 26 14:30:41 2020 from 172.25.11.254

[edit]
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Lab 8-2 • Implementing Advanced IPsec VPN Solutions www.juniper.net

Step 1.3
Open a separate session to the vSRX-2 device.
and load the starting configuration file using the load override ajsec/labS-start. config
command. After the configuration has been loaded, commit the changes before proceeding.
login: lab
Password:

[edit]
lab@vSRX-2# load override ajsec/labS-start.config
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.4
Open a separate session to the vSRX-VR device.
Step 1.5
Open a separate session to the vSRX-VR device using SSH or console. Log in with the username lab
and password labl23. Enter configuration mode and load the starting configuration file using the load
override ajsec/labS-start. config command. After the configuration has been loaded,
login: lab
Password:

[edit]
lab@vSRX-VR# load override ajsec/labS-start.config
[edit]
lab@vSRX-VR# commit
commit complete
[edit]
lab@vSRX-VR#

Step 1.6
On the vSRX-1 device, review the routing tables and determine which routes are used to reach the remote
device (vr201, vr202) networks.
[edit]

0.0.0.0/0 ■k
[Static/5] Id 08:49:38
> to 172.18.1.1 via ge-0/0/1.0
10.0.1.0/24 * [Direct/0] 00:03:41
> via ge-0/0/2.0
10.0.1.1/32 * [Local/0] 00:03:41
10.10.101.0/24 * [Direct/0] 00:03:41
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 00:03:41
10.10.102.0/24 * [Direct/0] 00:03:41
> via ge-0/0/5.0
10.10.102.1/32 * [Local/0] 00:03:41
172.18.1.0/30 * [Direct/0] Id 08:49:38
> via ge-0/0/1.0
172.18.1.2/32 * [Local/0] Id 08:49:38
172.20.100.0/24 * [Direct/0] 00:03:41
> via lt-0/0/0.0
172.20.100.1/32 * [Local/0] 00:03:41
172.25.11.0/24 * [Direct/0] Id 08:49:38
> via ge-0/0/0.0
172.25.11.1/32 * [Local/0] Id 08:49:38
192.168.1.1/32 * [Direct/0] Id 08:52:03
> via loO.O
192.168.3.1/32 * [Static/5] 00:03:42
> to 172.18.1.1 via ge-0/0/1.0
Question: Which route is currently used to reach the remote

networks?
Answer: Because there is no more specific route to the 10.10.201.0/

24 or 10.10.202.0/24 networks, the static default route (0.0.0.0/0) is
used to reach the remote networks.

Part 2: Configuring the Site-to-Site iPsec VPN

In this lab part, you configure the interfaces for the route based IPsec VPN. You will configure the Internet
key exchange (IKE) and IPsec parameters to establish the IPsec tunnel between the external ge-0/0/1
interfaces.You will then create a vpn zone and assign the appropriate interfaces. You will then create
policies to allow traffic to use the vpn zone.
Step 2.1
Configure the stO interface with the 10.10.10.1/24 IP address and network on the vSRX-1 device.
[edit]
[edit interfaces]
[edit interfaces]
lab@vSRX-l#
Step 2.2
Navigate to the [edit security ike] hierarchy and create a policy called policy-1. Configure
the policy with the following parameters:
Mode: main
Proposal Set: standard; and
[edit interfaces]
lab@vSRX-l# top edit security ike
[edit security ike]

lab@vSRX-l# set policy policy-1 mode main
[edit security ike]

lab@vSRX-l# set policy policy-1 proposal-set standard
[edit security ike]

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

lab@vSRX-l# show
policy policy-1 {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$XeGNVYJGifT3goT3690BxNd"; ## SECRET-DATA
}
[edit security ike]

lab@vSRX-l#

Step 2.3
Configure the gateway properties that will be used to establish the IPsec VPN to the remote site.
Configure the gateway with the following parameters:
Address: 172.18.2.2
External Interface: ge-0/0/1. O', and
IKE Policy: policy-1
[edit security ike]
lab@vSRX-l# edit gateway gateway-1
[edit security ike gateway gateway-1]


lab@vSRX-l# set external-interface ge-0/0/1.0

lab@vSRX-l# set ike-policy policy-1

lab@vSRX-l# show
ike-policy policy-1;
address 172.18.2.2;

lab@vSRX-l#
Step 2.4
Navigate to the [edit security ipsec] hierarchy and create a policy named policy-sec. Your
IPsec policy should use the pre-defined standard proposal-set.
lab@vSRX-l# up 2 edit ipsec policy policy-sec
[edit security ipsec policy policy-sec]

lab@vSRX-l# set proposal-set standard

lab@vSRX-l#
Step 2.5
Create a vpn called vSRX-l-to-vSRX-2. Configure the VPN with the following parameters:
• Bind Interface: sto . 0
IKE Gateway: ga teway-1
IKE IPsec Policy: policy-sec; and
Establish Tunnels: immediately.
lab@vSRX-l# up 1 edit vpn vSRX-l-to-vSRX-2
[edit security ipsec vpn vSRX-l-to-vSRX-2]

lab@vSRX-l# set bind-interface stO.O


lab@vSRX-l# set ike gateway gateway-1

lab@vSRX-l# set ike ipsec-policy policy-sec

lab@vSRX-l# set establish-tunnels immediately

lab@vSRX-l# show
ike {
gateway gateway-1;
ipsec-policy policy-sec;
}

lab@vSRX-l#
Step 2.6
Navigate to the [edit security zones] hierarchy and allow IKE as host-inbound-traffic for
the ge-0/0/1 interface within the untrust zone.
lab@vSRX-l# top edit security zones

lab@vSRX-l# set security-zone untrust interfaces ge-0/0/1 host-inbound-traffic
system-services ike

lab@vSRX-l#
Question: Why do we want to allow IKE on this interface?
Answer: This interface will be used for the IKE negotiation. For the
negotiation to succeed, we must enable the interface to accept this
traffic.
Step 2.7
Create a zone named vpn and add the stO. 0 interface. Verify the recent changes to both zones.
lab@vSRX-l# set security-zone vpn interfaces stO.O

lab@vSRX-l# show security-zone vpn
interfaces {
StO.O;
}

lab@vSRX-l# show security-zone untrust
system-services {
}
protocols {
}
}
interfaces {
ge-0/0/1.0 {
system-services {
ike;
}
}
}
}
Step 2.8
Navigate to the [edit security policies] hierarchy and create a policy. This policy should allow
all traffic to and from the Juniper-svand vpn zones. Name this policy Juniper-sv- to-vpn. Once
you have verified your configuration, commit these changes and exit to operational mode.
lab@vSRX-l# up 1 edit policies global policy Juniper-SV-to-vpn
[edit security policies global policy Juniper-SV-to-vpn]

lab@vSRX-l# set match from-zone [Juniper-SV vpn]

lab@vSRX-l# set match to-zone [Jun±per-SV vpn]





lab@vSRX-l# show
match {
source-address any;
application any;
from-zone [ Juniper-SV vpn ];
to-zone [ Juniper-sv vpn ];
}
then {
permit;
}

commit complete
lab@vSRX-l>
Note
For the purposes of this lab, we allow all traffic to pass through the IPsec
VPN, from the local Juniper-svzonetothe remote router instances, and
vice versa. In a production network, this setup might not be ideal. You can
limit the traffic allowed to pass through the IPsec tunnel by restricting the
source, destination, and applications.
Step 2.9
Verify that the IKE SA has been correctly negotiated using the show security ike
security-associations command.
7275115 UP fala32b4b54acaea 089126aab734bf49 Main 172.18.2.2
Question: Do you have an IKE SA?
Answer: Yes, at this point you should see an IKE SA.
Question: What is the state of the SA?
Answer: The state should be UP. If the State is displaying

something different, please review your IKE configuration and contact
your instructor if needed.
Step 2.10
Next, verify that you have a valid IPsec SA using the show security ipsec
security-associations command.
<131073 ESP:3des/shal 5e31354a 3519/ unlim root 500 172.18.2.2
>131073 ESP:3des/shal b3da0df8 3519/ unlim root 500 172.18.2.2

Question: Do you see IPsec SAs?
Answer: Yes, you should see one active tunnel. If you do not see an SA,
please review your IPsec configuration and contact your instructor for
assistance if needed.
Part 3: Configuring the GRE Tunnel over the IPsec VPN

In this lab part, you configure a GRE tunnel. This tunnel will establish over the existing IPsec VPN to the
remote site gateway device. This tunnel will be sourced from the stO interface on the vSRX-1 device and
will terminate on the stO interface of the vSRX-2 device. You will add the GRE interface to the
Juniper-svzone. You will then configure the vpn zone to recognize and allow the GRE traffic coming
in from the IPsec VPN. This GRE tunnel will allow the devices to establish an OSPF adjacency over the
IPsec link in the next part.
step 3.1
Enter configuration mode and navigate to the [edit interfaces gr-0/0/0 unit 0] hierarchy.
Configure the source and destination addresses that are going to be used to establish the GRE tunnel.
The tunnel source should be configured as the stO interface address on the vSRX-1 device, and the
tunnel destination address should be configured as the stO interface address for the vSRX-2 device.
After defining the source and destination of the tunnel, you need to specify the IP address of 10.11.11.1/
30 for the GRE interface on vSRX-1.
[edit]
lab@vSRX-l# edit interfaces gr-0/0/0.0
[edit interfaces gr-0/0/0 unit 0]

lab@vSRX-l# set tunnel source 10.10.10.1

lab@vSRX-l# set tunnel destination 10.10.10.2

lab@vSRX-l# set family inet address 10.11.11.1/30

lab@vSRX-l#
Step 3.2
Navigate to the [edit security zone Juniper-SV] hierarchy level, add the GRE interface to the
Juniper-SV zone. Review the configuration before moving on.
lab@vSRX-l# top edit security zones security-zone Junlper-SV

lab@vSRX-l# set interfaces gr-0/0/0.0

lab@vSRX-l# up


lab@vSRX-l# show security-zone Juniper-SV
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/4.0;
loO.O;
gr-0/0/0.0;
}

lab@vSRX-l#
Step 3.3
Enable the vpn zone to allow any-service traffic coming into this zone. After making your
configuration changes, commit and exit configuration mode.
lab@vSRX-l# set security-zone vpn host-inbound-traffic system-services any-service

commit complete
lab@vSRX-l>
Step 3.4
Clear the statistics for the IPsec VPN by issuing the clear security ipsec statistics
command. This command clears all statistics related to all traffic that has traversed the IPsec VPN. After
clearing the statistics, ping through the IPsec VPN, by pinging the vSRX-1 GRE interface address five
times. This task can be accomplished using the ping 10.11.11.2 rapid command. After pinging
the remote GRE interface, review the IPsec statistics to verify the traffic is traversing the tunnel.
Note
If both phase 1 and phase 2 tunnels are up and functional, and

the ping fails, reboot the vSRX-2 device and try again.
lab@vSRX-l> ping 10.11.11.2 rapid

PING 10.11.11.2 (10.11.11.2): 56 data bytes
I I I I I

ESP Statistics:
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
Note
You might see additional decrypted packets because the vSRX-2 device has
already configured OSPF over the gr-0/0/0 interface.
Question: Did your pings succeed?
Answer: Yes, your pings should complete at this time.
Question: Do you see encrypted and decrypted packets in the IPsec

statistics?
Answer: Yes, you should see encrypted and decrypted packets.
Part 4: Configuring OSPF over the GRE Tunnel
In this lab part, you configure OSPF to establish an adjacency over the GRE tunnel. You will also add the
Juniper-SV facing interface to the OSPF area of the vSRX-1 device. The Jun iper-sv zone must be
configured to allow the OSPF protocol. After establishing your adjacencies, you will review your route table
and ensure you have the correct OSPF routes.
Step 4.1
Enter configuration mode and navigate to the [edit protocols ospf area 0.0.0.0 ] hierarchy.
Add the GRE interface as well as the vrIOI-facing interface (ge-0/0/4). Review your configuration
changes before committing.
[edit]
lab@vSRX-l# edit protocols ospf area 0


lab@vSRX-l# set interface gr-0/0/0.0


lab@vSRX-l# show
interface gr-0/0/0.0;

commit complete
lab@vSRX-l>
Step 4.2
Begin verifying your configuration by looking at the OSPF neighborships.
Address Interface state ID Pri Dead
10.10.101.10 ge-0/0/4.0 Full 192.168.1.2 128 38
10.11.11.2 gr-0/0/0.0 Full 192.168.2.1 128 30
Question: How many neighborships do you see?
Answer: You should see two neighbors. You see one neighborship
with the vrl 01 instance and one with the vSRX-2 device over the
GRE interface.
Step 4.3
Review the OSPF routes installed in your routing table.
lab@vSRX-l> show route protocol ospf table inet.O

10.10.201.0/24 [OSPF/10] 00:03:28, metric 2

> via gr-0/0/0.0
10.10.202.0/24 [OSPF/10] 00:00:03, metric 2
> via gr-0/0/0.0
10.11.11.0/30 [OSPF/10] 00:03:33, metric 1
> via gr-0/0/0.0
224.0.0.5/32 [OSPF/10] 00:03:38, metric 1
MultiRecv

Question: Do you see the routes for the remote networks?
Answer: Yes, you should see the OSPF routes for the route for the
vr201 and vr202 networks.
Step 4.4
Clear the IPsec statistics database by issuing clear security ipsec statistics.
lab@vSRX-l>
Step 4.5
Verify reachability to the remote vr201 instance. You will use the ping utility to send five ICMP requests
to the VR device IP address. The vSRX-1 device will use the route learned through OSPF, which is
established over the GRE tunnel which is signaled over your IPsec VPN. You can accomplish this task by
issuing the ping 10.10.201.10 rapid command.
lab@vSRX-l> ping 10.10.201.10 rapid
PING 172.20.201.10 (172.20.201.10): 56 data bytes
I I I I I
Question: Did your pings complete?
Answer: Yes, your pings should complete. If the pings did not
complete, review your configuration and contact your instructor as
needed.
Step 4.6
Verify that the ping packets from the previous step traversed the IPsec tunnel by issuing show
security ipsec statistics.
ESP Statistics:
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:

Question: Does the output indicate that the ping packets traversed
the IPsec tunnel? Why would this happen?
Answer: Yes, the output should indicate the packets were subject to
IPsec encapsulation. This occurs because the GRE tunnel used to
route these packets is established over the existing IPsec tunnel.
Note
Please note that you do not need to configure a GRE tunnel to establish
OSPF over IPsec when both devices are Junos security devices. The GRE
tunnel is needed when one of the gateways does not support OSPF directly
over the IPsec VPN. Some vendors support this ability and some do not.
Please refer to the vendor documentation for specifics.
Part 5: Working with Overiapping Address Space

In this lab part, you configure static NAT on the vSRX-1 device to facilitate communication between the
local-vr-1 instance and the remote local-vr-2 device even though they use the same address
space. Once you have configured static NAT, you will direct this traffic over the IPsec tunnel that you have
previously configured.
Note
While configuring the NAT rule on vSRX-1, recall that a similar rule must be
in place on the vSRX-2 in order for sessions initiated from the
local-vr-2 instance to be translated and successfully routed to the
local-vr-1 instance.
Step 5.1
Enter configuration mode and navigate to the [edit security policies global policy
acqulred-to-untrust] hierarchy level and configure your device to allow all communication
between the acquired zone and the untrust zone.
[edit]
lab@vSRX-l# edit security policies global policy acquired-to-untrust
[edit security policies global policy acquired-to-untrust]

lab@vSRX-l# set match from-zone [untrust acquired}
[edit security policies global policy acquired-to-untrust1

lab@vSRX-l# set match to-zone [untrust acquired]






lab@vSRX-l#
Note
For the purposes of this lab, we want to allow all traffic, from the
local-vr-1 instance network to the remote local-vr-2 instance
network, to pass through the IPsec VPN and vice versa. In a production
network, this situation might not be ideal and you can limit the traffic
allowed to pass through the IPsec tunnel by restricting the source,
destination and applications allowed.
Step 5.2
Examine the routing table to determine which path the traffic will take if destined for the vSRX-2 external
NAT address space of 10.211.2.0/24.

0.0.0.0/0 ■k
[Static/5] 01:43:42
> to 172.18.1.2 via ge-0/0/1.0
10.0.1.0/24 * [Direct/0] 2d 21:27:34
> via ge-0/0/2.0
10.0.1.1/32 * [Local/0] 2d 21:27:34
10.10.10.0/24 * [Direct/0] 00:10:11
> via stO.O
10.10.10.1/32 * [Local/0] 00:10:11
Local via stO.O
10.10.101.0/24 * [Direct/0] 01:43:42
> via ge-0/0/4.0
10.10.101.1/32 * [Local/0] 01:43:42
10.10.102.0/24 * [Direct/0] 4d 02:54:53
> via ge-0/0/5.0
10.10.102.1/32 * [Local/0] 4d 02:54:53
10.10.201.0/24 * [OSPF/10] 00:07:45, metric 2
> via gr-0/0/0.0
10.10.202.0/24 * [OSPF/10] 00:07:45, metric 2
> via gr-0/0/0.0
10.11.11.0/30 * [Direct/0] 00:09:02
> via gr-0/0/0.0
[OSPF/10] 00:07:50, metric 1
> via gr-0/0/0.0
10.11.11.1/32 * [Local/0] 00:09:02

Local via gr-0/0/0.0

172.18.1.0/30 [Direct/0] 4d 02:54:53
> via ge-0/0/1.0
172.18.1.1/32 [Local/0] 4d 02:54:53
172.20.100.0/24 [Direct/0] 00:16:39
> via lt-0/0/0.0
172.20.100.1/32 [Local/0] 00:16:39
172.25.11.0/24 [Direct/0] 4d 23:06:25
> via fxpO.0
172.25.11.1/32 [Local/0] 4d 23:06:25
Local via fxpO.0
192.168.1.1/32 [Direct/0] 4d 02:54:53
> via loO.O
192.168.3.1/32 [Static/5] 00:16:39
> to 172.18.1.2 via ge-0/0/1.0
224.0.0.5/32 [OSPF/10] 00:08:00, metric 1
MultiRecv
Question: Which interface will be used for traffic destined to the

local-vr-2 external NAT address space of 10.211.2.0/24?
Answer: The route table shows that the traffic destined to the vSRX-2
external NAT address space will use the default route of O.O.O.O/O,
which points through the ge-0/0/1 interface.
step 5.3
Navigate to the [edit security nat static] hierarchy level. Configure a rule set that only
translates traffic that traverses the ge-0/0/1 interface.
[edit security policies global policy acquired-untrust]
lab@vSRX-l# top edit security nat static rule-set static-nat
[edit security nat static rule-set static-nat]

lab@vSRX-l# set from interface ge-0/0/1.0

lab@vSRX-l#
Step 5.4
Configure a static NAT rule called overlappingr-address that translates traffic that is destined to the
vSRX-1 external NAT address space of 10.211.1.0/24 into the 172.20.100.0/24 address space. When
you are finished, commit the configuration.
lab@vSRX-l# edit rule ovêrlapping-address
[edit security nat static rule-set static-nat rule overlapping-address]


lab@vSRX-l# set then static-nat prefix 172.20.100/24


lab@vSRX-l# up 2
[edit security nat static]

lab@vSRX-l# show
rule-set static-nat {
from interface ge-0/0/1.0;
rule overlapping-address {
match {
}
then {
static-nat {
prefix {
172.20.100.0/24;
}
}
}
}
}

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 5.5
Test connectivity by pinging the vSRX-2 local-vr-2 instance five times by issuing the run ping
10.211.2.10 routing-instance local-vr-1 rapid command.
lab@vSRX-l# run ping 10.211.2.10 routing-instance local-vr-1 rapid
PING 10.211.2.10 (10.211.2.10): 56 data bytes

Question: Was the ping test successful?
Answer: No, the test should not succeed at this time. In the following
steps you will diagnose the failure.
Step 5.6
Examine the static NAT statistics in an effort to determine why the ping test failed by issuing the run
show security nat static rule all command.
lab@vSRX-l# run show security nat static rule all
Total static-nat rules: 1

Total referenced IPv4/IPv6 ip-prefixes: 2/0

Static NAT rule: overlapping-address Rule-set: static-nat
Rule-Id 1
Rule position 1
From interface ge-0/0/1.0
Destination addresses 10.211.1.0
Host addresses 172.20.100.0
Netmask 24
Host routing-instance N/A
Translation hits 5
Failed sessions 0

lab@vSRX-l#
Question: Were the ping packets translated by the static NAT rule?
Answer: The Translation hits field is incrementing, which

means the ping packets are being translated by the static NAT rule.
Step 5.7
To further diagnose the problem, ping the vSRX-1 lt-0/0/0.1 interface address, which is the default
gateway for the local-vr-1 instance, by issuing the run ping 172.20.100.1
routing-instance local-vr-1 rapid command.
PING 172.20.100.1 (172.20.100.1): 56 data bytes
I I I I I
Step 5.8
Now ping the Internet router address from the local-vr-1 instance by issuing the run ping
172.18.1.2 routing-instance local-vr-1 rapid command.
PING 172.18.1.2 (172.18.1.2): 56 data bytes


Question: What do the ping tests reveal?
Answer: The ping tests show that the first hop, which is the vSRX-1
device, is responding to the ping packets, but the next hop, which is
the Internet router, does not respond.
Question: What does the lack of response from the Internet router
suggest?
Answer: The lack of response from the Internet router suggests that it
cannot route the traffic for the 10.211.2.0/24 or 10.211.1.0/24
networks. Most likely the problem resides with a lack of routing
information for the Internet router for the previously mentioned
networks. This scenario is common, in that Internet service providers
typically will not route private IP address space.
Question: What can you do to overcome this problem?
Answer: You can route the traffic through the IPsec tunnel that is
already in place. This method ensures that the traffic is received by
the remote team device and also adds encryption for the traffic.
However, the encryption is unnecessary in our current scenario, and
thus a GRE tunnel could be used instead.
Step 5.9
Configure a static route for the vSRX-2 external NAT address space (10.211.2.0/24) and use the stO
interface as the next hop for the route.
lab@vSRX-l# top edit routing-options
lab@vSRX-l# set static route 10.211.2. 0/24 next-hop stO
lab@vSRX-l# show
static {
route 192.168.1.2/32 next-hop 192.168.1.1;
route 10.10.101.0/24 next-hop 192.168.1.1;
route 192.168.3.1/32 next-hop 172 .18.1.1;
route 0.0.0.0/0 next-hop 172.18.1 .1;
}

Step 5.10
Navigate to the [edit security policies global] hierarchy level and renanne the
acquired-to-un trust policy to the acquired-to-vpn policy. Then, configure the policy to only
allow bidirectional communication between the acquired zone and the vpn zone. When you are
finished, commit the configuration
lab@vSRX-l# top edit security policies global
[edit security policies global]

lab@vSRX-l# rename policy acquired-to-untrust to policy acquired-to-vpn

lab@vSRX-l# delete policy acquired-to-vpn match from-zone untrust

lab@vSRX-l# delete policy acquired-to-vpn match to-zone untrust

lab@vSRX-l# set policy acquired-to-vpn match from-zone vpn

lab@vSRX-l# set policy acquired-to-vpn match to-zone vpn

lab(3vSRX-l# show policy acquired-to-vpn
match {
source-address any;
application any;
from-zone [ acquired vpn ];
to-zone [ acquired vpn ];
}
then {
permit;
}

lab@vSRX-l# commit
commit complete

lab(3vSRX-l#
Step 5.11
Clear the static NAT statistics by issuing the run clear security nat statistics static
rule all command. Then, test connectivity by pinging the local-vr-2 device five times by issuing
the run ping 10.211.2.10 routing-instance local-vr-1 rapid command.
lab@vSRX-l# run clear security nat statistics static rule all

PING 10.211.2.10 (10.211.2.10): 56 data bytes


Question: Was the ping test successful?
Answer: No, the test should not succeed at this time. In the following
steps you will diagnose the failure.
Step 5.12
Examine the static NAT statistics in an effort to determine why the ping test failed by issuing the run
show security nat static rule all command.
lab@vSRX-l# run show security nat static rule all
Total referenced IPv4/lPv6 ip-prefixes: 2/0
static NAT rule: overlapping-address Rule-set: static-nat
Rule-Id 1
Rule position 1
From interface ge-0/0/1.0
Netmask 24
Translation hits 0
Failed sessions 0
Question: What is preventing the translation hits from occurring?
Answer: Recall that in a previous step, you set the ge-0/0/1

interface as the from criteria of the static NAT rule set. This action
made sense in the previous step because the traffic was using the
default route that uses the ge-0/0/1 interface. However, you added
the static route that uses the st 0 interface as the next hop to direct
the traffic through the IPsec tunnel.
Question: What must you do to fix the problem?
Answer: To fix the problem, you can set the from criteria to the vpn
zone or the st 0 interface in the static NAT rule set.

Step 5.13
Deactivate the OSPF configuration by issuing the top deactivate protocols ospf command.
Then, change the static NAT rule set to use the stO interface for the from criteria. When you are
finished, commit the configuration and exit to operational mode.
Note
The OSPF configuration was deactivated to ensure that OSPF traffic is not
counted in the following IPsec statistics in the following steps.

lab@vSRX-l# top deactivate protocols ospf

lab@vSRX-l# top edit security nat static

lab@vSRX-l# delete rule-set static-nat from interface ge-0/0/1.0

lab@vSRX-l# set rule-set static-nat from interface stO.O

commit complete
lab@vSRX-l>
Step 5.14
Clear the current NAT and IPsec statistics by issuing the clear security nat statistics
static rule all and the clear security ipsec statistics commands. Then, test
connectivity by pinging the local-vr-2 instance five times by issuing the ping 10.211.2.10
routing-instance local-vr-2 rapid command.
lab@vSRX-l> clear security nat statistics static rule all
lab@vSRX-l> ping 10.211.2.10 routing-instance local-vr-1 rapid

PING 10.211.2.10 (10.211.2.10): 56 data bytes
I I I I I
Step 5.15
Examine the static NAT and IPsec statistics by issuing the show security nat static rule all
and the show security ipsec statistics commands.
lab@vSRX-l> show security nat static rule all
Total referenced IPv4/IPv6 ip-prefixes: 2/0
Static NAT rule: overlapping-address Rule-set: static-nat
Rule-Id 1
Rule position 1
From interface stO. 0


Netmask 24
Translation hits 5
Failed sessions 0

ESP Statistics:
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
Question: What do the static NAT and IPsec statistics show?
Answer: The static NAT and IPsec statistics show that traffic is
matching the static NAT rule and that the traffic is being processed
through the IPsec tunnel. Note that you might see additional
decrypted packets because the vSRX-2 device is still sending OSPF
packets.
Step 5.16
On the vSRX-1 device, terminate your session by issuing the exit command.
lab@vSRX-l> exit
login:
Step 5.17
lab@vSRX-2 exit
login:

Step 5.18
lab@vSRX-VR> exit
login:


vSRX-1 52S
tTTTTT
ATP Cloud
Physical
vSRX-VR SS
172.25.11.254 1
1
Internet
VNC Connections
Junos
Space
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
Gateway 172.25.11.254

jumper
Nf'ACKXS
Lab Network Diagram: Advanced IPsec

c ]
vSRX-1 External Internet vSRX-2 External

NAT Address Space NAT Address Space
10.211.1.0/24 Internet 10.211.2.0/24
Host
■JJ
172.31.15.1
local-vr-1 local-vr-2
(.10) (.10)
172.20.100.0/24 172.20.100.0/24
Acquired gr-0/0/0 (.1) 10.11.11.0/30 {.2) gr-0/0/0 7

Acquired
(.1) vSRX-1 vSRX-2
loO: 192.168.1.1
stO (.1) 10.10.10.0/30 (.2) loO: 192.168.2.1
ge-QIOI4 ge-0/0/5 ge-0IQI4
10.10.101.0/24 10.10.102.0/24 10.10.201.0/24 10.10.202..0/24
(.10) (•10)\ (.10)

(.10)
vr101 vr102
vSRX-VR vr201 vr202

jumper
Nf'ACKXS

Lab
Troubleshooting IPsec
Overview
In this lab, you will troubleshoot IPsec. You will use the Junos CLI to analyze log outputs and then
configure traceoptions to troubleshoot a failing SSH session. Then you will troubleshoot and resolve
several issues with an IPsec tunnel.
• View and examine logs.
• Configure traceoptions.
• Troubleshoot a failing SSH session.
• Troubleshoot IKE phase 1.
Troubleshoot IKE phase 2.
Troubleshoot a route-based IPsec VPN.
www.juniper.net Troubleshooting IPsec • Lab 9-1

Part 1: Examining Log Messages

devices. Next, you will load the starting configurations for the lab. You will then examine several logs to
troubleshoot issues related to IPsec VPNs.
Note

Step 1.1
devices.

devices?

Step 1.2
login: lab
Password:
Last login: Sat May 30 18:20:56 2020 from 172.25.11.254

[edit]
lab@vSRX-l# load override ajsec/lab9-start.conf±g
[edit]
lab@vSRX-l# commit
commit complete
[edit]
lab@vSRX-l#
Lab 9-2 • Troubleshooting IPsec www.juniper.net

Step 1.3
Open a new session with the vSRX-2 device.
and load the reset configuration file using the load override ajsec/lab9-start. config
login: lab
Password:

[edit]
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.4
Open a new session with the vSRX-VR device.
and load the reset configuration file using the load override ajsec/lab9-start. config
login: lab
Password:

[edit]
[edit]
commit complete
lab@vSRX-VR>

Part 2: Troubleshooting an IPsec VPN

In this lab part, you will examine the existing IPsec configuration on your 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 the vSRX-1 device.
[edit]
lab@vSRX-l# show security ike
proposal proposal-1 {
dh-group groupl4;
}
policy policy-1 {
mode main;
proposals proposal-1;
pre-shared-key ascii-text "$9$/UHwAulSrv7-wRh-wYgUD9Ap"; ## SECRET-DATA
}
gateway gateway-1 {
address 172.18.1.1;
dead-peer-detection;
}
gateway gateway-2 {
address 10.0.1.129;
}
[edit]
lab@vSRX-l#
Question: How many IKE phase 1 configurations are present?
Answer: As indicated by the output, there is 1 IKE phase 1 proposal, 1

IKE phase 1 policy and 2 IKE phase 1 gateways configurations
present.
Step 2.2
Examine the existing IPsec - IKE phase 2 configuration on the vSRX-1 device.
[edit]
lab@vSRX-l# show security ipsec
protocol esp;

}
policy policy-1 {
keys groupl4;
}
}
vpn vpnl {
ike {
gateway gateway-1;
ipsec-policy policy-1;
}
}
vpn vpn2 {
ike {
gateway gateway-2;
}
}
Question: How many IKE phase 2 configurations are listed?
Answer: As indicated by the output, there is one IKE phase 1

proposal, one IKE phase 2 policy, and two IKE phase 2 VPN
configurations shown.
Step 2.3
Exit configuration mode. 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.)
[edit]
lab@vSRX-l# exit
lab@vSRX-l> restart ipsec-key-management

IPSec Key Management daemon started, pid 7382
lab@vSRX-l>
Step 2.4
Check if any IKE phase 1 and IKE phase 2 SAs are present on the device.
2068374 UP 4beae56fbl4b4762 796540d0e8091019 Main 172.18.1.1

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

UP status. If no SA is displayed, notify your instructor. Note: you might
also see the down session to the other spoke.
Question: How many IKE phase 2 SAs are shown?
Answer: As indicated by the output, there are no active IKE phase 2

SAs.
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: The logical next step would be to verify the reachability

between spokes and your SRX loopback addresses.
Step 2.5
Verify the routing information to reach both spokes peering addresses is correct on the vSRX-1 device. For
the topology refer to the lab diagram.
lab@vSRX-l> show route 172.18.1.1 table inet.O

172.18.1.0/30 * [Direct/0] 2d 02:00:51

> via ge-0/0/1.0


10.0.1.0/24 [Direct/0] 00:32:14

> via ge-0/0/7.0
Question: Which interface and next-hop are used to reach the

loopback addresses of both spokes?
Answer: The ge-0/0/1.0 interface is being used to reach the

vSRX-VR device, and the ge-0/0/7.0 interface is being used to
reach the vSRX-2 device.
step 2.6
Verify the reachability to the vSRX-2 and vSRX-VR peering addresses using the ping utility. Define the IP
address of external -in ter face from the IKE phase Iconfiguration as the source address for the
ping.
lab@vSRX-l> ping 172.18.1.1 source 172.18.1.2 count 3

PING 172.18.1.1 (172.18.1.1): 56 data bytes

lab@vSRX-l> ping 10.0.1.129 source 10.0.1.1 count 3

PING 10.0.1.129 (10.0.1.129): 56 data bytes

Question: Were the pings successful?
Answer: Yes, as indicated by the output, both pings were successful. If

the pings are not successful notify your instructor.

Question: What does this mean?
Answer: The pings confirm the device can reach each other The next
step would be examining the IKE phase 1 and phase 2 for negotiation
details using traceoptions.
Step 2.7
Enter configuration mode and enable traceoptions for IKE phase 1 and IKE phase 2. For the traceoptions
configuration define flag all and a trace file called ike-trace, log. Commit the configuration changes
and exit to operational mode when complete.
[edit]
lab@vSRX-l# edit security
[edit security]
lab@vSRX-l# set ike traceoptions flag all
[edit security]
lab@vSRX-l# set ike traceoptions file ike-trace.log
[edit security]
lab@vSRX-l# set ipsec traceoptions flag all
[edit security]
commit complete
lab@vSRX-l>
Step 2.8
Review the ike-trace, logrfiie.
Note
For the sake of clarity and time, the interesting lines are bolded
in the output.
lab@vSRX-l> show log lke-trace.log

[Jun 1 13:05:11]Error:No such file or directory in deleting ike debug blob
[Jun 1 13 : 05 :11] kind iked cfgbuf addrec: 572: * * Allocated recptr is 1470, reclen =
1600417131 * *
[Jun 1 13 : 05 :11 ] kind iked cfgbuf addrec: 572: * * Allocated recptr is 44, reclen
1600417131 * *
[Jun 1 13:05:11]Error: Unknown record, type = 25
[Jun 1 13:05:11] kmd iked cfgbuf addrec: 572: * * Allocated recptr is 4, reclen
1600417131 * *

[Jun 1 13:05:11]kmd iked cfgbuf addrec: 572: * * Allocated recptr is 0, reclen

1600417131 **
[Jun 1 13:05:ll]No SPUs are operational, skip sending to SPUs.
[Jun 1 13:05:11]Config download: Processed 4-5 messages
[Jun 1 13:05:11]Config download time: 0 secs
[Jun 1 13:05:11]iked_config_process_config_list , configuration diff complete
[Jun 1 13:05:11]ikev2 fb i qm negotiation start:
FSM SET NEXT:ikev2 fb i qm negotiation negotiate
[Jun 1 13:05:11]ikev2 fb st i qm sa alloc spi:
FSM SET NEXT:ikev2 fb st i qm sa notify request
[Jun 1 13:05:11]ikev2 fb st i qm sa notify request:
FSM SET NEXT:ikev2 fb st i qm sa request
[Jun 1 13:05:11]ikev2_fb_st_i_qm_sa_request: FSM_SET_NEXT:ikev2_fb_st_i_qm_result
[Jun 1 13:05:11]ikev2 fb i qm negotiation negotiate:
FSM SET NEXT:ikev2 fb i qm negotiation result
[Jun 1 13:05:ll]ssh ike connect ipsec: Start, remote name :500, flags =
00010000
[Jun 1 13:05:ll]ssh ike connect ipsec: SA { 17ea41a7 e207fb41 8a54352c
77a28d4c}, nego 2
[Jun 1 13:05:11]ike_st_o_qm_hash_l: Start
[Jun 1 13:05:11]ike_st_o_qm_sa_proposals: Start
[Jun 1 13:05:11]ike_st_o_qm_nonce: Start
[Jun 1 13:05:11]ike_policy_reply_qm_nonce_data_len: Start
[Jun 1 13:05:11]ike_st_o_qm_optional_ke: Start
[Jun 1 13:05:11]ike_st_o_qm_optional_ids: Start
[Jun 1 13:05:11]ike_st_qm_optional_id: Start
[Jun 1 13:05:11]ike_st_qm_optional_id: Start
[Jun 1 13:05:11]ike st o private: Start
[Jun 1 13:05:11]Construction NHTB payload for local:172.18.1.2,
remote:172.18.1.1 IKEvl Pl SA index 6008679 sa-cfg vpnl
[Jun 1 13:05:11]iked get interface primary ip by family:Can Not find family for
tunnel interface stO.O
[Jun 1 13:05:11]iked nhtb get tunnel ip:Can Not get primary IPv6 address for
[Jun 1 13:05:11]iked nhtb get tunnel ip:Can Not get IPv6 link local address for
[Jun 1 13:05:11]ike_policy_reply_private_payload_out: Start
[Jun 1 13:05:11]ike_policy_reply_private_payload_out: Start
[Jun 1 13:05:11]ike st o encrypt: Marking encryption for packet
[Jun 1 13:05:ll]ike finalize qm hash 1: Hash[0..32] 11301fal flba0275 ..
[Jun 1 13:05:11]IKEvl packet S(<none>:500 - 172.18.1.1:500): len= 460,
mID=c3ee6d32, HDR, HASH, SA, Nonce, KE, ID, ID, PRV
[Jun 1 13:05:11]ike send packet: Start, send SA { 17ea41a7 e207fb41 8a54352c
77a28d4c}, nego = 2, dst = 172.18.1.1:500
[ Jun 1 13:05:30]-- Received from 172.18.1.1:500 to 172.18.1.2:0, VR 0,
length 204 on IF
[Jun 1 13:05:30]ikev2_packet_st_input_start:
FSM SET NEXT:ikev2 packet st input vl get sa
[Jun 1 13:05:30]ike_sa_find: Found SA = { 17ea41a7 e207fb41 - 8a54352c 77a28d4c }
[Jun 1 13:05:30]ikev2 packet st input vl get sa:
FSM SET NEXT:ikev2 packet vl start
[Jun 1 13:05:30]ikev2 packet vl start: Passing IKE vl.0 packet to IKEvl library
[Jun 1 13:05:30]ike get sa: Start, SA { 17ea41a7 e207fb41 - 8a54352c 77a28d4c }
/ a818efaf, remote 172.18.1.1:500
[Jun 1 13:05:30]ike sa find: Found SA = { 17ea41a7 e207fb41 - 8a54352c 77a28d4c }

[Jun 1 13:05:30]IKEvl packet R(<none>:500 <- 172.18.1.1:500): len= 204,

mID=a818efaf, HDR, HASH, SA, Nonce, ID, ID, unknown
[Jun 1 13:05:30]ike st i encrypt: Check that packet was encrypted succeeded
[Jun 1 13:05:30]ike st i qm hash 1: Start, hash[0..32] 35ca2845 6368760e ..
[Jun 1 13:05:30]ike_st_i_qm_nonce: Nonce[0..16] cae98869 9e8a9243 ..
[Jun 1 13:05:30]ike_st_i_qm_sa_proposals : Start
[Jun 1 13:05:30]ikev2 fb st select qm sa start:
FSM SET NEXT:ikev2 fb st select qm sa alloc spi
[Jun 1 13:05:30]ikev2 fb st select qm sa alloc spi:
FSM SET NEXT:ikev2 fb st select qm sa select
[Jun 1 13:05:30]ikev2 fb st select qm sa select:
FSM SET NEXT:ikev2 fb st select qm sa finish
[Jun 1 13:05:30]P2 SA payload match failed for sa-cfg vpnl. JUôrting negotiation
for tunnel local:172.18.1.2 remote:172.18.1.1 IKEvl.
[Jun 1 13: 05 : 30] ikev2_fb_spd_select_qm_sa_cb: IKEv2 SA select failed with error No
proposal chosen
[Jun 1 13:05:30]ikev2_fb_spd_select_qm_sa_cb: SA selection failed, no matching
proposal (neg 8f30300)
[Jun 1 13:05:30]ike_qm_sa_reply: Start
[Jun 1 13:05:30]ike state restart packet: Start, restart packet SA = { 17ea41a7
e207fb41 8a54352c 77a28d4c}, nego 2
[Jun 1 13:05:30]ike st i qm sa proposals: Start
[Jun 1 13:05:30]ike st i status n: Start, doi = 1, protocol = 0, code unknown
(40001) , spi[0..4] 8a9b3914 00000000 ..., data[0..8] 00010004 0a0a0a03 ..
[Jun 1 13:05:30]<none>:500 (Responder) 172.18.1.1:500 { 17ea41a7 e207fb41
8a54352c 77a28d4c [2] / 0xa818efaf } QM; Invalid protocol id = 0
[Jun 1 13:05:30]iked pm ike spd notify received: Negotiation is already failed.
Reason: No proposal chosen.
[Jun 1 13:05:30]QM notification '(null)’ (40001) (size 8 bytes) from 172.18.1.1
for protocol Reserved spi[0...3]=8a 9b 39 14
[Jun 1 13:05:30]ike_st_i_private: Start
[Jun 1 13:05:30]ike_st_o_qm_hash_2: Start
[Jun 1 13:05:30]ike st o qm sa values: Start
[Jun 1 13:05:30]<none>:500 (Responder) 172.18.1.1:500 { 17ea41a7 e207fb41
8a54352c 77a28d4c [2] / 0xa818efaf } QM; Error = No proposal chosen (14)
mID=0171676b, HDR, HASH, N(NO PROPOSAL CHOSEN)
[Jun 1 13:05:30]ike send packet: Start, send SA { 17ea41a7 e207fb41 8a54352c
77a28d4c}, nego 3, dst 172.18.1.1:500
[Jun 1 13:05:30]IPSec negotiation failed for SA-CFG vpnl for local:172.18.1.2,
remote:172.18.1.1 IKEvl. status: No proposal chosen
[Jun 1 13:05:30] P2 ed info: flags 0x0, P2 error: No proposal chosen
[Jun 1 13:05:37] Received from 10.0.1.129:500 to 10.0.1.1:0, VR 0,

length 324 on IF
[Jun 1 13:05:37]ikev2_packet_st_input_start:
FSM SET NEXT:ikev2 packet st input vl get sa
[Jun 1 13:05:37]ikev2 packet st input vl get sa:
FSM SET NEXT:ikev2 packet st input vl create sa
[Jun 1 13:05:37]ikev2 packet st input vl create sa: [8fe6f00/0] No IKE SA for
packet; requesting permission to create one.

[Jun 1 13:05:37]ikev2 packet st input vl create sa:

FSM SET NEXT:ikev2 packet st connect decision
[Jun 1 13:05:37]ikev2 packet vl start: Passing IKE vl.0 packet to IKEvl library
[Jun 1 13:05:37]ike get sa: Start, SA { 16dffed2 cdda660c - 00000000 00000000 }
/ 00000000, remote 10.0.1.129:500
[Jun 1 13:05:37]ike sa allocate: Start, SA { 16dffed2 cdda660c 80cd7d9a
2efef6d3 }
[Jun 1 13:05:37]ike_init_isakmp_sa: Start, remote = 10.0.1.129:500, initiator 0
[Jun 1 13:05:37]ikev2 fb pl negotiation allocate sa:
FSM SET NEXT:ikev2 fb pl negotiation wait sa done
[Jun 1 13:05:37]ikev2 fb st new pl connection start:
FSM SET NEXT:ikev2 fb st new pl connection local addresses
[Jun 1 13:05:37]ikev2 fb st new pl connection local addresses:
FSM SET NEXT:ikev2 fb st new pl connection result
[Jun 1 13:05:37]IKEvl packet R(<none>:500 10.0.1.129:500): len= 324,
mID=00000000, HDR, SA, Vid, Vid, Vid, Vid, Vid, Vid, Vid, Vid, Vid, Vid, Vid
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] afcad713 68alflc9 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 27bab5dc 01ea0760 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 6105c422 e76847e4 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 4485152d 18b6bbcd .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] cd604643 35df21f8 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 90cb8091 3ebb696e .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 7d9419a6 5310ca6f .
[Jun 1 13:05:37]ike_st_i_vid VID[0..16] 4al31c81 07035845 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..28] 69936922 8741c6d4 .
[Jun 1 13:05:37]ike_st_i_vid VID[0..8] 09002689 dfd6b712 ..
[Jun 1 13:05:37]ike st i vid VID[0..20] fd808804 df73bl51 .
[Jun 1 13:05:37]ike_st_i_sa_proposal : Start
[Jun 1 13:05:37]ikev2 fb st select ike sa:
FSM SET NEXT:ikev2 fb st select ike sa finish
[Jun 1 13:05:37]iked_pm_ike_spd_select_ike_sa failed, rc 1, error_code: No
proposal chosen
[Jun 1 13:05:37]ikev2_fb_spd_select_sa_cb: IKEv2 SA select failed with error No
proposal chosen (neg 8f30300)
[Jun 1 13:05:37]ike_isakmp_sa_reply : Start
[Jun 1 13:05:37]ike state restart packet: Start, restart packet SA = { 16dffed2
cdda660c 170f90c5 36e38fe6}, nego -1
[Jun 1 13:05:37]ike_st_i_sa_proposal : Start
[Jun 1 13:05:37]ike_st_i_cr: Start
[Jun 1 13:05:37]ike_st_i_cert: Start
[Jun 1 13:05:37]ike_st_i_private: Start
[Jun 1 13:05:37]ike_st_o_sa_values: Start
[Jun 1 13:05:37]10.0.1.1:500 (Responder) <-: 10.0.1.129:500 { 16dffed2 cdda660c -
170f90c5 36e38fe6 [-1] / 0x00000000 } IP; Error = No proposal chosen (14)
mID=7al0ea75, HDR, N (NO PROPOSJUj CHOSEN)
[Jun 1 13:05:37]ike_send_packet: Start, send SA = { 16dffed2 cdda660c - 170f90c5
36e38fe6}, nego = 0, dst 10.0.1.129:500
[Jun 1 13:05:37]IKE negotiation fail for local:10.0.1.1, remote:10.0.1.129 IKEvl
with status: No proposal chosen
[Jun 1 13:05:37] IKEvl Error : No proposal chosen
lab@vSRX-l>

Question: Do the log messages indicate the problem for the IKE
negotiations?
Answer: There are multiple issues revealed by the trace file. First
while IKE phase 1 is successful for the vSRX-VR device (172.18.1.1) J
the IKE phase 2 negotiation fails due to a no proposal chosen and a

rekey problem. Second, the negotiation with the vSRX-2 device fails
during IKE phase 1 with the message “No proposal chosen” which
typically indicates a proposal mismatch.
Question: How would you fix the situation?
Answer: You will need to review and compare the proposal and policy
configurations for the vSRX-1 device compared to both remote vSRX
devices. For the purposes of this demonstration, we will assume that
you do not have sufficient privileges to modify the configuration on the
vSRX-2 or vSRX-VR devices, so you will make the necessary changes
to the vSRX-1 device.
Step 2.9
View the current configurations under [edit security ike] and [edit security ipsec].
[edit]
traceoptions {
file ike-trace.log;
flag all;
}
dh-group groupl4;
}
policy policy-1 {
mode main;
}
gateway gateway-1 {
address 172.18.1.1;
}

gateway gateway-2 {
address 10.0.1.129;
}
[edit]
traceoptions {
flag all;
}
protocol esp;
}
policy policy-1 {
keys groupl4;
}
}
vpn vpnl {
ike {
gateway gateway-1;
}
}
vpn vpn2 {
ike {
gateway gateway-2;
}
}
Step 2.10
From the open session with vSRX-VR, view the current configurations under [edit security ike]
and [edit security ipsec].
lab@vSRX-VR> show configuration security ike
proposal propl {
dh-group groupl4;
}

policy poll {
mode main;
proposals propl;
pre-shared-key ascii-text "$9$FkkE6CuRhr8X-01X-VwaJ369"; ## SECRET-DATA
}
gateway gwl {
ike-policy poll;
address 172.18.1.2;
}
lab@vSRX-VR> show configuration security ipsec

proposal propl {
protocol esp;
}
policy poll {
proposals propl;
}
vpn vpnl {
ike {
gateway gwl;
ipsec-policy poll;
}
}
Question: Do you see the configuration issue that is causing the IKE
errors? How can you fix it?
Answer: Yes. The vSRX-1 device is configured to use the

perfect-forward-secrecy setting to rekey the phase 2 tunnel
but the vSRX-VR device is not. You can resolve the issue by removing
the setting from vSRX-1.
Step 2.11
On the vSRX-1 device, create a new policy {policy-1 is currently used for both VPNs) called policy-2
that does not use the perfect-forward-secrecy setting. Configure this as the policy forthe
vSRX-VR session. Commit the change.
[edit]
lab@vSRX-l# edit security ipsec policy policy-2
[edit security ipsec policy policy-2]

lab@vSRX-l# set proposals proposal-1
[edit security ipsec policy policy-2]

lab@vSRX-l# up 1 edit vpn vpnl

[edit security ipsec vpn vpnl]

lab@vSRX-l# set ike ipsec-policy policy-2

lab@vSRX-l# show
ike {
gateway gateway-1;
}

lab@vSRX-l# commit
commit complete

lab@vSRX-l#
Step 2.12
Check the effectiveness of your fix by checking the IKE and IPSec security associations on the vSRX-1
device.
lab@vSRX-l# run show security ike security-associations
2289674 UP a40c90d5e903c282 9e00 9e93ec3fcfef Main 172.18.1.1
2093153 DOWN 7578f675c790aadb b0bde801880cf584 Unknown 10.0.1.129

lab@vSRX-l# run show security ipsec security-associations
<131074 ESP:aes-cbc-256/sha256 128073ce 3579/ unlim - root 500 172.18.1.1
>131074 ESP:aes-cbc-256/sha256 497770f8 3579/ unlim - root 500 172.18.1.1
Question: Was your solution successful?
Answer: Yes, as indicated by the presence of two IPSec SAs in the

local database, the IKE negotiation with the vSRX-VR device was
successful. Note that the second failed session to the vSRX-2 device
may show as down or may not show up at all.
Step 2.13
Over the next couple of steps you will compare the configurations between the vSRX-1 and vSRX-2
devices to determine the cause of the IKE negotiation failure.
Examine the IKE and IPsec configurations on vSRX-1.


lab@vSRX-l# top
[edit]
traceoptions {
file ike-trace.log;
flag all;
}
dh-group groupl4;
}
policy policy-1 {
mode main;
}
gateway gateway-1 {
address 172.18.1.1;
}
gateway gateway-2 {
address 10.0.1.129;
}
[edit]
traceoptions {
flag all;
}
protocol esp;
}
policy policy-1 {
keys groupl4;
}
}
policy policy-2 {
}
vpn vpnl {
ike {

gateway gateway-1;
}
}
vpn vpn2 {
ike {
gateway gateway-2;
}
}
Step 2.14
Return to the open session on vSRX-2.
From the open session with vSRX-2, examine the IKE and IPsec configurations.
[edit]
lab@vSRX-2# show security ike
proposal propl {
dh-group groupS;
}
policy policy-1 {
mode main;
proposals propl;
pre-shared-key ascii-text "$9$lv8ESeLxdgoGvWoGDif5IEc"; ## SECRET-DATA
}
gateway gateway-1 {
address 10.0.1.1;
}
[edit]
lab@vSRX-2# show security ipsec
proposal propl {
protocol esp;
}
policy poll {
keys groupl4;
}
proposals propl;
}
vpn vpnl {
ike {
gateway gateway-1;

ipsec-policy poll;
}
}
Question: Do you see the issue that is causing the IKE negotiation
failure? How will you resolve it?
Answer: There is a mismatch in the IKE phase 1 proposals. The

vSRX-2 device is configured to use Diffie-Hellman group 5 while the
vSRX-1 device is configured to use group 14. You will create a new
phase 1 proposal and policy on vSRX-1 to match the settings on
vSRX-2.
Step 2.15
Return to the open session on vSRX-1.
On the vSRX-1 device, create a new IKE proposal called proposal-2 that uses the pre-shared key
authentication method, Diffie-Hellman group 5, the SHA-256 authentication algorithm, and the
AES-256-CBC encryption algorithm. Create a new policy called policy-2 that references the new
proposal. Use main mode for the policy and reference the ASCII text pre-shared key of juniper.
Configure policy-2 as the ike-policy for gateway-2. Commit the changes.
[edit]
lab@vSRX-l# edit security ike proposal proposal-2
[edit security ike proposal proposal-2]

lab@vSRX-l# set authentication-method pre-shared-keys

lab@vSRX-l# set dh-group groupS

lab@vSRX-l# set authentication-algorithm sha-256


lab@vSRX-l# up 1 edit policy policy-2
[edit security ike policy policy-2]

lab@vSRX-l# set mode main

lab@vSRX-l# set proposals proposal-2

lab@vSRX-l# set pre-shared-key ascii-text juniper

lab@vSRX-l# up

[edit security ike]

lab@vSRX-l# set gateway gateway-2 ike-policy pol2.cy-2
[edit security ike]

lab@vSRX-l# show
traceoptions {
file ike-trace.log;
flag all;
}
dh-group groupl4;
}
dh-group groupS;
}
policy policy-1 {
mode main;
}
policy policy-2 {
mode main;
pre-shared-key ascii-text "$9$H.fQ/CuEclFnclKMN-Hqm"; ## SECRET-DATA
}
gateway gateway-1 {
address 172.18.1.2;
}
gateway gateway-2 {
address 10.0.1.129;
}
[edit security ike]

commit complete
lab@vSRX-l>
Note
It might take a nninute for the second tunnel to be established.

Step 2.16
Verify the status of IKE phase 1 and IKE phase 2 SAs on your SRX.
2093113 UP b96ec71d81bd5340 0425681dclff3a74 Main 172.18.1.2
2093161 UP d80a30a67d995715 caad6a7c04 62 6c79 Main 10.0.1.129

<131074 ESP:aes-cbc-256/sha256 d4fd0d6c 3321/ unlim - root 500 172.18.1.2
>131074 ESP:aes-cbc-256/sha256 8fbel31b 3321/ unlim - root 500 172.18.1.2
<131075 ESP:aes-cbc-256/sha256 69ac94d6 3552/ unlim - root 500 10.0.1.129
>131075 ESP:aes-cbc-256/sha256 5b96e73f 3552/ unlim - root 500 10.0.1.129
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. Note that the previous, failed IKE phase 1 association
may still be shown with a status of down. 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, a pair for each remote vSRX device. If you experience different
output, double-check your configuration and notify your instructor.
Part 3: Troubleshooting Connectivity Problems for 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
Switch to the open session with the vSRX-VR device.
On the vSRX-VR device, test connectivity through the IPSec VPN tunnel between the vSRX-1 and vSRX-2
devices by sourcing ping from the virtual router instances connected to vSRX-1 {vrlOl and vrl02}
destined to the instances attached to vSRX-2 {vr201 and vr202}.
PING 10.10.201.10 (10.10.201.10): 56 data bytes
--- 10.10.201.10 ping statistics ---



PING 10.10.201.10 (10.10.201.10): 56 data bytes


PING 10.10.202.10 (10.10.202.10): 56 data bytes
I I I I I

PING 10.10.202.10 (10.10.202.10): 56 data bytes
I I I I I
Answer: As shown in the output, the pings to vr202 are successful,

however neither ping to vr201 is successful.
Step 3.2
On the vSRX-1 device, check the routes currently used to reach vr201 and vr202.

0.0.0.0/0 * [Static/5] 22:02:07

> to 172.18.1.2 via ge-0/0/1.0

10.10.202.0/24 * [Static/5] 00:04:08

> to 10.10.10.2 via stO.O

Question: Which interfaces and next-hop IP addresses are shown as

the forwarding result?
Answer: While the route to vr202 uses the stO. 0 interface as the
next hop, the route to vr201 currently uses the ge-0/0/1.0
interface connected to the vSRX-VR device.
Question: Is the forwarding correct considering the traffic from and to

both spokes must be secured?
Answer: No. Traffic to vr201 is not going into the tunnel interface
stO . 0. While it would be possible to successfully ping vr201 without
modifying the routing information - by configuring the appropriate
security policy and insuring the vSRX-VR device has the necessary
routes - you must insure that this traffic is secured, so the stO . 0
interface is the only option.
Step 3.3
Enter configuration mode.
Create a static route for vr201 traffic to use the IPsec VPN tunnel. Use the vSRX-2 device stO.O interface
as next-hop. Commit the change and exit to the operational mode when complete.
[edit]
lab@vSRX-l# edit routing-options static

lab@vSRX-l# set route 10.10.201.0/24 next-hop 10.10.10.2

lab@vSRX-l# show
route 192.168.1.2/32 next-hop 192.168.1.1;
route 192.168.3.1/32 next-hop 172.18.1.1;
route 0.0.0.0/0 next-hop 172.18.1.1;
route 10.10.202.0/24 next-hop 10.10.10.2;
route 172.31.15.1/32 next-hop 10.10.10.9;
route 10.10.201.0/24 next-hop 10.10.10.2;

commit complete
lab@vSRX-l>

Step 3.4
Test the forwarding to spoke 2 after the change.

10.10.201.0/24 [Static/5] 00:00:08

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

forwarded into stO. 0 interface.
Step 3.5
On the vSRX-VR device, verify connectivity from vrl 01 and vrl 02 to vr201.

PING 10.10.201.10 (10.10.201.10): 56 data bytes
I I I I I

PING 10.10.201.10 (10.10.201.10): 56 data bytes
I I I I I
Question: Are you able to reach vr201?
Answer: Yes, the pings should now be successful. If they are not,
verify your configuration and consult your instructor.
Step 3.6
On the vSRX-1 device, terminate the OLI session by issuing the exit command.
lab@vSRX-l> exit
login:

Step 3.7
lab@vSRX-2 exit
login:
Step 3.8
lab@vSRX-VR> exit
login:
STOP


r7T-T-:
vSRX-1 du
ATP Cloud
Physical
vSRX-VR SiS 172.25.11.254 1
1
Internet
vQFX’1 JI Console and
VNC Connections
Junos
Space
1
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
student Policy Enforcer 172.25.11.101
Gateway 172.25.11.254
© 2020 Juniper Networks, Inc. Ail Rights Reserved

J un i per Business Use On ly
jumper
NETWORKS
Lab Network Diagram: Troubleshooting IPsec
vSRX-VR
loO; 192.168.9.1
<5^
.'v
-O';/
public zone &
ge-0/0/7 (.1) 10.0.1.0/24 (.129) ge-0/0/7
vSRX-1 vSRX-2
stO (.1) (.2) stO
loO: 192.168.1.1 . loO; 192.168.2.1
10.10.10.0/24
ge-0/0/4 ge-0/0/5
10.10.101.0/24 10.10.102.0/24 10.10.201.0/24 10.10.202..0/24
(.10) (.10) (.10)
vrlOl vrl02
vSRX-VR vr201 vr202
Juniper-SVzone ACM E-SV zone Juniper-WFzone ACME-WFzone

jumper
NF'WCRXS


Lab
SecIntel
Overview
In this lab, you will implement several features related to Juniper SecIntel. You will use the ATP Cloud and
Security Director GUI interfaces to provision SecIntel feeds and use the Junos CLI to verify their
operation.
• Configure and monitor a security policy using the Office 365 feed.
• Configure and monitor a security policy using a custom feed.
www.juniper.net SecIntel • Lab 10-1

Part 1: Setting up the Environment

In this lab part, you will use the Junos command line interface (CLI) and Security Directory GUI to
configured and discover the SRX devices and import existing policy configurations.
Note
step 1.1
You will primarily configure the vSRX-1 and vSRX-2 devices. Consult the Management Network Diagram to
determine the management addresses of your devices.

devices?

Step 1.2
Access the CLI on the vSRX-1 device as directed by your instructor. Log in with the username lab and
password labl23. Enter configuration mode and load the labl 0-start. config from the ajsec
directory. Commit the configuration when complete and exit to operational mode.
login: lab
Password:

[edit]
lab@vSRX-l# load override ajsec/lablO-start.config
[edit]
commit complete
lab@vSRX-l>
Lab 10-2 • SecIntel www.juniper.net

Step 1.3
and load the reset configuration file using the load override a jsec/lablO-start. config
login: lab
Password:

[edit]
lab@vSRX-2# load override ajsec/lablO-start.config
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.4
and load the reset configuration file using the load override ajsec/lablO-start.config
login: lab
Password:

[edit]
lab@vSRX-VR# load override ajsec/lablO-start.config
[edit]
lab@vSRX-VR# commit
commit complete
[edit]
lab@vSRX-VR#

Step 1.5
Open a virtual console session to the desktop, open a Web browser and navigate to the web management
IP address for Junos Space Security Director, https://172.25.ll.100/dashboard
From the web browser, login with the username of super and the password of Junip3ri23!.
Note
Clear the cache and cookies in the browser if it

becomes unresponsive.
Junos Space Security Director

Version I9.4R1
super
Log In
III
Step 1.6
Mouse over the blue navigation bar on the left to expand it. Click on Devices->Device Discovery.
In the Device Discovery dialog, select the ajsec-devices discovery job. Click Run Now.
Global
Devices / Device Discovery q
X Security Devices
Device Discovery®
Device Discovery
Secure Fabric 1 selected

[ Gone
]( Ron Now J[ More 3 + z © Q Y :
3 NSX Managers
vCenter Servers
u □ Device Discovery Profile Target Type Target Details Probes Username Credential T._ Schedule Recurrence
o AISEC-OBCOVERY IP Range 172.25.11.1-17225.11.9 N/A lab Credential Ba... Fn. 01 Jun 203519:42:37 PDT
11tems
■BB

Job Details:Discover Network Elements

fob 10 229S95 Scheduled Start Ti... Thu, 04 Jun 2020 20t 16-00 POT
Job Name Oijcover Network Elements-22959S Actual Start Time Thu. 04 Jun 2020 20:1POT
Job State End Time Thu, 04 Jun 2020 20:16:22 POT

0 Success
Owner Super
5 :
IP Address Hostname Job Status Description
172.25.11.1 vSRX-1 0ev<e Managed Oev»ce discovered successfully
172.25.112 vSRX-2 Oevtce Managed Device discovered successfully
2 Rows
OK
Question: What are the results of the discovery job?
Answer: The vSRX-1 and vSRX-2 devices should be discovered

successfully. If any device was not discovered successfully, please
inform your instructor.
Step 1.7
Mouse over the blue navigation bar on the left to expand it.
Navigate to Devices->Security Devices. Check the boxes next to vSRX-1 and vSRX-2. Right click
on any device name and select import from the drop-down list.
Global
Devices / Security Devices Q V C 1^ S 9
Security Devices Security Devices ©

Device Discovery
[S’
Secure Fabric
2 selected Update Changes ReSynchronize with Network More * Q V :
NSX Managers
vCenter Servers
[Bl D Device Name IP Address OS Version Schema Version CPU Storage Authentication Status Connection Status Feed Source
Q . vSRX-1 172.25.11.1 20.1 RI .11 Credentials Based • Unverifi... A up
Configuration
Q > vSRX-2 172.25.11.2 20.1 RI .11 Credentials Based • Unverifi... ▲ up
Operations
items 1 of 1 Display 50 V
View Inventory Details
Update Changes
Upload Keys
Import
Refresh Certificate
Assign Device to Domain
Acknowledge Device Fingerprint
Step 1.8
Check the boxes next to all Firewall and NAT policies and click Next.
In the Conflict Resolution dialog, click Finish.
In the Summary page, click ok.

Devices ! Security Devices Q Global V O S ?
X Security Devices Import Configuration @

Device Discovery
o Secure Fabric Managed Services
NSX Managers
rite with Network
1 More oz Q V :
vCenter Servers O For devices with Junos OS Release 18.2 and later, ips policy is auto imported along with the assigned Firewall Policy.
Connection Status Feed Source
For devices with Junos OS Release 18.2 and later, Deprecated AppFw configuration will not be imported.
lUnverifi... ▲ up
zseieaed
I Unverifi... ▲ up
»
a Name Rules Errors Summary
1 Display 50 V
Firewall Policy
Q vSRX-2 4 0
NAT Policy
o vSRX-1 1 0
2 items
Cancel Next
Devices / Security Devices Q Global

O s ?
X Security Devices Import Configuration @

Device Discovery
o---
'.'stages S«r-.i:es Conflict Resolution
Secure Fabric
pi'te •••.ntt' Network More Q Y :
3 NSX Managers
vCenier Servers
■us Connection Status Feed Source
Q Y ► Unverifi... ▲ up
»Unverifi... ▲ up
B □ Object Name Object Type value Imported value Conflia Resolution New Object Name Domain
No Conflicts to Show 1 50 V
Display
CarKel Back Finish
Question: What is the result of the Import job?
Answer: The job should complete successfully. If it did not, consult

your instructor.
Step 1.9
Navigate to Administration->Policy Enforcer->Settings.
Consult the management diagram and configure the Policy Enforcer connection with the following
settings:

IP Address: 172.25.11.101
Username: root
Password: Junlp3rl23!
Sky ATP Configuration Type: Sky ATP/JATP with Juniper Connected Security
Leave all other settings at default. Click ok.
Note
The Policy Enforcer might already be

configured. If so, you can skip this step.
Administration / Policy Errforcer / Settings
My Profile
Settings®
Users & Roles > IP Address* 172.25.11.101
Logging Management > Username © root

Monitor Settings
Password*
Signature Database
Sky ATP Configuration Ty,., 0 Sky ATP/JATP with Juniper Connected Security v
License Management >
Policy Enforcer
Settings Configure polling timers to discover hosts in your network
Connectors Poll Network wide endpo... * 0 24 hours
NSM Migration
Poll Site wide endpoints* 0 5 mlns
Policy Sync Settings
OK Reset
Policy Enforcer Logs Download
Question: What is the result of the Policy Enforcer configuration?
Answer: The Settings page should display “The Policy Enforcer is

active.”
Part 2: Creating a Policy using the Office 365 Feed
In this lab part, you will enroll your devices with ATP cloud through the Policy Enforcer device. You will then
enable the Office 365 feed and configure a security policy to allow outbound access to all Office 365 IP
addresses. You will then use the Junos OLI to verify the functionality of this policy.
Step 2.1
Open a new web browser tab and navigate to https: //sky. junipersecurity. net. Login to the
ATP realm using the credentials provided by your instructor.

Sky ATP
Version 3.0 | Login
student@juniper.net
ajsec-realm-1
□ Remember me
Log In
Create a security realm Supported JUNOS Software
Forgot password and Documentation
Step 2.2
Navigate to Conf igure->Third Party Feeds. Check the box for Enable feed next to
of f ice365.
ConFûre / Third Party Feeds
File Inspection Profiles

Third Party Feeds®
Email Management >
Q IP Filter Feed
Whitelists
Blacklists
office365 D Enable feed
Third Party Feeds Go to feed site
Global Configuration > Command and Control Feeds

Selea to enable open source feeds managed by third parties.
H ! The accuracy of these feeds cannot be guaranteed, and false positives generated by these feeds will not be
X
investigated by Juniper Networks. Security policies will block malicious IP addresses and domains based on
enabled third parry feeds, but these events do not affect host threat scores.
IP Feed
Malware Domain List O Enable feed
Go to feed site C?
Block List □ Enable feed
Go to feed site
DShield O Enable feed
Go to feed site
Step 2.3
Open a web browser and navigate to the management IP for Junos Space Security Director.
From the web browser, log in with the username super and password Junlp3rl2 3 !

juniper NFTWOPr.;,
NFTWORr;.
a
(.
r
I

Version I9.4R1
I super
Log In
II
ffte.
Copydi luniper Networks, inc. AM ‘mark Nooce | Privacy Polky
k
I
Step 2.4
Navigate to Conf igure->Threat Prevention->Feed Sources. Make sure the Sky ATP tab is
selected, then click the + icon to add a new feed source.
Corifigure / Threat Prevention t Feed Sources Q Global V o s 9
X Firewall Policy Feed Sources©

Standard Policies
Unified Policies
□ Devices
Schedules
Sky ATP JATP Custom Feeds
Profiles
More *
Templates
Environment
■gW User Firewall Management > □ Realm Sites Devices Location Enrollment Status Token Expiry Feed Status Last Downloaded
Application Firewall Policy >

SSL Profiles > 0 items O
IPS Policy >

NAT Policy >
UTM Policy >
Application Policy Based Routi...
Threat Prevention
Policies
Feed Sources
Step 2.5
In the Sky ATP Realm Credential dialog, enter the Username, Password and Realm provided by your
instructor. Click Next.

Add Sky ATP Realm ©
SkyATP Realm Credential
SkyATP realm credentials

ret'
Location* North America v
Username ajsec_sky_atp@juniper.net
Password •••••••••••
Realm ® ajsec-student-01
No Sky ATP account? Select your region using the Location in the menu above, then click here to create an account.
You will be redirected to the SkyATP account page.
Cancel Next
step 2.6
In the Site dialog, click Create new site. In the Create Site dialog, enter a Site name of
a j sec-lab. Click OK.
Canfigur« i Threat Prevention / Feed Sources q Global 0 S
Firewall Policy Feed Sour Add Sky ATP Realm ©

Standard Policies
Unified Policies
o Seal— Crcce—.4 Site
Devices
Sky ATP JATP
Schedules
C31 Profiles
Templates Create Site © Mere v
Environment
User Firewall Management > □ Site* ajSS£-'3b|

Feed Status Last Downloaded
Application Firewall Policy > □

SSL Profiles > Description wnte description..
1 items
IPS Policy >
NAT Policy >
UTM Policy >
Threat Prevention
Policies
Feed Sources
IPSeeVPN >
Shared Objects >
Cancel OK
Change Management
Step 2.7
Insure the a jsec-lab site is selected. Click Next. In the Global Configuration dialog, check
the boxes to enable logging for Malware and Host Status. Click Finish.

Q Global V a s
I Configure / Threat Prevention / feed Sources
X Firewall Policy Feed Soul Add Sky ATP Realm ©

Standard Policies
Unified Policies
o-----
Sk)-aTP êsirn Crese—.i
o
Srte Global Configuration
Devices
E Sky ATP JATP
Schedules 7
Threat level Threshold
Profiles
6 8
More
Templates
Environment
User Firewall Management > □ Realm

Administrators Who Receive Email Notifications + I Expiry Feed Status Last Downloaded
Application Firewall Policy > □ ajsec-reata 2021
SSL Profiles >

IPS Policy >
11tems O
□ E-mail Threat level Threshold
No data available
NAT Policy >
UTM Policy >
Application Policy Based Routi... Logging
Threat Prevention
Policies
Matware □ Enable logging
Feed Sources
Host Status Q Enable Logging
IPSecVPN >
Shared Objects >
Change Management > Proxy Servers © +
Guided Setup >
□ Server IP
No data available
Cancel Finish
Note
Sometimes clicking the Finish button does not

remove the popup window. If this happens click
the Cancel button. Verify that the realm was
created.
Step 2.8
Navigate to Devices->Secure Fabric and click on Add Enforcement Points for the
a j sec-lab site. Select vSRX-1 and vSRX-2 and click the Arrow to select both devices. Click ok.
♦ Devices / Secure Fabric Q Global a s ?
X Security Devices Secure Fabric©

Device Discovery
(2)
Secure Fabric
Sites
3 NSX Managers
vCenter Servers
[SI
□ Site Enforcement Points IP Model Feed Source Feed Source... Last Updated Descrip...
□ ajsec-lab skyatp June 04,2020
1 items O

Add Enforcement Points ®
O Assigning a device to the site will cause a change in the device configuration.
Specify the enforcement points to assign to the site. The site cannot contain both switches and connectors.
Enforcement Points 0 Available q : 2 Selected q :

□ Name IP Model □ Name IP Model
□ vSRX-1 172.25.11.1 VSRX
□ vSRX-2 172.25.11,2 VSRX
No available items
Perimeter Device O »vSRX-1 »vSRX-2
Cancel OK
Step 2.9
Navigate to Devices->Security Devices. Verify that the Feed Source column has a value of
SKYATP and the Feed Source Status column shows the name of your assigned ATP realm.
♦ Devices / Security Devices q Global

a (5 s 9
X Security Devices
Security Devices ©
Device Discovery
Secure Fabric More * q 7 :

□ NSX Managers
[Bl
vCenier Servers
□ Device Name ▼ IP Address OS Version CPU Storage Connection Status Feed Source Feed Source Status Managed Status
□ . vSRX-2 172.25.11.2 20.1 RI.11 A up SKYATP ajsec-realm-1 \ Managed
□ . vSRX-1 172.25.11.1 20.1Rl.il ▲ up SKYATP ajsec-realm-1 Managed
B
Note
It may take up to 3 minutes to for this update

occur. Refresh the table to view the latest
updates.
Step 2.10
Navigate to Conf igure->Firewall Policy->Standard Policy and click + to create a new
policy.
Assign the policy a name of vSRX-1. For Type select Device Policy. Under Device Selection,
selection vSRX-1. Click ok.

Global
Configure ! Firewall Pokey / Standard Policies Q V 0 s 9
X Firewall Policy Standard Policies®

Standard Policies
Create
Unified Policies
Devices [ Global Options Locking v More •*’ Q V’

Pl
Schedules
Profiles
□ Seq. Name Rules Devices Publish State Last Modified Created By Modified By Domain
Templates
POLICIES APPLIED BEFORE DEVICE SPECIFIC POLICIES' (1 policy)
Environment
> □ 1 All Devices Policy Pre Add Rule 1 Not Published wed Jun 03.20206:19 PM System Global
H User Firewall Management
Application Firewall Policy > V' DEVICE SPECIFIC POLICIES (1 policy)
SSL Profiles > □ vSRX-2 4 vSRX-2 Not Published Thu Jun 04,2020 8:21 PM super Super Global
IPS Policy > V POLICIES APPLIED AFTER DEVICE SPECIFIC POLICIES' (1 policy)
NAT Policy >
UTM Policy > □ 2 All Devices Policy Post Add Rule 1 Not Published Wed Jun 03.20206:19 PM System Global
Application Policy Based Routi... 3 items
Threat Prevention >
Configure / Firewall
fewaiôj^ ! Standard Policies Q Global V C s ?
□
The selected items were successfully deleted.

Firewall Policy Stand
Standard Policies
Unified Policies
Devices Create Firewall Policy® I LOCkwlg >> More q Y-

Schedules
Profiles □ General Information KedBy Modified By Domain
Templates
V POLIC Name* vSRX-1
Environment
User Firewall Management > □ Description <2) »m Global
Application Firewall Policy > DEVIC
SSL Profiles > □ r Super Global
IPS Policy > S/ POLiC

Policy Options
NAT Policy >
UTM Policy > o Profile ®
Select an option Clear All *n Global
Application Policy Based Routi... 3 items
Threat Prevention > Type* ® O Group Policy

® Device Policy
IPSec VPN >
Shared Objects >
Device Selection
Change Management >
Guided Setup > Device O
vSRX-1
Clear All
Cancel OK
Step 2.11
In the standard Policies screen, click Add Rule on the line defining the vSRX-1 policy.
In the General dialog, assign a Rule Name of allow-of fice-365.
www.juniper.net SecIntel Lab 10-13

Create Rule @
General
o
So-rce
General Information
Rule Name* ® allow-office-365
Description ©
Allows outbound Office 365 traffic
Cancel Next
Step 2.12
In the Source dialog, select a Zone of Juniper-sv. Click Next.
Create Rule ©
o—
Gft'va Source
Identify the traffic that the rule applies to
Source
Zone © »Juniper-SV
Clear All
Addressees) © Select
Any
User IO © Select
End User Profile ©
Clear All
Cancel Sack Next
Step 2.13
In the Destination dialog, select a Zone of untrust.
Click Select for Addresses. Click the Include Specific option for Address Selection.
Under Addresses, check the box for ipf ilter_of f ice365 and click the arrow button to choose
this address. Click ok. Click Next.

Create Rule©
o o riACtanjHnn
Destination Address®
Select the destinatic- ' pu'i OU'" Si book en:*. f c ’' bheA • aoie iistbs'r/-'or yc-t--':?i j crerc ;
seieciiri the 'Asc
Address Selection ® O IrKlude Any Address
® Include Specific
O Excl ude Specific
O By Metadata Filter
Addresses O 12 Available Q : 1 Selected Q

□ Name Domain
□ Name Domain
□ Any-IPv4 SYSTEM □ ipfilter_office365 Global
□ Any-iPv6 SYSTEM
□ internet-host {172.31... Global
□ lab-peg_l0.10.l0l.1/... Global
□ lab-peg.10.10.101.10... Global
Add New Destination Address
Cancel OK
Cartel Back Next
Step 2.14
In the Advanced Security dialog, select an Action of Permit. Click Next.
Create Rule®
o—
Gei'era
o—
Soizce
o—
Cestiraxcr Advanced Security
o Rj e Options
Advanced Security
Rule Action
Aaion @ Permit
Advanced Security
App Firewall ® Select an option Clear All Add New
Supported in Junos OS version 18.1 and lower. Fc.'J_. .:s

18.2 versivTi and later, use dynamtc application of Unified
Fire. Ip jesto Support .VP
SSL Proxy (2) Select an option Clear All Add Forward Proxy Add Reverse Proxy
IPS ® Off
Supported in Junos OS verS">* 18.' oer
IPS Policy @ Select an option Clear All
Supported in Junos OS version 18.2 and later
UTM (2> Select an option Clear All Add New
Threat Prevention Policy (2) Select an option Clear All
Cancel Back Next
Step 2.15
In the Rule Options dialog, leave all options at default and click Next.

Create Rule©
o— o— c-- o
Crnrrat Sourer Drst*tat«n Mvanerd Sreurry Rule Options
Rule Options
Profile ® Select
Inherited from policy
Schedule Select an option Add New
Clear All
Cancel Sack Next
step 2.16
In the Rule Analysis dialog, click Next.
Create Rule @
o—
Geriera
o—
Sovxe CeSt'f^K'Ort
o
Ao.iriwc Secu*^'
oft., e—
Optiorts Rule Analysts
Automated Rule Analysis and Placement
Rule Analysis ® O Analyze the new rule to suggest a placeme...
Cancel Back Next
Step 2.17
In the Rule Placement dialog, click Finish. Click OK at the Summary screen.

Create Rule®
a o o o o o
Hui* Ptoc«in*ftt
Analysis
Results No rutoar:*,=5^5 was performed When ruto analy* rrx performed, the ST^tem w££?st a placement xcordrg
to the information provided m steps 1 to 5
Rule Placing
Rule Type ZONE
LoceUon ! Sequence Rule Sequence A I be No. 1
View PUcement inside Pokey
Cancel Back FtfiiSh
Create Rule©
Summary
Re.'iez, :ne ■.■ai r - iâtkjn
General information
Edit
Name allow>ofrice-365
Description Allows outbound Office 365 traffic
Identify Traffic Source

Edit
Zone juniper-SV
Address Any
Identify Traffic Destination

Edit
Zone untrust
Address ipfilter_office36S
Service Any
Advanced Security
Edit
IPS Off
Action PERMIT
Rule Options
Edit
Profile inherited from policy
Rule Analysis
Edit
Rule Placement
Edit
Cancel Back OK
Step 2.18
Review the new rule. Click ok, then Update. In the Update Firewall Policy screen, click
Pxiblish and Update. Click Yes to confirm

Global
configure / Rrewall Policy t standard Policies Q V Q s
X Firewall Policy
vSRX-1 / Rules . '“sdJ seconds ago
Standard Policies
© Unified Policies Pubi-;; Update ‘.'□re
71
Q V’ :
C4jjec» V. 2)
Devices
Schedules Update Firewall Policy©

Iser Profile best. Zone
Profiles
Templates
Environment Type* ® (S) Run now z untrust
User Firewall Management > O Schedule at a later time

SSL Profiles > ’.fat the pc
IPS Policy >

Q :
NAT Policy > 1 selected
UTM Policy >

Application Policy Based Routi... o Device Name Publish Req.- Configura... Ma... Connection S... Services Domain Device IP Platform OS version
Threat Prevention > vSRX-1 Required View O In... up vSRX-1 Global 172.25.11.1 VSRX 20.1 RI.11
IPSec VPN >

1 items
Shared Objects >
Change Management >
Guided Setup >
Cancel Publish and Update
Step 2.19
Review the Job Status result. Click OK.
Job Status ©
♦
Snapshot Policy Publish Policy Update Devices
229601 229602 229603
@ ®
Job Type: Update Devices job State: Success 0

job ID: 229603 Percent Complete: 100%
Job Name: Update Device5-229603 Scheduled Start Time: Thu, 04 Jun 2020 21:42:06 PDT
User: super Actual Start Time: Thu, 04 Jun 2020 21:42:06 PDT
End Time: Thu, 04 Jun 2020 21:42:11 PDT
Export to CSV q Y
Name Status Services Message Configuration Commit time
vSRX-1 (vSRX-1) Success vSRX-1 (FWPolicy] Vievr View Thu. 04 Jun 2020 21:42:10 PST
1 Rows
OK
Step 2.20
Access the command line interface (CLI) on the vSRX-1 device.
From the CLI session with vSRX-1, verify that the Office 365 feed category has been created by issuing
the show services security-intelligence category summary command.
lab@vSRX-l> show services security-intelligence category summary
Category name :IPFilter

Status :Enable
Description :IPFilter data
Update interval :3600s
TTL :3456000s
Feed name zipfilter office365

Version :20200415.1
Objects number:72
Create time :2020-05-25 02:17:47 UTC
Update time :2020-06-05 05:42:24 UTC
Update status :Store succeeded
Expired :No
Status :Active
Options :N/A
lab@vSRX-l>
Step 2.21
From the CLI session with the vSRX-1 device, view the entries in the Office 365 feed by issuing the show
security dynamic-address address-name ipfilter_office365 command. Choose an address from this list
and write it down for a future step.
lab@vSRX-l> show security dynamic-address address-name ipfilter_office365 |
no-more
No . IP-start IP-end Feed Address
1 13.70.151.216 13.70.151.216 IPFilter/ipfliter office365
ipfilter_office365
ipfilter_office365
ipfilter office365
ipfilter_office365
ipfilter_office365
ipfilter_office365
ipfilter_office365
ipfilter office365
ipfilter_office365
ipfilter office365

ipfilter_office365
ipfilter_office365
ipfilter office365
Instance default Total number of matching entries: 72
lab@vSRX-l>

Step 2.22
From the CLI session with the vSRX-1, check the configurations generated as a result of enabling a policy
with the 0ffice365 dynamic address group.
[edit]
lab@vSRX-l# show services security-intelligence
url https://172.25.11.101:443/api/vl/manifest.xml;
authentication {
auth-token 6XYNM4KKLPSI16FOC1LYKIDOD2K9GYKO;
}
[edit]
lab@vSRX-l# show security dynamic-address
address-name ipfilter office365 {
description n Policy Enforcer feeds.";
profile {
category IPFilter {
feed ipfilter office365;
}
}
}
[edit]
lab@vSRX-l# show security policies
from-zone Juniper-SV to-zone untrust {
policy allow-office-365 {
description n Allows outbound Office 365 traffic";
match {
source-address any;
destination-address ipfilter_office365;
application any;
}
then {
permit;
}
}
}
default-policy {
deny-all;
}
[edit]
lab@vSRX-l# exit
lab@vSRX-l>

Step 2.23
From the CLI session with the vSRX-VR device, test the functionality of the 0ffice365 policy by issuing a
ping to the IP address you recorded in step 2.21 sourced from the vrlOl routing instance. Leave the
ping running and proceed to the next step.
PING 13.107.127.255 (13.107.127.255): 56 data bytes
Question: Does the ping succeed?
Answer: The result will vary. Not all Office 365 end points will respond
to pings. We will verify that the traffic is allowed in the next step.
Step 2.24
From the vSRX-1 session, verify that the ping from the vrlOl routing instance is permitted by the
allow-office-365 policy by issuing the show security flow session
destination-prefix <office-365-ip> command
lab@vSRX-l> show security flow session destination-prefix 13.107.127.255

Session ID: 329887, Policy name: allow-office-365/4, Timeout: 40, Valid
In: 10.10.101.10/20511 — 13.107.127.255/0;icmp. Conn Tag: 0x0, If: ge-0/0/4.0.
Out: 13.107.127.255/0 172.18.1.2/12830;icmp. Conn Tag: 0x0, If: ge-0/0/1.0.
Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Session ID: 329897, Policy name: allow-office-3 65/4, Timeout: 44, Valid
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,
Out: 13.107.127.255/10 — 172.18.1.2/12278;icmp. Conn Tag: 0x0, If: ge-0/0/1.0.
Pkts : 0, Bytes: 0,
Out: 13.107.127.255/11 172.18.1.2/9820;icmp, Conn Tag: 0x0, If: ge-0/0/1.0.
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,
Pkts : 0, Bytes: 0,

In: 10.10.101.10/20511 13.107.127.255/14;icmp. Conn Tag: 0x0, If: ge-0/0/
4.0, Pkts : Iz Bytes: 84,
Out: 13.107.127.255/14 172.18.1.2/4938;icmp, Conn Tag: 0x0, If: ge-0/0/1.0.
Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,

Pkts : 0, Bytes: 0,
Total sessions: 21
lab@vSRX-l>
Question: Is the ping allowed by the correct policy?
Answer: Yes. You should see one or more icmp sessions to the
0ffice365 destination being allowed by the policy.
Step 2.25
From the session with the vSRX-VR device, end the ping by issuing ctrl+c.
PING 13.107.127.255 (13.107.127.255): 56 data bytes
C
Step 2.26
Open a web browser and return to the session with the Junos Space Security Director.
From the Security Director GUI, navigate to Conf igure->Firewall Policy->Standard
Policies. Click on the vSRX-1 policy.
Configure / Firewall Pobcy I Standard Policies Q Global

0 s ?
Firewall Policy Standard Policies®

Standard Policies
Unified Policies
Devices
Global Options Locking w More *■ Q V’
Schedules
Profiles □ Seq. Name Rules Devices Publish State Last Modified Created By Modified By Domain
Templates
V POLICIES APPLIED BEFORE DEVICE SPECIFIC POLICIES' (1 policy)
Environment
■» User Firewall Management >

□ 1 All Devices Policy Pre Add Rule 2 Not Published Wed Jun 03.2020 6:19 PM System Global
Application Firewall Policy > '>/ DEVICE SPECIFIC POLICIES (2 policies)
SSL Profiles > □ vSRX-1 1 vSRX-1 Not Published Frijun 05,2020 10:48 AM super super Global
IPS Policy > □ vSRX-2 4 vSRX-2 Not Published Thujun 04,2020 8:21 PM super super Global
NAT Policy >
POLICIES APPLIED AFTER DEVICE SPECIFIC POLICIES' (1 policy)
UTM Policy >
Application Policy Based Rouli... □ 2 All Devices Policy Post Add Rule 2 Not Published Wed Jun 03,2020 6:19 PM System Global
Threat Prevention > 4 items
IPSecVPN >
Shared Objects >
Change Management >
Guided Setup >
Step 2.27
In the Rules screen, check the box for the allow-office-365 policy and click the trash bin icon.
Click Yes to confirm the delete.
Configure / Firewafl Policy / Standard Policies q Global s ?
Firewall Policy
vSRX-1 / Rules Ldited few seconds ago
Standard Policies
Unified Policies Publish Update Shared Objects * More v + / © Id q Y- :

Devices
Schedules
Seq.
Hit Co... Rule Name Src. Zone Src. Address Src. Expression UserID End User Profile best. Zone
Profiles
Templates V/ ZONE(1 Rule)
Environment io NA allow-office-365 Juniper-SV A Any I untrust
User Firewall Management > V GLOBAL (0 Rule)

SSL Profiles >
IPS Policy > Firewall Rules
NAT Policy > Are you sure you want to delete the selected policy rules?
UTM Policy >
No Yes
Threat Prevention >

IPSecVPN >
Shared Objects >
Step 2.28
Open a web browser and navigate to https: //sky. junipersecurity. net.
Login with the realm credentials provided by your instructor.

SkyATP
Version 3.0 | Login
student@juniper.net
ajsec-realm-l
□ Remember me
Log In
Step 2.29
From the SkyATP interface, navigate to Conf igure->Third Party Feeds.
Uncheck the Enable feed checkbox next to of f ice 3 6 5.
Configure / Third Party Feeds What’s new ajsec-realm-1 J 9

Third Party Feeds©
Email Management >
IP Filter Feed
Whitelists
ivg Blacklists □ Enable feed

office365
Third Party Feeds Go to feed site

im
Global Configuration > Command and Control Feeds
Select to enable open source feeds managed by third parties.
H I The accuracy of these feeds cannot be guaranteed, and false positives generated by these feeds will not be
investigated by Juniper Networks. Security policies will block malicious IPaddresses and domains based on
X
enabled third party feeds, but these events do not affect host threat scores.
s?
IP Feed
Part 3: Creating a Firewall Policy using a Custom Feed
In this lab party, you will create a custom HTTP feed. You will then configure this as a custom feed in the
Security Director interface and create a Firewall Policy using this feed as a dynamic address group. You
will then validate the function of this policy using the JunOS CLI
Step 3.1
Open a command line interface (CLI) session to the Virtual Desktop device.
From the CLI session with the Virtual Desktop device, issue the curl localhost command.
labQdesktop:~$ curl localhost
<hl>Welcome to the AJSEC IPFilter feed server!</hl
To enable a custom feed. create a file with one IP address per line
and save to the /var/www/html directory. You can then configure
This as a custom feed in Security director at the URL:
http://<desktop ip>/<feed filename>

</p>
labOdesktop:
Step 3.2
From the Virtual Desktop session, create a new feed file by navigating to the /var/www/html directory
and issuing sudo touch myfeed.
lab@desktop:cd /var/www/html
lab@desktop :/var/www/htinl$ sudo touch myfeed
Step 3.3
Open the myf eed file for editing by issuing nano myfeed.
Add the following IP addresses to the file, adding a newline between each entry:
203.0.113.100
203.0.113.101
203.0.113.102
203.0.113.103
Press ctrl+o, followed by enter, then ctrl+x to save the file and exit nano.
lab@desktop :/var/www/htinl$ nano myfeed
I GNU nano 2.5.3 File; myfeed Modified |
203.0.113.100
203.0.113.101
203.0.113.102
203.0.113.103Q
Get Help
Exit E Write Out
Read File
Where Is
Replace
Cut Text
Uncut Text
Justify
To Spell
Cur Pos
Go To Line B
Prev Page
Next Page
Step 3.4
From the Virtual Desktop CLI, verify your custom feed by issuing curl localhost/myfeed.
lab@desktop:/var/www/html$ curl localhost/myfeed
203.0.113.100
203.0.113.101
203.0.113.102
203.0.113.103

Step 3.5
Open a web browser and navigate to the address of the Junos Space Security Director.
Login with the username super and password Junlp3rl23!
juniper

Version 19.4R1
I super
1
I
Log In
I
(
r
I L J
Copyrli 11^ X19, luniper Networks, me All ! frnci‘mark Notice | Privacy Policy
Step 3.6
Navigate Conf igure->Threat Prevention->Feed Sources. Click on the Custom Feeds
tab. Click Create->Feed with remote file server.
Configure / Threat Prevention / Feed Sources Q Global

0 s ?
Firewall Policy Feed Sources @

standard Policies
Unified Policies
Devices
Schedules
Profiles
Templates
Settir^gs Create Q 7
Environment
Feeds with local files
User Firewall Management > Feeds with remote file server
Q A Name Feed Type Last updated Days to Become inactive Remote Download Status Description
No data available
SSL Profiles >
IPS Policy >
NAT Policy >
UTM Policy >
Threat Prevention
Step 3.7
In the Create remote custom feed dialog, configure the feed with the following options
Name: aj secfeed
Feed Type: Dynamic Address
Type of server url: http
Server File URL: http: //172.25.11.254/myfeed
Username: <blank>
Password: <blank>

Update Interval: Hourly

Zones/Realms: select <your Realin>
Click OK. Wait for the Remote Download Status column to show a value of Success.
Create remote custom feed ®
Name* (2) ajsecfeed
Description © Write descnption..
Feed Type* (2) Dynamic Address v
Type of server uri* (2) ® hup

O https
Server File URL* http://172.25.11.254/myfeed
Username (2)
Password (2)
Update Interval* (2) Hourly V
Zones/Realms* (2) 0 Available q 1 Selected q

□ Zones/Realms
□ Zones/Realms
-i
□ aJsec-student-01
Cancel OK
Step 3.8
Navigate to Conf igure->Firewall Policy->Standard Policies. Click on the vSRX-1 policy.
Click + to add a new rule.
Configure ! Firewell Policy / Stenderd Policies Q Global

a 15 s ?
X Firewall Policy
vSRX-1 / Rules Edited 34 minute<s) ago
Standard Policies Create
Unified Policies Publish Update Shared Objects More v 7\ Q V’ :

Devices
i^
Schedules
Seq.
Hit Co... Rule Name Src. Zone Src. Address Src. Expression User ID End User Profile Dest. Zone
Profiles
Templates v* ZONE (0 Rule)
Environment \Z GLOBAL (0 Rule)
User Firewall Management >

SSL Profiles >
IPS Policy >
NAT Policy >
Step 3.9
In the General dialog, configure a Rule Name of allow-myfeed. Click Next.

Create Rule ©
General
General Information
Rule Name* ® allow-myfeed
Description ©
Cancel Next
Step 3.10
In the Source dialog, select a Zone of Juniper-sv. Click Next.
Create Rule ©
o—
General Source
Source
Zone © »Juniper-SV
Clear All
Address(es) © Select
Any
User ID © Select
End User Profile ©
Clear All
Cancel Back Next
Step 3.11
In the Destination dialog, select a Zone of untrust.
Click the Select button for Addresses.

Create Rule®
o— o—
Gei'ers' Soizte Destin«tk»n
Destination
Zone ® « untrust
Clear All
Addressees) ® Select
Any
Service Protocols
Service(s) O Select
Any
Cancel Back Next
Step 3.12
Check the Include Specific radio button.
Check the box for aj secfeed and click the arrow to select a j secfeed. Click OK. Click Next.
Create Rule ®
o o
Destination Address ®
cestiH; You can r r : ok ei*:- iiaM-- list S •j'j* eni

“ ngti-----jAdo ^.-.-'Des^- -- bur?"
Address Selection ® O Include Any Address
® Include Specific
O Exclude Specific
O Sy Metadata Filter
Addresses (S) 13 Available 1 Selected Q
□ Name Domain □ Name Domain
□ Any-iPv4 SYSTEM □ myfeed Global
□ Any-IPv6 SYSTEM
□ Internet-host {172.31... Global
□ ipfitter_office365 Global
□ lab-peg.10.10.101.1/... Global
Add New Destination Address
Cancel OK
Caixel Back Next
Step 3.13
In the Advanced Security dialog, select the action of Permit. Click Next.

Create Rule ©
o— o- o—
Ge“e'’8' Sowfce Oesti-afor Advanced Security
Advanced Security
Rule Action
Aaion © Permit
Advanced Security
App Firewall ® Select an option Clear All Add New
Supported m Junos OS version 18.1 and lower. For Jiaios

18.2 version and later, use dynamic application of Unified
Arewall Policies to support App Firewall
SSL Proxy O Select an option Clear All Add Forward Proxy Add Reverse Proxy
IPS ® Off
•fXKted m Junos OS version 18 1 and lower
IPS Policy ® Select an option Clear All
Supported m Junos OS version 18 2 and later
UTM ® Select an option Clear All Add New
Threat Prevention Policy ® Select an option Clear All
Cancel Sack Next
Step 3.14
In the Rule Analysis dialog click Next. In the Rule Placement dialog click Finish. In the
Create Rule summary screen, click OK.
Create Rule ©
o— o— c---- Q o
Ge“e'3' So_r:e Desti“atcr Ad.arcec Seounty Rule Options Rule Analysis R-'e Placer-er:
Rule Analysis 0 O Analyze the new rule to suggest a placeme...
Cancel Back Next

Create Rule ©
o— o— o— o------- o— o—
Ge“e*8 Sowfce 0esTi“a:ior Ac\-3“cec Sec-nr/ Rwie Op:«rs (U'e Ara'-yss Rule Placement
Analysis
Results No rule analysis was performed, when rule analysis Is not performed, the system will suggest a placement according
to the information provided in steps 1 to 5.
Rule Placing
Rule Type ZONE
Location / Sequence Rule Sequence will be No. 2
View Placement inside Policy
Cancel Back finish
Create Rule ©
Summary
General Information
Edit
Name allow-myfeed
Identify Traffic Source Edit
Zone Juniper-SV
Address Any
Identify Traffic Destination Edit
Zone untrust
Address ajsecfeed
Service Any
Advanced Security Edit
IPS Off
Action PERMIT
Rule Options Edit
Profile Inherited from policy
Cancel Back OK
Step 3.15
In the Rules page, click Save, then Update. In the Update Firewall Policy screen, click
Publish and Update. Click Yes to confirm.

Update Firewall Policy©
Type* (2) (S) Run now

O Schedule ata later time
1 selected Q :
□ Device Name Publish Req... Configure... Ma... Connection S... Services Domain Device ip Platform OS version
vSRX-1 Required View O In... up vSRX-1 Global 172.25.11.1 VSRX 20.1 RI.11
1 items
Step 3.16
In the Job Status screen, wait until the Job State shows a state of Success. Click OK.
Job Status®
♦ ♦
229614 229615 229616
© ©
Job Type: update Devices Job State: Success 0
job ID: 229616 Percent Complete: 100%

Job Name: Update Devices-229616 Scheduled Start Time: Fri. 05 Jun 2020 11:33;01 POT
User: super Actual Start Time: Fri. 05 Jun 202011:33:01 POT
End Time: Fri, 05 Jun 2020 11:33:06 POT
Export to CSV Q Y
vSRX-1 (vSRX-1) Success vSRX-1 [FWPolicy] View View Fri, 05 Jun 2020 11:33^>5 PST
1 Rows
OK
Step 3.17
Log in to the command line interface (CLI) for vSRX-1.
From the vSRX-1 CLI session, verify that the custom feed has been added by issuing the show
services security-intelligence category summary command.
Category name :IPFilter

Status :Enable
Description :Customer category IPFilter
TTL :2592000s
Feed name : aj secfeed
Version : 1591381271.1
Objects number:4
Create time :2020-06-05 18:21:11 UTC
Update time :2020-06-05 18:33:20 UTC

Expired :No
Status :Active
Options :N/A
lab@vSRX-l>
Step 3.18
From the vSRX-1 session, verify that the ajsec-custom-feed dynamic address group contains the correct
addresses by issuing the show security dynamic-address address-name ajsec-custom-feed command.
lab@vSRX-l> show security dynamic-address address-name ajsecfeed
No. IP-start IP-end Feed Address
1 203.0.113.100 203.0.113.100 IPFiIter/ajsecfeed aj secfeed
lab@vSRX-l>
Step 3.19
Verify the security intelligence configuration by entering configuration mode and issuing show services
security-intelligence.
[edit]
lab@vSRX-l# show services security-intelligence
url https://172.25.11.101:443/api/vl/manifest.xml;
authentication {
auth-token 6XYNM4KKLPSI16FOC1LYKIDOD2K9GYKO;
}
[edit]
lab@vSRX-l#
Step 3.20
Verify that the correct security policy has been configure by issuing show security policies
[edit]
lab@vSRX-l# show security policies
from-zone Juniper-SV to-zone untrust {
policy allow-myfeed {
match {
source-address any;
destination-address ajsecfeed;
application any;
}
then {
permit;
}
}
}
default-policy {
deny-all;
}

[edit]
lab@vSRX-l#
Step 3.21
From the CLI session with the vSRX-VR device, test the functionality of the ajsec-custom-feed policy by
issuing a ping to the 203.0.113.101 address in your custom feed.
PING 203.0.113.101 (203.0.113.101): 56 data bytes
Question: Does the ping succeed?
Answer: Yes, the ping should succeed. If it does not, verify your
configuration and notify your instructor.
Step 3.22
From the vSRX-1 session, verify that the ping from the vrlOl routing instance is permitted by the
allow-myfeed policy by issuing the show security flow session destination-prefix 203.0.113.101
command
[edit]
Session ID: 338211, Policy name: allow-myfeed/5, Timeout: 2, Valid


Total sessions: 3

[edit]
lab@vSRX-l#
Step 3.23
From the session with the vSRX-VR device, end the ping by issuing ctrl+c.

64 bytes from 203.0.113.101: iemp seq=9 ttl=63 time=3.656 ms

lab@vSRX-VR>
Part 4: Cleaning Up
In this lab part, you will return the lab environment to its starting state.
Step 4.1
Open a web browser and navigate to the address of the Junos Space Security Director.
If the session has expired, login with user super and password Junlp3rl23!
juniper
NCTWOP':. a
r
(. I

Version I9.4R1
/ super
Log In
II
rî
Copyrli Juniper Networks, loc. AW emark Nooce | Privacy Polky
p”
I

Step 4.2
Navigate to Devices->Security Devices. Select all Devices. Right click and select
Operations->Delete Devices. Click OK to confirm the deletion.
Devices / Security Devices Q Global V a s 9
Security Devices Security Devices ©

Device Discovery
Secure Fabric [ ResyiKtironge with Netiwrfc | [ More

2 selected Update Changes Q ¥ :
NSX Managers
configuration
vCenter Servers
[■^1 OS Version Connection Delete Devices Operations Id Status
Q Device Name ▼ IP Address CPU Storage
Reboot Devices
Q . V5RX-2 172.25.11.2 20.1 RI .11 ▲ up 'ged
Resynchronize with Network
□ .
■ vSRX-1 172.25.11.1 20.1 RI .11 ▲ up
View Inventory Details
IC
items 1 >0 V
Update Changes
Upload Keys
Import
Refresh Certificate
Acknowledge Device Angerprint
Step 4.3
Wait for the Job Details screen to show a Job State of Success.
Job Details:Delete Device
lob ID 229620 Scheduled Stan Ti... Fri. 05 Jun 2020 11:48:44 PDT
Job Name Delete Device-229620 Actual Start Time Fri, 05 Jun 202011:48;44 POT
Job State End Time Fri. 05 Jun 2020 11:48:51 PDT

@Success
Owner super
Q ;
Name IP Address Job Status Description
vSRX-1 172.25.11.1 SUCCESS Device deleted successfully
vSRX-2 172.25.11.2 SUCCESS Device deleted successfully
2 Rows
OK
Step 4.4
Navigate to Conf igure->Firewall Policy->Standard Policies. Select the vSRX-1 and
vSRX-2 policies. Click the trash bin icon to delete. Click Yes to confirm.

Configure / Firewall Pokey / StandardPelicles Q Global

0 s ?
X Firewall Policy Standard Policies®

Standard Policies
Delete
Unified Policies
Devices
2 selected Publish Update Global Options Lockir>g More Q Y’
Schedules
Profiles
□ Seq. Name Rules Devices Publish State Last Modified Created By Modified By Domain
Templates
POLICIES APPLIED BEFORE DEVICE SPECIFIC POLICIES' (1 policy)
Environment
User Firewall Management > □ 1 All Devices Policy Pre Add Rule Not Published Wed Jun 03,2020 6:19 PM System Global
Application Firewall Policy > V DEVICE SPECIFIC POLICIES (2 policies)
SSL Profiles > a vSRX-1 1 Published Frijun 05,202011:32 AM super super Global
IPS Policy > a vSRX-2 4 Not Published Thu Jun 04,2020 8:21 PM super super Global
NAT Policy >
UTM Policy >
Application Policy Based Routi... □ 2 All Devices Policy Post Add Rule Not Published Wed Jun 03,2020 6:19 PM System Global
Threat Prevention
4 items
Policies
Feed Sources
Step 4.5
Navigate to Conf igure->Threat Prevention->Feed Sources. In the SkyATP tab, check the box
for your SkyATP realm and click the trash bin icon to delete. Click Yes to confirm.
Configure / Thre« Preverroon / Feed Sources Q Global s ?
X Firewall Policy Feed Sources®

Standard Policies
Unified Policies
Devices
s Sky ATP JATP Custom Feeds
Schedules
Delete
Profiles
Templates
1 selected More '«■' + z ©
Environment
H User Firewall Management > □ Realm Sites Devices Location Enrollment Status Token Expiry Feed Status Last Downloaded
Application Firewall Policy > □ > ajsec-rea1m-1 ajsec-lab vSRX-1 +1 North America SUCCESS Jun 4, 2021 0OK Jun 5, 2020,11:50:06
® SSL Profiles > 1 items C
IPS Policy >
NAT Policy >
UTM Policy >
Threat Prevention
Step 4.6
Click the Custom Feeds tab. Check the box for a j secfeed and click the trash bin icon to delete.
Click Yes to confirm.
Global
Configure / Threat Prevention / Feed Sources q s
X Firewall Policy Feed Sources ®

Standard Policies
(S) Unified Policies
Devices
Schedules
Profiles
Delete
Templates
1 selected Settings Create Z 0 q Y
Environment
H User Firewall Management >

Q A Name Feed Type Last Updated Days to Become Inactive Remote Download Status Description
SSL Profiles > ea myfeed Dynamic-Address June 05.202011:20 AM 30 ©Failed
IPS Policy > 1 items O
NAT Policy >

UTM Policy >
Step 4.7
Return to the CLI session with the Virtual Desktop.
Remove the myfeed file by issuing rm myfeed.
lab@desktop:/var/www/html$ rm myfeed
Lab 10-38 SecIntel www.juniper.net

Step 4.8
On the Virtual Desktop device, terminate the CLI session by issuing the exit command.
labOdesktop:/var/www/htinl$ exit
Step 4.9
On the vSRX-1 device, terminate the CLI session by issuing the exit command.
lab@vSRX-l> exit
login:
Step 4.10
lab@vSRX-2 exit
login:
Step 4.11
lab@vSRX-VR> exit
login:


vSRX-1
rT'T~;
ATP Cloud
vSRX-2 I ge-0/0/0 (on all student devices)
35
L Lli11 Physical
vSRX-VR 172.25.11,254
’ilib;
Internet
VNC Connections
Junos
Space
Policy
Enforcer 1 Hypervisor
vSRX-1 172.25.11.1

Core ATP On-Prem
Network
vQFX-1 172.25.11.10
c
AD/NTP/DNS Server
3
Lab Environment ATP On-Prem 172.25.11.120

Gateway 172.25.11.254

juniper
NETWORKS
Lab Network Diagram: SecIntel
vSRX-VR
loO: 192.168.9.1
•<?
<3/^
untrust zone 'J'

55^ (.103)
(.102)
(.101)
vSRX-1
(.100)
loO: 192.168.1.1 myfeed
(.1)
hosts
ge-0/0/4
10.10.101.0/24 10.10.102.0/24
(.10) (•loy
vr101 vr102
Juniper-SV zone ACME-SV zone

vSRX-VR
jumper
NETWORKS

Lab
Juniper ATP On-Prem
Overview
In this lab, you go through the setup process on both the Juniper ATP On-Prem Core and Web Traffic
Collector and then run diagnostics to verify that the devices are working correctly. You will then configure
the collector to collect SMB and SSH traffic. After the configuration phase you will use the GUI to see
incidents that you created.
• Setup the main components to Juniper ATP On-Prem.
• Diagnose the setup to verify connections to components.
• Configure and test SMB collection.
• Configure and test Honey Pot collection.
www.juniper.net Juniper ATP On-Prem • Lab 11-1

Part 1: Connect to Devices

In this lab part, you will use the command-line interface (CLI) to log in to the vSRX-1, vSRX-2, vSRX-VR and
vQFX devices. Next, you will load the starting configurations for the lab. You will then use the command
line interface (CLI) to log in to the ATP-OnPrem and the ATP-Coll devices.
Note
step 1.1
You will pri ma ri ly configure the vSRX-1, vQFX ATP-OnPrem and the ATP-Coll devices. The vSRX-2 and
vSRX-VR devices are already configured for you. Consult the Management Network Diagram to determine
the management addresses of your devices.

devices?

Step 1.2
Access the CLI on the vSRX-1 device as directed by your instructor. Log in with the username lab and
password labl23. Enter configuration mode and load the labll-start.config from the ajsec
directory. Commit the configuration when complete and exit to operational mode.
login: lab
Password:

[edit]
lab@vSRX-l# load override ajsec/labll-start.config
[edit]
commit complete
lab@vSRX-l>
Lab 11-2 • Juniper ATP On-Prem www.juniper.net

Step 1.3
and load the reset configuration file using the load override a jsec/labll-start. config
login: lab
Password:

[edit]
lab@vSRX-2# load override ajsec/labll-start.config
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.4
and load the reset configuration file using the load override a jsec/labll-start. config
login: lab
Password:

[edit]
lab@vSRX-VR# load override ajsec/labll-start.config
[edit]
lab@vSRX-VR# commit
commit complete
[edit]
lab@vSRX-VR#

Step 1.5
Open a new session with the vQFX-1 device.
On the vQFX-1 device, login with the username lab and password labl23. Enter configuration mode
and load the reset configuration file using the load override ajsec/labll-s tart .config
login: lab
Password:
Last login: Thu Jun 4 22:00:18 2020 from 172.25.11.254
-- JUNOS 17.4R1.16 built 2017-12-19 20:03:37 UTC

{master:0}
lab@vQFX-l> configure
{master:0}[edit]
lab@vQFX-l# load override ajsec/labll-start.config
load complete
{master:0}[edit]
lab@vQFX-l# commit
configuration check succeeds
commit complete
{master:0}[edit]
lab@vQFX-l#
Step 1.6
Open a new session with the ATP-OnPrem device.
On the ATP-OnPrem device, login with the username admin and password Jiiniperl23.
■k k
Juniper Networks Advanced Threat Prevention Appliance
k k
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Welcome admin. It is now Thu Jun 4 15:10:36 PDT 2020

ATP-OnPrem:Core#
Step 1.7
Open a new session with the ATP-Coll device.
On the ATP-Coll device, login with the username admin and password Juniperl23.
k k
k k
Welcome admin. It is now Thu Jun 4 15:13:25 PDT 2020

ATP-Coll:WebCol#

Part 2: Juniper ATP On-Prem Setup
In this part you will configure the Juniper ATP On-Prem with an initial configuration. You will then verify the
installation and connectivity to make sure it is running. Once you have verified it is working, attach a web
collector to the core.
Step 2.1
Return to the open session to the Juniper ATP On-Prem Core device, ATP-OnPrem, and type in a ? to bring
up the list of options.
ATP-OnPrem:Core# ?
cm Change to the Central Manager configuration mode
core Change to the Core configuration mode
diagnosis Change to the diagnosis mode
exit Exit the Juniper ATP Appliance CLI session
help Display an overview of the CLI syntax
history Display the current session’s command line history
server Change to the server configuration mode
wizard Run the configuration wizard
ATP-OnPrem:Core#
Step 2.2
Run the wizard command to setup the Juniper JATP On-Prem Core. It has already been setup so answer
yes, to the questions about re-running the wizard. Then answer no to the using DHCP on the
management address, so that we can enter in our static IP information.
'k k
kr k
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
ATP-OnPrem:Core# wizard
The basic system configuration has been done already. Do you want to re-run the
configuration wizard again (Yes/No)? Yes
'k "k "k 'k 'k

Setting the IP address and Domain Name Servers •:Ar ■:Ar ■:Ar
Use DHCP to obtain the IP address and DNS server address for the management (ethO)
interface (Yes/No)? No
Step 2.3
Enter the following options about the management (ethO) interface. When asked to for a secondary DNS
server answer yes, and then restart the management interface.
IP address: 172.25.11.120
netmask: 255.255.255.0
Gateway IP address: 172.25.11.254
Primary DNS Server: 172.25.11.130
Secondary DNS Server: 8.8.8.8
Search Domains: No
Enter IP address for this management (ethO) interface: 172.25.11.120

Enter netmask for this management (ethO) interface: 255.255.255.0
Enter gateway IP Address for this management (ethO) interface: 172.25.11.254
Enter primary DNS server IP Address for the management (ethO) interface:
172.25.11.130
Do you have a secondary DNS server for the management (ethO) interface? (Yes/No)?
Yes
Enter secondary DNS server IP Address for management (ethO) interface: 8.8.8.8
Do you want to enter the search domains for management (ethO) interface? (Yes/No)?
no
Restart the management (ethO) interface (Yes/No)? Yes
- Stopping behavioral service
- A complete network interface restart can take more than 60 seconds
- Restarting exhaust-bridge interface
waiting for lock on /run/network/ifstate.cyos_br_cooker
- Starting behavioral service
Step 2.4
Continue the wizard by naming the Juniper ATP On-Prem device ATP-OnPrem and regenerate the SSL
self-signed certificate.
"k "k 'k 'k "k
Setting the device host name ■:Ar •:Ar •:Ar ■:Ar •:Ar
Please enter a valid hostname: ATP-OnPrem

Updating server FQDN to ATP-OnPrem.eng.ATP-OnPrem.com
Regenerate the SSL self-signed certificate? (Yes/No)? Yes
SSL Self-signed certificate re-generated successfully!
The hostname will be updated after the next login.
Step 2.5
Enter the following server attributes.
Central Manager: Yes
Device name: cm-atp
Device Description: AJSEC Lab
Device key passphrase: juniper
k k k -k
Setting the device basic attributes ■:Ar •:Ar •:Ar ■:Ar ■:Ar
Please enter the following server attributes...

Is this a Central Manager device (Yes/No)? Yes
Device name: CM-ATP
Device description: AJSEC Lab
--- Restarting all services----
Adding *127.0.0.1’ to the whitelist...
The specified iptables rule already exists and will not be added again.
ATP-OnPrem:Core#

Question: Is the device key passphrase important?
Answer: Yes, you should always remember this and keep it

confidential. The distributed system that can be created with
collectors, multiple cores, and secondary cores, must have this
passphrase to function together.
Step 2.6
Return tho the ATP-Coll device and run the setup wizard on the collector to pair it with the ATP Core we
just set up. Answer yes to re-running the configuration wizard and no to using DHCP to obtain an IP
address.
ATP-Coll:WebCol# wizard
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
k
Juniper Networks Advanced Threat Prevention Appliance k
k k
The basic system configuration has been done already. Do you want to re-run the
configuration wizard again (Yes/No)? Yes
Setting the IP address and Domain Name Servers k k k -k k k

'k "k "k 'k 'k "k
Use DHCP to obtain the IP address and DNS server address for the management (ethO)
interface (Yes/No)? No
Step 2.1
Enter the following options about the management (ethO) interface. When asked for a secondary DNS
server answer yes, and then restart the management interface.
IP address: 172.25.11.121
netmask: 255.255.255.0
Gateway IP address: 172.25.11.254
Primary DNS Server: 172.25.11.130
Secondary DNS Server: 8.8.8.8
Search Domains: No
Enter IP address for this management (ethO) interface: 172.25.11.121

Enter netmask for this management (ethO) interface: 255.255.255.0
Enter gateway IP Address for this management (ethO) interface: 172.25.11.254
Enter primary DNS server IP Address for the management (ethO) interface:
172.25.11.130
Do you have a secondary DNS server for the management (ethO) interface? (Yes/No)?
yes
Enter secondary DNS server IP Address for management (ethO) interface: 8.8.8.8
Do you want to enter the search domains for management (ethO) interface? (Yes/No)?
no
Restart the management (ethO) interface (Yes/No)? Yes

- A complete network interface restart can take more than 60 seconds

- Restarting management (ethO) interface
Step 2.8
Configure a host name of atp-Co11 and then enter the information to attach the collector to the Juniper
ATP On-Prem Central Manager that we just set up.
Setting the device basic attributes
"k "k 'k 'k "k 'k -jlr
Please enter the following server attributes...

Enter a valid Hostname: ATP-Coll
Central Manager IP address: 172.25.11.120
Device name: ATP-Coll
Device description: AJSEC Collector
--- Restarting all services----
Adding '172.25.11.120’ to the whitelist...
The specified iptables rule already exists and will not be added again.
ATP-Coll:WebCol#
Step 2.9
Verify that the collector can ping the management interface of the Central Manager. You must first move
to the server hierarchy to run the ping command.
ATP-Coll:WebCol# server
Entering the server configuration mode...
ATP-Coll:WebCol#(server)# ping 172.25.11.120
PING 172.25.11.120 (172.25.11.120) 56(84) bytes of data.

5 packets transmitted. 5 received. 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.370/0.379/0.403/0.012 ms
ATP-Coll:WebCol#(server)#
Question: Was the ping to the Central Manager successful?
Answer: As, you can see in the output the ping should have been
successful. If not please notify your instructor.
Step 2.10
List the interfaces on the collector by issuing the show interface ? command. Use the names of the
interfaces to look at the management interface and the honeypot interface.
ATP-Coll:WebCol#(server)# show interface ?
management Show the management interface
monitoring Show the monitoring interface

alternate-exhaust Show the alternate exhaust interface

honeypot Show the honeypot interface
<cr>
ATP-Coll:WebCol#(server)# show interface management

Interface: management (ethO) Enabled: Yes Link: Yes
IP Address: 172.25.11.121 Mask: 255.255.255.0 MTU: 1500
MAC Address: 00:50:56:a9:16:4b Speed: lOOOOMb/s Duplex: Full
Auto-negotiation: No Medium: Copper
RX packets: 6133 Bytes: 2863813 Errors: 0 Overruns: 0
TX packets: 5960 Bytes: 1375937 Errors: 0 Overruns: 0
Traffic rate for the last 5 seconds/1 minute/5 minutes
RX bits/sec: 568/6656/5904
RX packets/sec: 0/3/2
TX bits/sec: 848/4712/3520
TX packets/sec: 0/2/2
ATP-Coll:WebCol#(server)# show interface honeypot

Interface: honeypot (eth3) Enabled: Yes Link: Yes
IP Address: unknown Mask: unknown MTU: 1500
MAC Address: 00:50:56:a9:5d:18 Speed: lOOOOMb/s Duplex: Full
Auto-negotiation: No Medium: Copper
RX packets: 8629 Bytes: 607392 Errors: 0 Overruns: 0
TX packets: 34 Bytes: 2634 Errors: 0 Overruns: 0
Traffic rate for the last 5 seconds/1 minute/5 minutes
RX bits/sec: 0/0/0
RX packets/sec: 0/0/0
TX bits/sec: 0/0/0
TX packets/sec: 0/0/0
ATP-Coll:WebCol#(server)#
Question: What ethernet interfaces are mapped to names

management and honeypot?
Answer: Interface ethO is mapped to interface management and

eth3 is mapped to interface honeypot.
Step 2.11
Exit out of the server hierarchy and enter the diagnosis hierarchy. Let’s verify that everything is working
on our collector with the setupcheck all command. Since we do not have any traffic flowing at this
time when it monitors ethl break out of the test using Ctrl + c.
ATP-Coll:WebCol#(server)# exit
ATP-Coll:WebCol# diagnosis
ATP-Coll:WebCol#(diagnosis)# setupcheck all

Start interface status test to ethO ... [ OK ]
Start interface status test to ethl ... [ OK ]

Monitor traffic on ethl ... aborted [ FAIL ]

Autoupdate configuration(software/content)... [ OK ]
Testing file download from the Auto Update repository ... [ OK ]
Start file test to SSL client certificate ... [ OK ]
Start file test to SSL CA certificate ... [ OK ]
Start file test to SSL private key ... [ OK ]
Verifying installed Juniper JATP packages ... [ OK ]
Start test to Collector service ... [ OK ]
Start GSS API test ... [ OK ]
Start Central Manager web service API test (from Web Collector Agent) ...[ OK ]
Use CLI n setupcheck report under diagnosis mode to see more details.
II
ATP-Coll:WebCol#(diagnosis)#
Question: Did all the tests pass?
Answer: Yes, they all should have passed exceptMonitor traffic

on ethl might have failed. Some of the tests might display warn
instead of ok, this is acceptable.
Step 2.12
View the report created by the setupcheck all command with the setupcheck report
command. Press ‘q’ to quit the report.
ATP-Coll:WebCol#(diagnosis)# setupcheck report
[RESULT]:
[interface], [2020-06-05 10:57:24.532624]
ethO is up
ethl is up
[RESULT]:
[autoupdatetest] , [2020-06-05 10:57:24.533396]
[RESULT]:
[file], [2020-06-05 10:57:24.534155]
Found SSL client certificate
Found SSL CA certificate
Found SSL private key
All CyOS packages are properly installed.
[RESULT]:
[service], [2020-06-05 10:57:24.534207]
Test Collector service success
[RESULT]:
[api], [2020-06-05 10:57:24.534235]
GSS API test success
Central Manager web service API test (from Web Collector Agent) success
Step 2.13
Exit out of the diagnosis hierarchy and enter the collector hierarchy. Turn on the honeypot feature on the
collector using the set honeypot ssh-honeypot enable address 10.10.100.111
netmask 255.255.255.0 gateway 10.10.100.1 command

ATP-Coll:WebCol#(diagnosis)# exit
Leaving the server configuration mode...
ATP-Coll:WebCol# collector
Entering the Collector configuration mode...
ATP-Coll:WebCol#(collector)# set honeypot ssh-honeypot enable address
10.10.100.111 netmask 255.255.255.0 gateway 10.10.100.1
Enabled ssh-honeypot
- Starting honeypot service
ATP-Coll:WebCol#(collector) #
Step 2.14
Verify the honeypot configuration using the show honeypot ssh-honeypot command.
ATP-Coll:WebCol#(collector)# show honeypot ssh-honeypot
Enabled: using static config
IP: 10.10.100.111
netmask: 255.255.255.0
gateway: 10.10.100.1
ATP-Coll:WebCol#(collector)#
Step 2.15
Verify the protocol parsers that are enabled on the collector using the show protocols command.
ATP-Coll:WebCol#(collector)# show protocols
http parser is enabled
smb parser is disabled
Question: Are both the HTTP and the SMB parser enabled?
Answer: No, the HTTP parser is enabled but the SMB parser is
disabled.
Step 2.16
Enable the SMB parser using the set protocols smb on command. Then re-verify the protocols
parsers that are enabled.
ATP-Coll:WebCol#(collector)# set protocols smb on
ATP-Coll:WebCol#(collector)# show protocols
http parser is enabled
smb parser is enabled
Question: Are both the parsers enabled now?
Answer: Yes, both parsers are enabled.

Step 2.17
Return to the open session on ATP-OnPrem device move to the diagnosis hierarchy and run the
setupcheck all command. There are a few tests that might not complete for licensing reasons. You
may use ctrl-c to break out of individual tests.
ATP-OnPrem:Core# diagnosis
Entering the diagnosis mode...
ATP-OnPrem:Core#(diagnosis)# setupcheck all

Verifying active directory domain controller configuration ... [ SKIP ]
Start interface status test to ethO ... [ OK ]
Start ping test to 8.8.8.8 ... [ OK ]
start DNS test using the configured name server: 172.25.11.130 8.8.8.8[ OK ]
Start OpenDNS test to https://welcome.opendns.com ... [ WARN ]
Start Cloud ping test to gss.gss.junipersecurity.net ... [ OK ]
Autoupdate configuration(software/content )... [ OK ]
Retrieving Autoupdate URL ... [ OK ]
Testing file download from the Auto Update repository ...
Upgrade Path returned by REST Server is: TIER-l/precise-release-rainier.
[ OK ]
Check for valid product license ... [ OK ]
Check Static Engine(AV) initialization ... [ OK ]
Checking PAN Firewall connectivity... (Not configured) [ SKIP ]
Checking endpoint integration configuration... [ SKIP ]
Check for valid email notification configuration ... [ SKIP ]
Verifying email collector configuration ... [ OK ]
Start file test to Windows 7 analysis engine image and verify the SHA-1
checksum. It may take a few minutes ... [ FAIL ]
Start file test to Windows 10 analysis engine image and verify the SHA-1
checksum. It may take a few minutes ... [ FAIL ]
Start file test to SkyATP analysis engine image and verify the SHA-1 checksum.
It may take a few minutes ... [ OK ]
Start file test to SSL client certificate ... [ OK ]
Start file test to SSL CA certificate ... [ OK ]
Start file test to SSL private key ... [ OK ]
Verifying installed Juniper JATP packages ... [ OK ]
Start test to Static Engine service ... [ OK ]
Start test to Correlation service ... [ OK ]
Start test to Behavior Engine service ... [ OK ]
Start GSS API test ... [ FAIL ]
Start Reputation API test ... [ OK ]
Start Central Manager web service API test (from Core Agent) ... [ OK ]
Start analysis pipeline test [ OK ]
Use CLI n setupcheck report under diagnosis mode to see more details.
II
ATP-OnPrem:Core#(diagnosis)#
Question: Did any of the tests fail?
Answer: Yes, the one for GSS API test failed. This is because of the way
the lab is licensed to run Juniper ATP On-Prem Core. Also, the sandbox
tests for Windows 7 and Windows 10 fail.

Question: Why did some of the test return “skip” as the result?
Answer: When a feature is not configured the test for that feature is
skipped. An example is the first line of output, when if tries to verify
the active directory domain controller. That feature has not been
configured yet.
step 2.18
Verify that the collector configuations worked and that it is communicating with the ATP-OnPrem device.
Use the show device collectorstatus to see all the collectors.
ATP-OnPrem:Core#(diagnosis)# show device collectorstatus
WEB COLLECTOR
IP : 172.25.11.121
Enabled : True
Last Seen : 2020-06-05 14:36:33.390000-07:00
Install Date : 2018-09-12 11:59:22-07:00
ATP-OnPrem:Core#(diagnosis)#
Question: Is the collector communicating with the ATP-OnPrem

device?
Answer: Yes, as the output show it should be connected and enabled.
Part 3: Testing the Web Collector—HTTP

In this lab part you will verify the function of the web collector in scanning HTTP downloads.
Step 3.1
Open a web browser and navigate to the IP address of the JATP Web UI.
From the web browser, login with username admin and password Juniperl23.

jumper NETWORKS
MIZT\A/r\DtZC I
Advanced Threat Prevention Appliance

1
Username:
admin
Password:
Login
Powered by jiwper vemoo 5X17.15 corten wenaoo ia?Ji suspen I Resources ) contaaus
Question: What do you see upon successful login?
Answer: You should see the Dashboard, which contains details of

recent events, included Infected Hosts, Malware Trends and Top
Compromised Endpoints
Step 3.2
Click on the incident tab.
You should see a table of all recent events.
ADVANCED THREAT PREVENTION APPLIANCE Refresh Data O System Health A J-ATP Admin
Dashboard Incidents File Uploads Mitigation Reports Custom Rules Config
All Incidents (11 shown, 11 total)

SmtcK- Show Threat All Zones Last Month « E
Status T ♦ inadent ID Risk ♦ Threat 0 Progression t 0 Collector Type T 0 Threat Source I Threat Target ▼ I Zone T I Target OS I Collector Date A Time ♦
Complete 12 HIGH ViruS.DC DL 10.10.100.3 10.10.100.140 Oefaulx Zone Windows NT 6.3 web collector Jun 713:35:53 Pacific Daylight Time
Complete 11 HIGH Virus.OC DL 1010.100.3 1010.100140 Default Zone Windows NT 63 web coilecior Jun 614 49 07 Pacific Daylight Time
Complete 10 EICAR-TEST-SIGNATURE DL 213.211.198.58 10.10.100.140 lab unknown vSRX-i Jun 614 43 56 Pacific Daylight Time
Complete 9 EICAR-TEST-SIGNATURE DL 10.10.100.3 10.10.100.140 Default Zone web collector Jun 6 14:36:20 Pacific Daylight Time
Complete 8 EICAR-TEST-SIGNATURE DL ^3 1010100.3 10 10.100140 Defautt Zone web collector Jun 6 14 20 06 Pacific Daylight Time
Complete 7 [HIGH] Virus.DC DL 10.10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web coilector Jun 613:36:17 Pacific Daylight Time
Complete 6 EICAR-TEST-SIGNATURE DL 10.10100.3 10 10.1004 Default Zone web collector Jun 612 34 05 Pacific Daylight T ime
Complete 5 Susplclous.SSH.HP LS web-col lector-ssh-honeypot 10.10.100.6 Default Zone web collector Jun 612:31:00 Pacific Daylight Time
Complete 4 rHIGHi Virus.DC DL 10.10.100.3 10.10.100.4 Default Zone unknown web collector Jun 610:35:13 Pacific Daylight Time
Complete 3 EICAR-TEST-SIGNATURE DL ^3 2016.etcar.org 10 10.100 140 Default Zone Windows NT 6 3 web collector Jun 5 20 39 54 Pacific Daylight Time
Details forviru$.DC
SUMHARV DOWnujwn
Progression:
Actions
Target:
Zone: Default zone tr

DELIVERY
If A ih
COMMANDACONTROL
* 9
e
Phishing Exploits Downloads Executions Infections Custom Rules Lateral Spread
Incident id. 13
0 0 1 0 0 0 0
Hostname
Triggers:
Username:
iPAddress: 10.10.100140 Behavior
FQDN: 10.10.100 140
Source Email ID Custom Rules .

Lateral Spread >
Destination Email ID
Infection >
Lab 11-14 Juniper ATP On-Prem www.juniper.net

Question: What is the status of recent events?
Answer: You should notice that all pre-existing events have a status of
Complete, indicating the incident has been resolved. In the next step
you will generate an event by downloading simulated malware.
Note
Depending on your lab setup, you may not see

any previous events in this interface.
Step 3.3
Open a virtual console session with the WindowsClient device.
Within the WindowsClient session login with the user Administrator password trainlngl.
Open the Firefox web browser and navigate to http: //lO .10.100.3/fakemalware. When
prompted, insure the Save File option is checked, and click ok.
lO.IO.IOO.JfakemaIvvare C 0 Qoogle P @ 4^ *
0
Opening fakemalware X
You have chosen to open:
fakemalware
which is: application/octet-stream (398 KB)
from: http:/Z10.10.100.3
What should Firefox do with this file? 1

O Qpenwrth Browse...
®[êTile3
□ Do this automatically for files like this from nowon.
OK Cancel
Search
' Take where you've been everywhere you go. With a

Firefox Account, your bookmarks and tabs go with you.
Sign Up
Downloads Bookmarks
©
History Add-ons
oSync Options
Restore Previous Session
5:34 PM
IB
- <b ® Ite 6/8/2020
step 3.4
Return to the browser session with the Juniper ATP On-Prem GUI and click on the incidents tab.
Within the Juniper ATP GUI, click the Refresh Data option. Verify that an incident has been created
with a status of New.

ADVANCED THREAT PREVENTION APPLIANCE Refresh Data O System Health A J-ATPAdmin
All Incidents (11 shown, 11 total)

SeMcK Show Threat All Zones 0 Last Month • 0
I I Incident ID I Risk I Threat 0| Collector Type T f Threat Source f Zone T I Target OS t CoUeaor
Sutus T I Progression t ThreatTarget t Date & Time ♦
HIGH I Virus.OC Web Default zone Jun 71603:09 Pacific Daylight Time
DL 10.10.100.3 10.10.100.140 Windows NT 6.3 web colleaor
Complete 12 HIGH VirusDC DL 10.10100.3 10 10.100.140 Default Zone Windows NT 6 3 web collector Jun 713 35 53 Pacific Daylight Time
Complete 11 HIGH virus.OC DL 10,10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 614:49:07 Pacific Daylight Time
Complete 10 EICAR-TEST-SIGNATURE DL
^3 213 211198 58 10 10.100140 lab unknown vSRX-1 Jun 614 43 56 Pacific Daylight Time
Complete 9 EICAR-TEST-SIGNATURE DL 10,10.100.3 10.10.100.140 Default Zone web collector Jun f, 14:36:20 Pacific Daylight Time
CO 10101003 10 10100.140 Default Zone web colleaor Jun 614 20:06 Pacific Daylight Time
Complete 7 HIGH Virus.OC DL 10.10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 613:36:17 Pacific Daylight Time
Complete 6 EICAR-TEST-SIGNATURE DL 10.10.100.3 10.10.100.4 Default Zone web collector Jun i 12'34:0$ Pacific Daylight Time
Complete 5 Suspicious.SSH HP LS web-collector-ssh-honey pot 10.10.100.6 Default Zone web collector Jun 612:31:00 Pacific Daylight Time
Complete 4 HIGH Virus.OC DL 10.10.100.3 10.10.100.4 Default Zone unknown web colleaor Jun 610:35:13 Pacific Daylight Time
Complete 3 EICAR-TEST-SIGNATURE DL Î6.e*car.org 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 520.39.54 Pacific Daylight Time
Details for Viru$.0C
SUMMARY DOWNLOADS
Progression:
Actions
Target; DELIVERY
e EXPtXXTATlpN&
INSTALLATION COMMAND A CONTROL
e
Zone Default Zone tr nt A * 9
Phishing Exploits Downloads Executions infections Custom Rules Lateral Spread
incident Id: 13
0 0 1 0 0 0 0
Hostname:
Triggers:
Username
IP Address 1010100 140 Behavior
FQON: 10.10.100140
Source Email ID: Custom Rules

Lateral Spread
Destination Email ID.
infeaion
Execution
Risk High
Downloads ▲
Question: What are the details of this incident?
Answer: Existing incidents may be different than shown in this lab

guide. However, the new incident should indicate a risk of High
Collector type of Web, Threat Source of 10.10.100.3 and ThreatTarget
of 10.10.100.140.
Step 3.5
Click on the Incident ID associated with the new incident.
This will open a new tab containing details of this incident. Examine the details of the event under the
Summary tab.
ADVANCED THREAT PREVENTION APPLIANCE
Deuils for virus.OC
SUMMARY OCWmkUAuS
Progression:
Aaions
Targ«: DELIVERY
e COMMAND&CONTROL
w
Zone: Default zone
ti IP A lA * 9
Phishing Exploits Downloads Executions infections Custom Rules Lateral spread

Incident Id. 13
0 0 1 0 0 0 0
Hostname
Triggers:
Username-
iPAOdress: 10.10.100.140 Behavior
FQDN: 10.10.100.140
Source Email ID Custom Rules
Lateral Spread
Destination Email ID
Infection
Execution
Risk High
Downloads 4s
Threat Category: Virus Exploit
Phishing
Asset Value Medium
T 1
Target OS Windows NT 6 3
JUh JU*' JUh

Relevance Max
Progression: Download
Protocol: HTTP
OS Matched Yes
Summary Hi^ Risk Threat downloaded Virus DC
Coiieaors: web colleaor
source: 10.10.100.3(10.10.100.3}
Golden Images: Notconfi|ured

Step 3.6
Click the Downloads tab.
In the Downloads page, examine the details of the detected malware download.
When complete, close the new incident tab.
Details for Virus.OC
OOWNLOAOS
Seerdv
Severity
0.75
♦ Threat Name
Virus.OC
File Type
PE32 executatMe (console) intel 80386, for ms Windows

3 Collector
wet> collector
1^ Findon VirusTotal
Threat Name: Virus. DC
Threat Category: Virus □ Download Sample
Captured From: HTTP Traffic Q Download Behavior log
Source: 10.10.100.3 S Generate IVP
Source Address: 10.10.100.3(10.10.100.3) Q Add to Whitelist
Source URL: http//10.10.100.3/fakemalware. P Report False Positive

Alexa Rank--1
File Type: PE32 executable (console) Intel 80386, for MS Windows Screenshot
Golden Images:
File Site: 407,040 (398KB)
File Hashes: MDS: S40a69bf98Oba37a7fSdeS80f42b30a0
SHAl: 4dSe39cc99e444029a84fâ7a9935d346a770c
SHA25& a92c2a07b7dl2774d67600a96fd3333e9<e84txiee72d040f 1 b4fOf44cff4c527
Signed by: N/A
Malware Referrer URL: N/A
History
Analysis Timestamps: Jun S 2S 30 54 PacifK Daylight Time
Process graph
rrocess grapn
csrss.exe
]
Sample svnhost exe
isassexe
Malware Indicators
MalKious Trait Behavior Details
Anu Sandbox Checks the disk enum registry key for sandbox artifacts \REGlSTRY\MACHlNE\STSTEM\CootrolSet001\service5\0»sk\EnumV0"
\REGISTRY\MACHINE\SYSTEH\ContrOlSet001\servlces\0iSk\Enum
Checks the System BiOS/Processor registry key for sandbox artifacts \REGISTRy\MACHlNE\HAR0WARE\0ESCRIPTION\SystemV-SystemBiosVerswn-
Checks the OS product ID registry key for sandbox artifacts \REGISTRY\MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVerslon\*Productld*
Sleeps for an excessive amount of time n/a. mouse over for trace locations
Checks the registry to get a list of installed apps \REGISTRY\MACHINE\SOFTWARE\MicrosofC\Windows\CurTentVersion\UninstaII
Suspicious Processes Creates a spoofed system process svnhost exe

isass.exe
Creates a spoofed system process from a non-standard path C.\Users\John\AppOata\LocaI\Temp\csrss exe
Creates a process that runs in a suspicious path C:\Users\John\AppOata\Locat\Temp\csrss.exe

C \Users\John\AppOata\Local\Temp\svnhost exe
C:\User$\John\AppDdtd\Locai\Temp\isa$s.exe
Anti Debug Checks to see if a remote debugger is attached n/a, mouse over for trace locations
Outputs to debug port n/a. mouse over for trace locations
Checks to see if the Just In Time debugger is set (also known as post mortem debugger) \REGISTRY\MACHINE\SOFTWARE\Microsoft\WindowsNT\CurTenlVersion\AeOebug
Suspicious File Drops Creates a suspicious file C:\Users\John\AppOata\Local\Temp\csrss exe

C:\users\John\Appoatd\Locat\Temp\svnhosi.exe
C:\Users\John\AppOata\Local\Temp\isassexe
Suspicious File Accesses Opens a bait file C:\Users\John\Documents\fileacce5SpasswordS2ip

C:\users\John\Deskiop\fileaccess.pdSs words.2ip
C.\Users\John\Oocuments\userfiles docs zip
C:\Users\John\Desktop\userfiies.docs2ip
Suspicious Registry Accesses Accesses a suspicious registry key \REGlSTRY\MACHINE\HAROWARE\OESCRIPTION\SyStem
Suspicious Code Injection Behaviors Allocates committed memory with execute brt set • could be a process of injecting code 4096
Sets a page of memory to enable execution n/a. mouse over for trace locations
All Other File Drops Creates a new file C:\Users\John\AppData\Local\Temp\csrssexe

C:\Users\John\AppOa ta\Local\Temp\svnho$t exe
C:\Users\John\Appoaia\Locdr\Temp\isass.exe
Another Behaviors Allocates and commits memory n/a, mouse over for trace locations
www.juniper.net Juniper ATP On-Prem Lab 11-17

Additional Behavior Information
VM Network Callbxks: None
Memory Artifacts
Securrty Tools l>etecTed: firewall
control
security
IP Strings: None
Virtual Machines Detecte None

d:
URL Strings: None
Encryption Keys:
Step 3.7
From the JATP Web UI, click on the Mitigation tab, then click on the Hosts sub tab.
Verify that the 10.10.100.140 host is listed in the infected Hosts list, state of
Investigation should be Open.
ADVANCED THREAT PREVENTION APPLIANCE Refresh Data O System Health A J-ATP Admin
IP Filtering URL Filtering IPS Signatures Endpoint infection VerrfKation Emails Hosts
Infected Hosts
SMTrft All Zones Displaying Hosts with Threat Level at or above Threat Level 0.5
State of
Host IP Threat Level Threat First Seen Threat Last Seen Zone T
♦ CACHits Malware Hits Host Status Investigation MAC Address
♦
10 10.100140 0.5 2020-06-0603 39 54 024435*00 2020-06-07 23 03 09.772236*00 Default Zone 0 1 High threat level, recommend blocking host and investigating further Open
Step 3.8
Click on Open in the state of Investigation field for the new incident.
Change the Investigation Status value to Resolved - Ignored. Click Submit. Click OK to
confirm Added/updated item.
"Fn THREAT PRE*. ':NT''?\' \ Refresh Data O System Health A J-ATP Admin
■■ M?' 'Hn r.. . Ri
ir TNiiilag FWCMIbm Eatfx
All Zones • DoiayinetnsRwVi'nwatUwei at or abeae Threat Leal: 0.9
State of
HostlP Thrust Level Threat first Seen Threat Last Seen zone T C&CHits Malv.- ?HiU Host Status Investigation
iC iff itri II 0-5 2e2iMM617 QefaaMene 0 1 Hijh thnaMeveaaeeemmm^BQduBgâand invmgaxing further ■Mee- Rsrt
Host 10.10.100.140
irwesUgatlon Status: [Resolved • Ignored j
SutNnk Caral
Step 3.9
Click on the incidents tab.
In the incidents table, click on the New status field for the new incident. Set the Status field to
Complete and enter a comment of incident ignored. Click Submit. Click OK.

ADVA'.CLC THREAT PREVENTIO.\' ' \CE Refresh Data O System Health A J-ATP Admin
L.v. . Ri.
[ All Incidents (11 shown, 11 total) LH [m

Show Threat All Zones Last Month e Q
I I Incident ID I I CoHecXcrT;2.- T
SUIUS T t Risk I Thre«t
♦ P'.- ' T Threat Source I Threw Ifl.ge: T I Zone T OS Coilector Oate&Time ♦
I i: 13 100 140
HIGH DI Web 10 :0 10:1 3 •ouK Zone Wir’d.,. inl 63 web collector j- n < 16 v; Fj'-lic "aylight Time
Com^fste HIGH WrusUC DL IC 10 100 3 10 10 Tfrrjf: Default Zone Winde*»s MT 6 3 web collector Jun 7 IS 35 S3 Pacific Di,:;ght Time
Ce m^ m ii HIGH DL M.lO lOO I 10 lo.aaasBO oefauirTone wmtiowMiT $=3 wetMiieewr Jun«14 4»07Pa<jrn i,T ifle
Co^plMe 10 EICAR-TEST-SIGMATURE DL 213 211^58 10 lO 1«“4C lab unknoaB vW-1 Jun $ 14 43 sfLEanfiEBay^ght Time
DL 19W.100.3 10 10 100 140 Svfdull Zora wetMritmor Jun4i4 3Saaa<*(i«Aa3îigc^^ra
B ElCAR-TESSSKSiW DL I Report Jun 7,202016:03.-09 PscMc Daylight Time K wtaMiteetor ttPacific Dij'light Time
User Com ments for Virus. DC
Risk Level High
HIGH DL le tttRieeurrv.s weDeciiMwwi JWkA13 3517 EUi*K Deylig^t Time
Status: Complete
QCJriSBfifiSMlMUJJK DL u>eb coltector J**£fcS 12 34 #5 Patifti! Da,light Time
Comments: J—ei2 31 ^Pacific DeylightTiffi*

Coiraietf 5 Sui^leiMI.SSH HP LS le wirtinTlLi Tui
CBi'iiBlie 4 HIGH «muL DL Incident Ignored

iua>rart» We'D collector' Jun 810 3513 Pacific Daylight Time
Cem0ett 3 ElCtfVEST-SI&tOW&E DL ne Winflfi ri wub seiUector J^Â^s*^cific Daylight Time
Submit Cancel
âUtfftfVltnc nf
History
Jun 7.20201(03 29 P»(i6c 0«7l<gnt Tiine • Cyptwrt appliance mom b new (on«n«nt
Actions
Cve«t 101 was added w this incident
Taiget:
Zone Default 2cra 6 *

'-ND&CONTROL
O
e JtfTIONON
targets
Rfrishkif Cxpiflis I'Tt'-' I i|^ LuMem-Bules tinriLiUlnd

Incident Id
0 A A a
Part 4: Testing the Web Collector—Samba
In this lab part you will verify the function of the web collector in scanning SMB file transfers.
Step 4.1
Return to the virtual console connection to the WindowsClient device.
From the WindowsClient session, open the File Explorer. Expand This PC. Click on sambashare, and if
prompted, login with password laJbl23.
Recycle Bin
V I
Drive Tools sambashare <\\10.10.100.3) (Z:) I-1°[ X
□ I
Home Share View Manage
L
<- t > This PC ► sambashare (\\10.10.100.3)(Z:) V O Search sambashare (\\10.10.1... P
Firefox
Name Date modified Type Size
Favorites
■ Desktop □ 540a69bf980ba37a7f5de580f42b30a0 6/6/2020 9:43 AM File 398 K8
Downloads 11 eicar.txt 6/6/2020 12:33 PM Text Document 1 K8
Recent places 0 fakemalware.exe 6/6/2020 9:43 AM Application 398 KB
PuTTY * fakemalware.pdf 6/6/2020 12:41 PM Firefox HTML Doc... 398 KB

:■ This PC 11 fakemalware.txt 6/6/2020 12:41 PM Text Document 398 KB
> K Desktop Pl myfile 6/6/2020 9:40 AM File 0 KB
> Documents
Q > Ju Downloads
Q : i > Music
WinSCP
> Pictures
P ■ Videos
P jb l-ocal Disk (C;)
1
P sambashare <\\10-10.100.3) (Z:)
t> Network
6 items
Windows Server 2012 R2 Standard

Build 9600
4:32 PM
* <b ® b 6/7/2020
Step 4.2
The sambashare folder contains several simulated malware files. For this lab step, you will download the
eicar. txt file. Click and drag this file onto the desktop. Click ok on the Windows Security warning.

I
Recycle Bin
D X
4-1 D sambashare (\\10.10.1003) (Z:)
Home Share View e
T V This PC ► sambashare (\\10.10.100.3) (Z) Search sambashare (\\10.10.1... P
Firefox
'if Favorites Name Date modified Type Size
■ Desktop n 540a69bf980ba37a7f5deS80f42b30a0 9:43 AM File 398 KB

Ji Downloads PM Text Document 1 KB
Recent places Windows Security iM Application 398 KB
PuTTY I I ] These files might be harmful to your PM Firefox HTML Doc... 398 KB
:■ This PC PM Text Document 398 KB
computer
li Desktop kM File 0 KB
jl Documents Your Internet security settings suggest that one or more
files may be harmful. Do you want to use it anyway?
Ji Downloads
Music
WinSCP
Show details OK Cancel
Pictures
B Videos
How do I decide whether to unblock these files?
b Local Disk (C:)
sambashare (\\10.10.100,3) (Z;)
Network
6 items 1 item selected 69 bytes 3
Windows Server 2012 R2 Standard

Build 9600
,- ISI e 4:34 PM
6/7/2020
step 4.3
Return to the session opened to the Juniper ATP Web UI.
In the Juniper ATP Web UI, click on the incidents tab. Click Refresh Data to load the latest
incidents.
Examine the contents of the Incidents table.
Question: Is there a new event listed?
Answer: Yes. There should be an event listed with a Status of New,

Risk of Low, Collector Type of LAN, Threat Source of 10.10.100.3 and
Threat Target of 10.10.100.140.
Step 4.4
Summary tab.

f
Details for EICAR TEST- SIGNATURE
SUUKAftV
Progression:
Actions
Target:
Zone: Default Zone

OEUVERV
*
e A
COMMAND&CONTROL
* 0
WPs'^
Phishing Exploits Downloads Executions Infections Custom Rules Lateral Spread

Incident kJ. 14
0 0 1 0 0 0 0
Hostname
Triggers:
Username:
IP Address: 10.10.100.140 Staoc
FQDN 10.10.100 140
Source Email ID Custom Rules

Lateral Spread
Destination Email ID:
Infection
Execution
Risk: LOW Downloads
Exploit
Threat Category Suspicious
Phishing
Asset Value Medium I I
-oo
Relevance Max 01 Oi
lu"
Progression: Download
Protocol: SMB
OS Matched No
Summary Low Risk Threat downloaded EICAR-TEST-SIGNATURE
Collectors: webcoiieaof
Source: 10.10.100.3(10.10.100.3)
Golden lmap.es: nmc - fz
Step 4.5
Click the Downloads tab.
In the Downloads page, examine the details of the detected malware download.
When complete, close the new incident tab.
OMtil* for DCAR-TCSTSKNATURS
Smk*
SooOMy TnrwcNinio ’ Mo Typo
02$ eiOM.nsT.siiMA.TuRc ASCII txt •MOCOUOCDOr

ThroMltam* OCAA-TEST-SIGMATUliC ill firtaonMruoTMol
ThroMCMeory- SutplOM □ OownloMSwrvI*
Copturoo frodk WMOOM RU Ttwielor o AMWWNMM
Sour* 10101003 9 Rieon FMm Poaovo
10101003(1010100 Jl
SoxcoURL UOlO lOO.JjOfflootnoMOXoroc.

AiouRoM-l
ASCXMrt
GoUonimaeM
AtoSi» ({e.MMET)ip*nua
PikHMhM WS $0430M5T4«(<790230e091caM3auO
SNAL dlH»0<Mm07TTS«l(*c2w«a00S(M317c(2
91A2SC. Ulf»SeSlcc01»*(«blTS7f$«Md»»«»*oo«ff4«o3mT3MS)lboio82$7
SienMOy KA
History
AnHyU* TMtMUmpt Ji«i4323*r7^j$rCh^<>rramr
Additional Behavxx Information
Mttaor* InttcMorv
VMNoMorfcCtltoKlu. Nono
Ami Ooeu(pn(. Nono
Prooofoo* SpoKxofl. Nono
Mutton Nono
Ropttry MoWAcoMno Nono
ranOpcnott Nono
Step 4.6
In the Incidents table, click on the New status field for the eicar-test incident. Set the Status
field to Complete and enter a comment of incident ignored. Click Submit. Click OK.

ARV, ‘:CED THREAT PREVENTION APPL 'r Refresh Data

■ System Health >✓ A J-ATP Admin '
[-■i
f All Incidents (12 shown. 12 tota][

11 _LL
Show Threat All Zones Last Month • B
SU! IrKident IO Rfc- :r?at Pr;.; s- T Tbt at Source Tbf aiTz.r T Z“'- T OS CoLt'Uor Dete&Time
14 DL W19JM3 10 10m IIO 0eUuh29ne web cotMUbi ;uti T ifcw 'fiq t»ay<i?hsiime
HIGH DL TO IMO 3 10 IMMO Default Zone Wi«aiiiiiJn^3 W»B [fr.lggSgr Jun_LÔ* C
Coiwp*«w. tt HIGH viru««C QL 1010M3 10 10 >101110 oeUutt zone mntlows MT 6.3 web cotieetc? ftn < &a0'Ethafia&
Compttite U HIGH HL 1010100 3 10 IMOBB Default Zone Wine^vfcbT6 3 vsMfiMor Jua.£ 14 4$ •*? Panfic tla)<«fl*a irne
€efnpiet« M EKAR-TEST>»6tt»l«E QL 210 2111MS8 lO lO HOillO lae unknown vSRxn Jim 61 •-•?.: ri B>r<r
CrmpliTe EiC^ft-TtST.-SamiVRE QL 10 10 IM 3 loio.iaoM OeiMit Zone vsOBKfor JUQX14 3«:20 riiLTfll~njjli^wJ . ,
Reported Jun 7,202016:3437 PkIRc Oaylicht Time

e^mpMe 8 ElCAR-TEST-yacSmE QL user comments for EICAR-TEST-SIGNATURE Hl!Ui iiuiIUlIUI Jim 6 11 ir> -c Pirifi- Pniniitfinn
Risk level Lew
Cornptwe HIGH QL Will JWW-UT 8.3 •Htitatatetor Jtm ST?-J6:
Status: Complete «
Mptate € rriTTcrr^tfiWT^TiL QL weôilector Jun 612.34.0»fiKAc ^TjimiTnn
Comments:
Conpiete s Suspioom.SSH HP ts Jun 6 i2-n=wtf3;ifif Ddyugtaaitme
Incident ignored|
Corpfdaaa 4 fHIGH WUS=» QL uaibuwn wetocenector Jun C10 35'13 Panfig DaylijhlJIme
QettfS forSCAft-TESr-^GHATURE
SubfnK Cancel
SUM^^
History
Actions Jun *. 2010 }4 96-00 P*t if< Da/l-fnt r<in« ■ CypiMn AppMAcn mom • nnw eonwnnnt'
Tatgeti
UxtSe'il !SJ
Event 102 was added totals incident
I *eea
?. fONTROt
O
e
IMmmds "meamBulM ■ -^"Tf
Hwwiin'ie:
« 9 Q «
Jseer'iam*:
IPA^^'SSi i8,i0',mi,40-
Part 5: Testing the SSH Honeypot

In this lab part you will verify the functionality of the SSH honeypot feature by simulating a brute force SSH
root login attack on the honeypot interface
Step 5.1
Open an SSH session with the KaliPentester device.
From the CLI session with KaliPentester, execute a network mapping scan by executing nmap --top-ports
20 10.10.100.0/24
$ nmap —top-ports 20 10.10.100.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2020-06-07 17:11 PDT
Nmap scan report for 10.10.100.3
Host is up (0.0014s latency).
PORT STATE SERVICE

21/tcp closed ftp
22/tcp open ssh
23/tcp closed telnet
25/tcp closed smtp
53/tcp closed domain
80/tcp open http
110/tcp closed pop3
111/tcp closed rpcbind
135/tcp closed msrpc
139/tcp open netbios-ssn
143/tcp closed imap
443/tcp closed https
445/tcp open microsoft-ds
993/tcp closed imaps
995/tcp closed pop3s
1723/tcp closed pptp
3306/tcp closed mysql
3389/tcp closed ms-wbt-server
5900/tcp closed vnc

8080/tcp closed http-proxy
Nmap scan report for kali (10.10.100.6)

PORT STATE SERVICE

21/tcp closed ftp
22/tcp open ssh
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
139/tcp closed netbios-ssn
143/tcp closed imap
445/tcp closed microsoft-ds
5900/tcp closed vnc

PORT STATE SERVICE

21/tcp closed ftp
22/tcp open ssh
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
143/tcp closed imap
5900/tcp closed vnc


PORT STATE SERVICE

21/tcp closed ftp
22/tcp closed ssh
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
135/tcp open msrpc
143/tcp closed imap
3389/tcp open ms-wbt-server
5900/tcp closed vnc

PORT STATE SERVICE

21/tcp closed ftp
22/tcp closed ssh
25/tcp closed smtp
80/tcp closed http
110/tcp closed pop3
135/tcp open msrpc
143/tcp closed imap
3389/tcp open ms-wbt-server
5900/tcp closed vnc

PORT STATE SERVICE

21/tcp closed ftp
22/tcp open ssh
25/tcp closed smtp


80/tcp open http
110/tcp closed pop3
143/tcp closed imap
5900/tcp closed vnc
Nmap done: 256 IP addresses (6 hosts up) scanned in 10.74 seconds

$
Step 5.2
In the next several steps you will load the metasploit framework and execute a brute force attack to
determine the password for the root account on the 10.10.100.111 host.
From the CLI session, load the metasploit framework by issuing the msf console command.
$ msfconsole
+
I METASPLOIT by Rapid? I
+ +
n n If ff ff ff ff ff ff IT ff ff
==c ( (o ( ( 0 I
EXPLOIT
// W
// W ==[msf ]
// W
// RECON \\ \ (@) (@) (@) (@) (@) (@) (@) /
// W *********************
+ +
o 0 o \'\/\/\/'/
o 0 ) (
I I
o LOOT
I AAAAAAAAAAAAAA 11 _l l
ff ff
I PAYLOAD I f (_l l_
I I I) I I _l l_) I
I (@) (@) I(@)(@)** I (@)
II II II * * II
I I II
I I
+ +
=[ metasploit v4.16.48-dev ]
--=[ 1749 exploits - 1002 auxiliary - 302 post ]
—=[ 536 payloads - 40 encoders - 10 nops ]
--=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf
Step 5.3
From the metasploit console command line, load the ssh_login module by issuing the use
auxiliary/scanner/ssh/ssh_login command. Issue the options command to view available
options.
msf use auxiliary/scanner/ssh/ssh_login
msf auxiliary(scanner/ssh/ssh_login)
msf auxiliary(scanner/ssh/ssh login) options
Module options (auxiliary/scanner/ssh/ssh login):
Name Current Setting Required Description
BLANK_PASSWORDS false no Try blank passwords for all users

B RU T E FO RC E_S PEED 5 yes How fast to bruteforce, from 0 to 5
DB ALL CREDS false no Try each user/password couple stored
in the current database
DB ALL PASS false no Add all passwords in the current
database to the list
DB_ALL_USERS false no Add all users in the current database
to the list
PASSWORD no A specific password to authenticate
with
PASS_FILE no File containing passwords, one per
line
RHOSTS yes The target address range or CIDR
identifier
RPORT 22 yes The target port
STOP_ON_SUCCESS false yes Stop guessing when a credential works
for a host
THREADS 1 yes The number of concurrent threads
USERNAME no A specific username to authenticate as
USERPASS FILE no File containing users and passwords
separated by space, one pair per line
USER_AS_PASS no Try the username as the password for
all users
USER_FILE no File containing usernames. one per
line
VERBOSE false yes Whether to print output for all
attempts
Step 5.4
Configure the ssh_login module with the following settings:
rhosts: 10.10.100.111
stop_on_success: true
pass_file: passwords. txt
username: root
verbose: true
msf auxiliary(scanner/ssh/ssh login) set rhosts 10.10.100.111
rhosts 10.10.100.111

msf auxiliary(scanner/ssh/ssh login) set stop_on_success true

stop on success true
msf auxiliary(scanner/ssh/ssh login) set pass_file passwords.txt
pass file = passwords.txt
msf auxiliary(scanner/ssh/ssh login) set username root
username root
msf auxiliary(scanner/ssh/ssh login) set verbose true
verbose true
msf auxiliary(scanner/ssh/ssh login)
Step 5.5
Initiate the brute force login attack by issuing the run command.
msf auxiliary(scanner/ssh/ssh login) run
[-] 10.10.100.111:22 Failed: I root:awlkndal23 I

[!] No active DB -- Credential data will not be saved!
[-] 10.10.100.111:22 Failed: I root daqwdlnlkl2nl I
[-] 10.10.100.111:22 Failed: I root wdlkanw3431’
[-] 10.10.100.111:22 Failed: I root sldkqal’
[-] 10.10.100.111:22 Failed: I root wdlkn I
[-] 10.10.100.111:22 Failed: I root aerl ’
[-] 10.10.100.111:22 Failed: I root 415f'
[-] 10.10.100.111:22 Failed: I root acqwx I
[-] 10.10.100.111:22 Failed: I root 324twf'
[-] 10.10.100.111:22 Failed: I root c23rcawC I
[-] 10.10.100.111:22 Failed: I root 23F32DAA I
[-] 10.10.100.111:22 Failed: I root s23ry34ewf I
[-] 10.10.100.111:22 Failed: I root 324f2fy4653twes'
[-] 10.10.100.111:22 Failed: I root 42r2wfe’
[-] 10.10.100.111:22 Failed: I root 234wf32'
[-] 10.10.100.111:22 Failed: I root 3e24fc23f I
[-] 10.10.100.111:22 Failed: I root 23d23rc232'
[-] 10.10.100.111:22 Failed: I root 45635hb4bv3'
[-] 10.10.100.111:22 Failed: I root 34t343'
[-] 10.10.100.111:22 Failed: I root 43t34g3g I
[-] 10.10.100.111:22 Failed: I root gdfwd I
[-] 10.10.100.111:22 Failed: I root dfwwevw345t’
[-] 10.10.100.111:22 Failed: I root grvrewv’
[-] 10.10.100.111:22 Failed: I root 3gf34ge’
[-] 10.10.100.111:22 Failed: I root 345yvvdsv I
[-] 10.10.100.111:22 Failed: I root 34ge3efr I
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(scanner/ssh/ssh login) >
step 5.6
Return to the browser open to the Juniper ATP Web UI. If necessary, login with username admin and
password Juniper 123
From the WebUI browser session, click on the incidents tab. Click Refresh Data and examine the
incidents table and verify that a new incident has been recorded.

ADVANCED THREAT PREVENTION APPLIANCE Refresh Data O System Health lA J-ATP Admin
Dashboard Incicients File Uploads Mitigation Reports Custom Rules Config
All Incidents <13 shown. 13 total)
Search: Show Threat d All Zones e Last Month t 0
Status T ♦ Incident ID *1 Risk

♦ Threat I Progression T 0 Collector Type T Threat Source I Threat Target T Zone T Target OS 0 I Collector Date & Time ♦
New 15 MED SuSpKIOuS.SSH.HP LS HFlan'^^^^HI ATP-coil-ssh-honeypot 10.10.100.6 DefauttZone web cotlector Jun 71721:01 Pacific Daylight Time
CO 1010 100 3 1010 100 140 Default Zone web collector Jun 7 16 34'37 Pacific Daylight Time
Complete 13 HIGH Virus.DC DL 10.10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 71603:09 Pacific Daylight Time
Complete 12 HIGH Virus DC DL 1010 100 3 10.10100 140 Default Zone Windows NT 6 3 web collector Jun 7 13'35:53 Pacific Daylight Time
Complete 11 HIGH Virus.DC DL 10.10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 614:49:07 Pacific Daylight Time
Complete 10 EICAR-TEST-SIGNATURE DL 213 211 198 58 10.10100.140 lab unknown vSRX-1 Jun 6 14 43:56 Pacific Daylight Time
Complete 9 EICAR-TEST-SIGNATURE DL 10.10.100.3 10.10.100.140 Default Zone web collector Jun 614:36:20 Pacific Daylight Time
Complete 8 EICAR-TEST-SIGNATURE DL 23 10.10.100.3 10.10.100.140 Default Zone web collector Jun 614'20:06 Pacific Daylight Time
Complete 7 HIGH Virus.DC DL 23 10.10.100.3 10.10.100.140 Default Zone Windows NT 6.3 web collector Jun 613 36:17 Pacific Daylight Time
Complete 6 EICAR-TEST-SIGNATURE DL BJ3 10.10.100.3 10.10.100.4 Default Zone web collector Jun 6 12'34:05 Pacific Daylight Time
Complete 5 Suspicious_SSH.HP LS 23 web-collector-ssh-honeypot 10.10.100 6 Default Zone web collector Jun 612 31:00 Pacific Daylight Time
Details for Suspicious.SSH.HP
SUMMARY lATEP'. —•
Target: Progression:
Zone Default Zone DELIVERY

e eXf^lTATION &
INSTALLATION COMMAND! CONTROL
e
Incident Id 15 b If A * d
Hostname Phishing Exploits Executions Infections Custom Rules Lateral Spread
0 0 0 0 0 26
Username:
IP Address: 10.10 100.6 Triggers:
FQON 10.10 100 6

Network
Source Email ID
Destination Email ID: Custom Rules ■

Lateral Spread *
oo
Risk: Medium Infeaion *
Execution >
Threat Category. suspicious
Downloads >
Asset Value Medium _gutQi^
Question: Is there a new incident listed?
Answer: Yes, there should be a new incident with Status of New, Risk
of Med, Threat of Suspicious_SSH.HP, Collector Type of LAN, Threat
Source of ATP-Coll-ssh-honeypot and Threat Target of 10.10.100.6.
Step 5.7
Summary tab. When complete, close the new incident browser tab.
Deuils for Susplcious.SSH.HP
SUMMARY LATr— *■' so
Target: Progression:
Zone:
Incident id:
Default zone
15 tf
DELIVERY
e e COMMAND&CONTROL
If A 9
Phishing Exploits Executions Infections Custom Rules Lateral Spread
Hostname
0 0 0 0 0 26
Username:
iPAddress: 10.10.100.6 Triggers:
FQDN: 10.10.100.6 Netvrork
Source Email ID
Destination Email ID- Custom Rules OO

Lateral Spread
Risk: Medium Infection
Execution
Threat Category. suspicious
Downloads
Asset Value Medium
Exploit
Relevance: Max Phishing
T T T T T 1
Progression: Lateral Spread
01 J..”"
Protocol SSH joO luo' JU’''01
OS Matched No
Summary: Medium Risk Threat: SSH session attempted from target h

ost to Cyphort SSH Honeypot
Collectors: web collector
Source. ATP-Coll-ssh-honeypot (10.10 lOO.lllJ
Golden Images: mwconhcurwi

Step 5.8
In the Incidents table, click on the New status field for the new incident. Set the Status field to
Complete and enter a comment of incident ignored. Click Submit. Click OK.
ADVANCED THREAT PREVENTION .APPLIANCE Refresh Data O System Health A J-ATP Admin '
: id Incidents iS Rcy/vi • Custom Rules
_ All Incidents (13 shown, 13 total)
Swck Show Threat All Zones Last Month « S9

Status T I Incident ID
« Risk I Threat I I Progression
1
t f Collector Type T | IhreatSource I Threat Target T f I Zone T I Target OS I Collector Date A Time
1^
Coni^btt 14
Miu <
EICAR-TE$T-Sl&hiATURE DL
■'J
W.IO 1003 10.10 100.140

.iVj'lt' -.'Ik.
OefatitZoi^
(eb collector
wee<ix:e:tcr
Jun 717 21 01 Pacific Daylight Time
Jun 716 34 37 Pxific Daylight T:m«
Cors^lotfr Thigh MrusOC DL 10 100 3 :c 10100140 Default Zone WineeneWT 6 3 kseb collector Jun 716'5 WPacifi; Oa>1ight Tine
Caripim 12 Thigh Virus.OC DL 10.10 100.3 lv.10.100.14C Default Zone winoes^T 6 3 web co.:ector Jur. ’ 13:35 53Pxtfic OaylightTime
GMVîace 11 HIGH DL 10 100 3 IC 10 ICO 14C Default Zone WinOovrS-fft^ web-collector Jur 614 49 OTP.v ific Oa-, light T;r-ie
10 EICAR-TEST>£ieaUimRE DL 213211194 5$ 10 10.100.140 lab vSRX-l Jon 6 14:43:56 Pacific Daylight T-me
R«0on»d Jun 7.20201741-01 Paciftc Daylight Time

teoptete 9 Eh iil'l ll‘,1 lIMJurC CL User Comments for Suspicious_$$H.HP webcohector ?un 614 36 23 Pacific Daylight T me
Risk Level Medium
Complete 8 EICAR-TEST-SIGNATURE DL s web collector Jun 614:20 06 Pacific Daylight T:fne

Status: Complete
Cerp^te 7 high i*B*ec QL Windows UT-6 3 web collector Jun 613 3447 Pacific Da,ii41iLJ’'*e
Comments:
Complete 6 EICAR-TEST-SIGNATURE DL e web collector Jun 612 34 05 Pac fic Daylight Time
Incident Ignored
Cempieie 5 TuepieioijfaSSH HP TS web collector Jun 612 3100 Pacific Oa,night T rme
Details for Suspicious.SSH.KP

Submit Cancel
iriCT
History
Targp**-
Jon 7.20201* 21.05 bajlignt Tinx • Cyphon AeeKance mom « "♦« cenme*
hEldMKM:
BeSiutsMti
15
Event 120 was aOOeO to tnis incident
1
e
Jun 20201T2L0* Aacific b»,ign: Turw - Cyphort Applunn iootc a naw convnant.
Rules Ldioial Spread
na'Jname
Event 117 was added to this incident
jsemanre
Jun T.2020 }71t-0«Paci6( Oaihpn ri->M ■ CypMnAppttanca aooM a new comment
iPAeeress- 1O103M£
Event )2S was added to this incident
ISJA.1W6
Jun *. 20201* iLOa Eeci^ bejlgnt Time • Cyphen Aeptiance eooM » new commex
DesUnlian £iiwil Q.
Jun 7.20201741:01 Aacific Oeitpnriine ■ CyphortApplianca aooM a new comment

©o
RiSM' WedtuRi
*«rMiC-tgary:
Step 5.9
Exit out of the Juniper ATP Web GUI, the Juniper ATP Collector CLI, the WindowsClient, and the
KaliPentester.


vSRX-1 52S
ATP Cloud
Physical
vSRX-VR SiS 172.25.11.254
Internet
VNC Connections
Junos
Space
Policy
Hypervisor
vSRX-2 172.25.11.2
Virtual Switch
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
Gateway 172.25.11.254

jumper
Nf'ACKXS
Lab Network Diagram: Juniper ATP On-Prem

Internet
untrust zone
ge-0/0/1
vSRX-1
ATP Appliance
loO: 192.168.1.1
(•120)
(.1) ge-0/0/3
172.25.11.0/24
10.11.10.0/24
clientszone
(.2) xe-0/0/1
(.121) ethO
vQFX-1 xe-0/0/3 (SPAN) eth2
Web Collector
irb.lO
(.1) eth3
(.100)
xe-0/0/2 (HONEYPOT)
VLAN 10
10.10.100.0/24
(.140) (.3) (.6)
WindowsClient LinuxClient KaliPentester

jumper
Np.'ACKXS

Lab
Juniper Connected Security—Automated Threat Remediation
Overview
In this lab, you will configure and deploy a secure network configuration using the ATP Cloud to scan for
malware threats. You will then simulate the actions of infected and compromised hosts and demonstrate
the automated isolation features of Juniper Connected security.
• Configure and threat prevention policy with AAMW and C«&C profile.
• Simulate a host downloading a malware file.
• Simulate a host attempting to contact a known C«&C server.
• Monitor the effects of malware detection and compromised host isolation.
www.juniper.net Juniper Connected Security—Automated Threat Remediation • Lab 12-1

Part 1: Setting up the Environment

In this lab part, you will use the Junos command line interface (CLI) and Security Directory GUI to
configured and discover the SRX devices and import existing policy configurations.
Note
step 1.1
You will primarily configure the vSRX-1 and vQFX-1 devices. You will also load baseline configurations on
vSRX-2 and vSRX-VR. Consult the Management Network Diagram to determine the management
addresses of your devices.

devices?

Step 1.2
On the vSRX-1 device, log in with the username lab and password labl23. Enter configuration mode
and load the labl 3-s tart, config trom the a j s e c directory. Commit the configuration when
login: lab
Password:

[edit]
lab@vSRX-l# load override ajsec/labl3-start.config
[edit]
commit complete
lab@vSRX-l>
Lab 12-2 • Juniper Connected Security—Automated Threat Remediation www.juniper.net

Step 1.3
and load the reset configuration file using the load override ajsec/lablS-start. config
login: lab
Password:

[edit]
lab@vSRX-2# load override ajsec/labl3-start.config
[edit]
lab@vSRX-2# commit
commit complete
[edit]
lab@vSRX-2#
Step 1.4
and load the reset configuration file using the load override a jsec/labl3-start. config
login: lab
Password:

[edit]
lab@vSRX-VR# load override ajsec/lablS-start.config
[edit]
lab@vSRX-VR# commit
commit complete
[edit]
lab@vSRX-VR#

Step 1.5
Open a console session to the student desktop and open a Web browser, then navigate to the web
management IP address for Junos Space Security Director.
From the web browser, login with the username of super and the password of Junlp3rl231.
Step 1.6
Mouse over the blue navigation bar on the left to expand it. Click on Devices->Device Discovery.
nX
Devices / Device Discovery
Device Discovery®
Q Global a s ?
Security Devices
Device Discovery
Q
Secure Fabric 1 selected Clone
I Run Now
J More + / 0 q Y :
NSX Managers
vCenter Servers
□ Device Discovery Profile Target Type Target Details Probes Username Credential T... Schedule Recurrence
ea AJEC-DEViCES IP Range 172.25.11.V172.25.11.2 N/A lab Credential Ba- Thu, 20 Jun 2030 20:12:33 POT
□ vQFX IP Address 172.25.11.10 N/A lab Credential Ba... Sat. 06 Jun 2020 13:49:19 POT
■BB
2 items
Step 1.7
In the Device Discovery dialog, select the ajsec-devices discovery job. Click Run Now.
Global V C s
Devices / Device Discovery Q 9
X Security Devices
Device Discovery®
Device Discovery
Secure Fabric 2 selec Muti © Q Y :

□ NSX Managers Job Details:Discover Network Elements
vCenter Servers
□ lob ID 229656 Scheduled Start Ti... Sun, 07 Jun 2020 18:18:46 PDT
■liule Recurrence
sc
□ lob Name Discover Network Elements-229656 Actual Start Time Sun, 07 Jun 2020 18:18:46 PDT
«l20Jun 2030 20:12:33 POT
□ |ob State
& Success
End Time Sun, 07 Jun 2020 18:19X>5 PDT II. 06 Jun 2020 13:49:19 PDT
■n
Owner super
2 items
172.25.11.1 vSRX-1 Device Managed Device discovered successfully
172.25.11.2 vSRX-2 Device Managed Device discovered successfully
2 Rows
OK
Answer: The vSRX-1 and vSRX-2 devices should be discovered

successfully. If any device was not discovered successfully, please
inform your instructor.
Step 1.8
In the Device Discovery dialog, select the vQFX discovery job. Click Run Now.

Devices / Device Discovery q Global a s ?
X Security Devices
Device Discovery®
Device Discovery
Secure Fabric 1 selected Clone Run Now
] More V + z © q ¥ ;
NSX Managers
vCenter Servers
□ Device Discovery Profile Target Type Target Details Probes Username Credential T... Schedule Recurrence
SC
□ AJEC-OEViCeS IP Range 172.25.11.1-172.25.11.2 N/A lab Credential 6a... Thu, 20 Jun 2030 20:12:33 POT
□ vQRC IP Address 172.25.11.10 N/A lab Credential Ba... sat, oejun 2020 13:49:19 PDT
2 items
« Devices ! Device Discovery q Global V a s

X Security Devices
Device Discovery®
Device Discovery
Secure Fabric q ¥ :
NSX Managers Job Details:Discover Network Elements
vCenter Servers
□ lob ID 229659 Scheduled Start Ti... Sun, 07 Jun 2020 18:20:49 PDT
Zhedule Recurrence
sc
□ Job Name Discover Network Elements-229659 ACTual Start Time Sun, 07 Jun 2020 18:20:49 POT
tu, 20Jun 2030 20:12:33 PDT
(il
□ Job State
0 Success
End Time Sun, 07 Jun 2020 18:21:11 POT n, 06 Jun 2020 13:49:19 POT
I I
Owner super
2 items
(3 :
172.25.11.10 vQFX-1 Device Managed Device discovered successfully
1 Rows
OK
Answer: The vQFX-1 device should be discovered successfully. If any

device was not discovered successfully, please inform your instructor.
Step 1.9
Mouse over the blue navigation bar on the left to expand it.
Navigate to Devices->Security Devices. Check the boxes next to vSRX-1 and vSRX-2. Right
click on any device name and select import from the drop-down list.

♦ Devices t Security Devices Q Global a s ?
X Security Devices
Security Devices ©
Device Discovery
Secure Fabric 2 selected Update Changes

Resynchfonue with Network ]
More 3 Q Y :
□ NSX Managers
vCenier Servers Q Device Name ▼ IP Address OS Version CPU Storage Connection Status Feed Source Feed Source Status Managed Status
Q > vSRX-2 172.25.11.2 20.1R1.11 ▲ up Not Registered Managed
Configuration
Q vSRX-1 20.1 RI .11 A up Not Registered Managed
s Operations
View inventory Details
Update Changes
Upload Keys
Import
Refresh Certificate
Acknowledge Device Fingerprint
Step 1.10
Check the boxes next to all Firewall and nat policies and click Next.
Devices / Security Devices Q Global

C (5 s ?
X Security Devices Import Configuration ©

Device Discovery
Secure Fabric Managed Services mze with Network

[ More Q Y :
S NSX Managers
vCenter Servers O For devices with Junos OS Release 18.2 and later, IPS policy is auto imported along with the assigned Arewall Policy. Feed Source Status Managed Status
For devices with Junos OS Release 18.2 and later. Deprecated AppFw configuration will rx>tbe imported.
hot Registered Managed
3 selected
Wot Registered Managed
Q Name Rules Errors Summary

1 Display 50 V
Firewall Policy
Q vSRX-1 3 0
Q vSRX-2 4 0
NAT Policy
D vSRX-1 1 0
3 items
Cancel Next F
Step 1.11
In the Conflict Resolution dialog, click Finish.
Lab 12-6 Juniper Connected Security—Automated Threat Remediation www.juniper.net

Devices / Security Devices Q Global O s ?
X Security Devices Import Configuration ©

Device Discovery
o---
Secure Fabric ‘.'a-agec S«r,-:es Conflict Resolution >0126 witr> Network More Q V :
NSX Managers
vCenter Servers Feed Source Status Managed Status
Rrn.iw Overwrite witb Imported Vjlue Keep I »i‘,Ting Object Q 7 Not Registered “ Managed
Not Registered Managed
■i o Object Name Object Type Value Imported Value Conflict Resolution New Object Name Domain ►
1 Display 50 V
No Conflicts to Show
Cancel Back Finish
Step 1.12
In the Summary page, click ok.
Devices y Security Devices q Global s 7
Security Devices Import Configuration ©

Device Discovery
Secure Fabric Summary
t' Lrsumrrary of<''

Juzewitb Network
1 More q V ;
NSX Managers
vCenter Servers Managed Services feed Source Status Managed Status

Rrewall Policy,Firewall Policy,NAT Policy Edit
Firewall Policy Rules 4 Not Registered Managed
Firewall Policy Rules 3

Not Registered ri Managed
NAT Policy Rules 1
B
Error Summary 0 1 Display 50 V
Object Conflicts 0
Object Creation list 0
Object Modification list 0
Report SummaryReport.zip
Click OK to con-e'ete
Cancel Back OK
Question: What is the result of the Import job?
Answer: The job should complete successfully. If it did not, consult

your instructor.
www.juniper.net Juniper Connected Security—Automated Threat Remediation Lab 12-7

Step 1.13
Navigate to Administration->Policy Enforcer->Settings.
Consult the management diagram and configure the Policy Enforcer connection with the following
settings:
IP Address: 172.25.11.101
Username: root
Password: Junlp3rl23!
Sky ATP Configuration Type: Sky ATP/JATP with Juniper Connected Security
Leave all other settings at default. Click ok.
♦ Administrition / Policy Enforcer / Settings Q Global

C 1^ s
X My Profile Settings ®
Users & Roles >
6^
Logging Management > O The Policy Enforcer space API user (pe.user) password is currently valid, it will expire on 2020-09-02.
S Monitor Settings
The Policy Enforcer is active.
Signature Database
It is configured with version 19.4R1-975.
License Management >
Policy Enforcer
IP Address* 172.25.11.101
Settings
Conneaors Username © root
NSM Migration Password*
Policy Sync Settings Sky ATP Configuration Ty... © Sky ATP/JATP with Juniper Connected Security v
Configure polling timers to discover hosts in your network
Poll Network wide endpo... * © 24 hours
Poll Site wide endpoints* © 5 mins
OK Reset
Policy Enforcer Logs Download
Question: What is the result of the Policy Enforcer configuration?
Answer: The Settings page should display "The Policy Enforcer is

active.”
Part 2: Configure the Secure Fabric

In this lab part, you will configure the fabric, including the vQFX-1, SRX-1 and vSRX-2 devices. You will also
define a secure fabric object containing all 3 devices, a threat prevention policy and a policy enforcement
group.
Step 2.1
From the Security Director Web UI, navigate to Conf igure->Guided Setup->Threat
Prevention.
Click start Setup.

a s
♦ Configure / Gutded Setup ! Threat Prevention Q Global
X Firewall Policy
Threat Prevention Policy Setup ®
Standard Policies
Interested in creating Advanced Threat

unified Policies
IVevention (ATP) policies for groups of Secure Network Fabric
Devices
S Policy Enforcement (PE) allows you to create
Schedules
threat prevention policies, such as blocking
infected hosts ana matware, and apply them to
CT Profiles groups of IPs, rather than devices. Support for
threat prevention, monitoring, and remediation
I
Templates for infected hosts is present For both Juniper Router
Site
switches and third party switches. X
Environment
The system is configured for Sky ATP with juniper Threat Feed
Connected Security mode. In this mode, the Firewall
User Firewall Management > following features are available:
T
Sky ATP
Spotlight
1
Application Firewall Policy > 1. Secure Fabric
r Third Party
2. Policy Enforcement Group Switches

SSL Profiles > 3. Sky ATP Realm
IPS Policy > 4. Threat policies for the following threat types
a) C&C Server (Command and Control
NAT Policy > Server)
Juniper Swnche* I nrd Party Swecnet
UTM Policy > b) Infected Hosts
Policy Enforcement Group
c) Malware
1
Threat Prevention
IPSec VPN
>
>
d) Geo IP
□ □
Shared Objects > Start Setup
J
Change Management >
Guided Setup
Threat Prevention
Step 2.2
In the Secure Fabric dialog, click + to create a new secure fabric object.
In the Create Site dialog, configure a name of a j sec-lab. Click OK.
Threat Prevention Policy Setup ©
Secure Fabric
Siti
Create Site ©
□ Ml...
Site* ajsec-lab
Nod
Description Write description..
Cancel OK
Cancel Next
Step 2.3
In the Secure Fabric dialog, click Add Enforcement Points.
Check the boxes for all devices. Click the arrow icon to select the devices. Click ok. Click Next.

Secure Fabric
Add Enforcement Points @
Assigning a device to the site will cause a change in the device configuration.
Specify the enforcement points to assign to the site. The site cannot contain both switches and connectors.
Enforcement Points 0 Available q : 3 Selected q :

□ Name IP Model □ Name IP Model
□ vSRX-1 172.25.11.1 VSRX
□ vSRX-2 172.25.11.2 VSRX
No available items □ vQFX-1 172.25.11.10 VQFX-10000
Perimeter Device ® «vSRX-l «vSRX-2
Cancel OK
Cancel Next
Step 2.4
In the Policy Enforcement Groups dialog, click + to create a Policy Enforcement Group object.
Name the PEG a j sec-group. Check the boxes for all subnets, except for 172.25.11.1/24,
172.25.11.2/24 and 172.25.11.9/24. Click the arrow button to select these subnets. Click ok. Click
Next.
Policy Enforcement Group ©
Name* isec-group
Description
Group Type ®
Connector IPs/subnets 3 Available q : 17 Selected q ;

□ Subnets Source Model □ Subnets Source Model
□ 172.25.11.2/24 vSRX-2 space □ 10.25.0.2/24 vSRX-2 space
□ 172.25.11.9/24 vSRX-VR space □ 172.18.2.1/30 vSRX-VR space
□ 172.25.11.1/24 vSRX-1 Space □ 10.10.101.1/24 vSRX-1 space
□ 10.10.202.10/24 vSRX-VR Space
□ 10.10.201.10/24 vSRX-VR Space
Refresh Available subnets
Additional IP © Space V Add
Cancel OK
1
Cancel Back Next
Step 2.5
In the Sky ATP Realm dialog, click the + icon to create a new Sky atp realm.
Enter the SkyATP Realm credentials provided by your instructor. Click ok.

Threat Prevention Policy Setup®

o--
Sec-re Fab’x
c-
Pol'cy ■xer-e-: Gro-ps Sky ATP Realm
Sky ATP Realm © I +

□ Realm
Sky ATP realm credentials
Feed Status
Pc, ..
0 items O
Location* North Amerka v
Username studentS»juniper.net
Password
Realm O xxxxxxxj
No Sky ATP account? Select your region using the Location in the menu above, then click here to create an account.
You will be redirected to the Sky ATP account page.
Cancel OK
Cancel Back Next
Step 2.6
In the Sky ATP Realm dialog, click Assign Sites. In the Site dialog, select the a jsec-lab site.
Click OK. Click Next.

o—
S«c-fe âfcnc
o
Pole/ «r: GÔ-CS Sky ATP Realm
Sky ATP Realms ©
□ O Assigning a site to the realm will cause a change in the device configuration in the associated devices.
oaded
□
1 itel
Site
ajsec-realm-1
Cboote sites to be enrolled uno the realm
Site >ajsec-lab Create new site
Cancel OK
Cancel Back Next
Step 2.7
In the Policies dialog, click + to create a new Threat Prevention Policy.
In the Create Threat Prevention Policy dialog, set a name of a j sec-tpp. Check the box for
Include C&C profile in policy. Leave Threat Score and Actions at default settings.
Check the Include infected hosts profile in policy box. Leave Actions at default
setting.

Check the box for Include malware profile in policy. Select the SkyATP Feed Type.
Enable HTTP File Download and in Device Prof ile expand ajsec-realm-l and check the
default profile box.
Leave all other settings at their default values and click ok.
Create Threat Prevention Policy®
Name* © ajsec-tpp
Description
Profiles
Q include C&C profile In policy
SHect the threat sccre »a**gesto appty v.+ien men try to access a C&C ?e'vpr
5 8
Threat Score
4 E
■■ Permit I «4 ■■ MonitorS-T " BtoCkB-lO
Actions Drop connection silently (recommended) v
Q include infected host profile in policy

.elect.*, action to appfy to infected hosts.
Actions Drop connection silently v
Q Include mahvare profile in policy
Feed Type* O lATP

(g) SkyATP
HTTP File Download ®
Select a file scanning device profile and threat score range to appy to HTTP and HTTPS traffic
Scan HTTPS O
o
Device Profile
1 selected
Q Realm Name File Categories
'*'ajsec-realm-i
a default_profi1e Document (32 MB) +3
1 items
Actions Drop connection silently V
SMTP Attachments ®
IMAP Attachments ®
O Include DOoS profile in policy
Log Setting ® Log all traffic
Cancel OK
Step 2.8
Click the Assign to Groups link.
Check the box for a j sec-group and click the arrow icon to select the group. Click ok.
View the Change List and click Update.
Wait until the Job Status Job State shows Success. Click OK. Click Next.


o--
Se:_'e Pacnc
o-----
Policy Erferce~e~: Gro.<os
o--Siey ATP Realm
o—
Pol'Ces Geo IP
Assign to Policy Enforcement Groups ®
□ Name
Select c-e ; ef ;c>iient g'* -e
□ DPRK
1 seieaed
Policy Enforcement Groups 0 Available q Q
1 items O
□ Groups
□ Groups
□ ajsec-group
No available items
Cancel
Cancel Back Finish
Thre^^ PrAvontinn Pnlirv ôfiin

View Change ListO
Sec-re Fi
' le ze eoitec after anaf'i;-?- Ck:^- • /ev.' these cha'?-
Seq. Name Changed Rules Summary Devices Domain
> POLICIES APPLIED BEFORE DEVICE SPECIFIC POLICIES' (0 policy)
□ V DEVICE SPECIFIC POLICIES (2 policies)

I
□ Global
vSRX-2 S Rules Added vSRX-2
1 itei
4 Rules Added Global
vSRX-1 vSRX-l
> POLICIES APPLIED AFTER DEVICE SPECIFIC POLICIES' (0 policy)
2 Rows
Cancel Update
Cancel Back Next

Thre Job Status®
♦
229665 229666 229667
@ @
o
□ Job Type:
Job ID:
Update Devices
229667
Job State:
Percent Complete:
Success
100%
n
□ Job Name:
User:
Update Devices-229667
super
Scheduled Start Time:
Actual Start Time:
Sun. 07 Jun 2020 18:46:51 POT
Sun. 07 Jun 2020 18:46:51 POT
End Time: Sun. 07 Jun 2020 18:47:01 POT
1 iten
Export to csv Q 7
vSRX-1 (vSRX-l) Success vSRX-1 (FWPolicyl View View Sun. 07 Jun 2020 18:46:S6 PST
vSRX-2 (vSRX-2) Success vSRX-2 (FWPolicyJ View View Sun, 07 Jun 2020 18:46:56 PST
2 Rows
Cancel OK Next
Step 2.9
In the Geo IP dialog, click + to create a Geo IP address group.
Assign a name of dprk. Check the box for Korea, Democratic People's Republic of and
click the arrow button to select. Leave all other settings at default and click OK.
Create GeoIP®
Name* ® DPRK
Deunpoon
Countries 242 Available Q 1 Selected Q

Country Country
u Jordan
Korea. Democraoc People’S Republic of
I Kazakhstan
Kenya
LJ Ktnbaci
U Korea. Republic of
Block Traffic incoming traffic v
Cancel nK
Step 2.10
Click Assign to Groups.
Check the box for a j sec-group and click the arrow icon to select the group. Click ok.
View the change List and click Update.

Wait until the Job Status Job State shows Success. Click ok.

Assign to Policy Enforcement Groups ©
to !•
Policy Enforcement Groups 0 Available Q 1 Selected Q

Q Groups Q Groups
□ ajseC'group
No available items
Cancel OK
View Change List®
; tc . se
Seq. Name Changed Rules Summary Devices Domain
> POLICIES APPLIED BEFORE 'DEVICE SPECIFIC POLICIES' (0 policy)
V/ DEVICE SPECIFIC POLICIES (2 policies)
vSRX-2 5 Rules Added vSRX-2 Global
vSRX-1 4 Rules Added vSRX-1 Global
> POLICIES APPLIED AFTER DEVICE SPECIFIC POLICIES' (0 policy)
2 Rows
Cancel Update
Job Status ®
f 2 }
♦
327734 327735 327736
© ® ®
Job Type: Update Devices Job State: Success ©

Job ID: 327736 Percent Complete: 100%
Job Name: Update Devices-327736 Scheduled Start Time: Tue. 07 Jul 2020 19:34:18 UTC
User: super Actual Start Time: Tue. 07 Jul 2020 19:34:18 UTC
End Time: Tue. 07 Jul 2020 19:34:23 UTC
Export to CSV Q Y
vSRX-2 (vSRX-2) Success vSRX-2 [FWPolicy] View View Tue, 07 Jul 2020 19:34:22 CUT
vSRX-1 (vSRX-1) Success vSRX-1 (FWPolicy] View View Tue. 07 Jul 2020 19:34:22 CUT
2 Rows
1 OK

Step 2.11
Click Finish. Review the configurations and click ok.

Summary
Number of sites 1 (ajsec-lab)edit
Number of policy enforce... 1 (ajsec-groop)gdit
Number of Sky ATP realms 1 (ajsec-realm-l)Edrt
Number of threat preven... 1 (ajsec-tpp)Edit
Number of geo IP policies 1 (OPRK)Edit
Citck OK to con-pie:e
Cancel Back OK
Step 2.12
Navigate to Devices->Secure Fabric.
Expand the row for ajsec-lab and verify that Feed Source shows Success for both vSRX-1 and
vSRX-2.
Secure Fabric®
Sites + /
□ Site Enforcement... IP Model Feed Source Feed Source Status Last U... Des...
Q ’ ajsec-lab
vSRX-2 172.25.11.2 VSftX skyatp ^Success July 07,...
vSRX-1 172.25.11.1 VSRX Success
172.25.11.10 VQFX-10000
vQFX-1
1 items C
Part 3: Creating Security Policies

In this lab part, you will configure security policies to insure the appropriate network traffic is allowed and
scanned for malware.
Step 3.1
Navigate to Conf igure->Firewall Policy->Standard Policies.
In this table, you should notice a number of pre-configured policies. For this lab we will be leaving these
policies for vSRX-2, but creating new policies for vSRX-1.
Click on the value in the Rules column in the row containing vSRX-1.

Global
Configure / Firewsl Policy / Standard Policies Q V o S 9
Firewall Policy Standard Policies®

Standard Policies
Unified Policies
Devices [ Global Options Locking V More •*’ Q Y-

Schedules
[Bl Profiles □ Seq. Name Rules Devices Publish State Last Modified Created By Modified By Domain
Templates
V POLICIES APPLIED BEFORE DEVICE SPECIFIC POLICIES' (1 policy)
Environment
> □ 1 All Devices Policy Pre Add Rule 2 Not Published wed Jun 03.20206:19 PM System Global
H User Firewall Management
Application Firewall Policy > V DEVICE SPECIFIC POLICIES (2 policies)
SSL Profiles > □ vSRX-2 14 vSRX-2 Published Sun Jun 07,2020 6;S0PM super super Global
IPS Policy > □ vSRX-1 11 vSRX-1 Published Sun Jun 07,2020 6:50 PM super super Global
NAT Policy >
UTM Policy >
Application Policy Based Routi... □ 2 AJI Devices Policy Post Add Rule 2 Not Published wed Jun 03,20206:19 pm System Global
Threat Prevention > 4 Items
IPSec VPN >

Shared Objeas >
Change Management >
Guided Setup >
Step 3.2
In the vSRX-l/Rules dialog, select all current rules and click the trash bin icon to delete. Click Yes to
confirm.
Global V C 1^ s
Configure ! Firewall Pokey ! Standard Policies Q
X Firewall Policy
vSRX-1 / Rules Edited 5 minute(s) ago
Standard Policies Delete
Unified Policies Publish Update Shared Objects n. More 0 1^

z
7)
Id
Q Y' :
Devices
E
Schedules
Seq.
Hit Co... Rule Name Src. Zone Src. Address Src. Expression User ID End User Profile Dest. Zone
Profiles
Templates ZONE (3 Rules)
Environment □ V InterZone: clients to untrust (Rules 1 to 3)
eg User Firewall Management > □ NA PoticyEnforcer-Rulei’1 z clients ft ajsec-peg_i72.i8.... *16 z untrust

SSL Profiles > □ NA PoticyEnforcer-Rulel-2 z clients DPRK z untrust
IPS Policy > Q 3 NA clients-to-untrust z clients /k Any z untrust
NAT Policy > V GLOBAL (8 Rules)
UTM Policy > □ 1 NA PollcyEnforcer-Rulel-l z ACME-SV ft ajsec-peg.l72.18....+i6 z untrust

+1
Q 2 NA PoticyEnforcer-Rule1-4 Z DPRK z untrust
Threat Prevention > +1
IPSec VPN > Q 3 NA |uniper-SV-to-untrust Z ACME-SV +1 A Any z untrust
Shared Objects > Q NA PollcyEnforcer-Rulei-2 Z ACME-SV +2 ft ajsec-peg_i72.i8....*i6 Z ACME-SV
Change Management > NA

Q s Poticy6nforcer-Rule1-5 Z ACME-SV +2 DPRK z ACME-SV
Guided Setup >
□ NA clients-to-juniper-sv Z ACME-SV *2 A Any Z ACME-SV
Q 1 NA PoticyEnforcer-Rulei-3 ft ajsec-peg.172.18.... *16
□ 8 NA PolicyEnforcer-Rulel-6 DPRK
Step 3.3
In the next several steps, you will configure the security policies for the vSRX-1 device. Detailed
instructions will be presented for the first policy. Summaries will be given for the remainder.
Click the + icon. In the General screen, configure a Rule Name of Juniper-SV-to-internet.
Click Next.

Create Rule ©
General
General Information
Rule Name* ® lunIper-SV-to-intemet
Description ®
Cancel Next
Step 3.4
In the Source dialog. Select Juniper-svforthe zone. Click Next.
Create Rule®
o—
Gerera Source
Source
Zone ® »Junlper-sv V
Clear All
Addresstes) © Select
Any
User ID 0 Select
End User Profile 0
Clear All
Cancel Sack Next
Step 3.5
In the Destination dialog. Select untrust for the zone. Click Next.

Create Rule®
o o
Destination
Zone O > untrust
Clear All
Address<es) (2) Select

Any
Service Protocols
Servke(s) Select
Any
Cancel •êxi
Step 3.6
In the Advanced Security dialog, select Permit for Action.
For the Threat Prevention Security option, select the ajsec-tpp policy.
Click Next.
Create Rule ©
o—
Ge-e-ai
o-
So_rce
o--
Desti“a:.or Advanced Security
c
Oo:«rs
Advanced Security
Rule Action
Action ® Permit
Advanced Security
App Firewall Select an option Clear All Add New
Supported inJurx>$OS versior 18 1 and lower Forjur>os

18.2 version and later, use dynamic application of Unified
f Policies to Support App Firewall
SSL Proxy <3) Select an option Clear All Add Forward Proxy Add Reverse Proxy
IPS © Off
Supported mjufws OS versior 18.1 and lower
IPS Policy ® Select an option Clear All
Supported in Junos OS version 18.2 and later
UTM 0 Select an option Clear All Add New
Threat Prevention Policy 0 ajsec-cpp Clear All
Cancel Back Next
Step 3.7
Leave the settings at default values for Rule Options, Rule Analysis, and Rule Placement
dialogs.
Click Finish. Click OK in the Summary dialog.

Create Rule ©
o—
Genera’
o—
Source
o—
Desti“at»on
oA0\-ancec Sec-nr/ Rule Options
Rule Options
Profile ® Select
Inherited from policy
Schedule ® Select an option Add New
Clear /Ml
Cancel Back Next
Create Rule ©
o— o- o
Genera Source Destiniation AO-.-anze; Secun^- RJe Optons Rule Analysis
Rule Analysis ® O Analyze the new rule to suggest a placeme...
Cancel Back Next
Lab 12-20 • Juniper Connected Security—Autormated Threat Remediation www.juniper.net

Create Rule ©
a— o— o--- c o— c----
Ge“e*3 So-fee Destrat’or AO-.-ancec Secjnty Rule Options RJe Araij-sis Rule Placement
Analysis
Results No rule analysis was performed. When rule analysis is not performed, the system will suggest a placement according
to the information provided in steps 1 to 5.
Rule Placing
Rule Type ZONE
Location / Sequence Rule Sequence will be No. 1
View Placement Inside Policy
Cancel Back Finish
Create Rule ©
Summary
'ne 'umrary o* r cha'
General Information
Edit
Name Juniper-SV-to-internet
Identify Traffic Source

Edit
Zone Juniper-SV
Address Any
Identify Traffic Destination

Edit
Zone untnjst
Address Any
Service Any
Advanced Security
Edit
IPS Off
Threat Prevention Policy ajsec'tpp
Action PERMIT
Rule Options
Edit
Profile Inherited from policy
Rule Analysis
Edit
Rule Placement
Edit
Cancel Back OK
Step 3.8
Create a new rule with the following settings (leave settings at default if unspecified):
Rule Name: dients-to-internet
Source Zone: clients
Destination Zone: untrust
Action: Permit
Threat Prevention Policy: ajsec-tpp
Step 3.9
Rule Name: block-Juniper-SV-DPRK
Source Zone: Juniper-sv

Destination Zone: 2kny

Destination Address: dprk
Action: Deny
Step 3.10
Rule Name: block-clients-dprk
Source Zone: client
Destination Zone: 2kny
Destination Address: dprk
Action: Deny
Step 3.11
Rule Name: allow-internal-web
Source Zone: Juniper-sv, clients
Destination Zone: Juniper-sv, clients
Services: http, https
Action: Permit
Threat Prevention Policy: ajsec-tpp
Step 3.12
Rule Name: allow-internal-ssh
Source Zone: Juniper-sv, clients
Destination Zone: Juniper-sv, clients
Services: ssh
Action: Permit
Step 3.13
After creating the policies, you will need to re-order the policies so that the DPRK deny policies are
evaluated first. Check the boxes for block-Juniper-sv-DPRK and block-clients-DPRK. Click
and drag above all other Zone policies.

Global s ?
Configure ! Firewall Policy / Standard Policies Q
X Firewall Policy
vSRX-1 / Rules Currently editing this poBcy .
Standard Policies
Unified Policies
( Save Discard Shared Objects v More V Id
71
7, Q ¥• :
Devices
3
Schedules
Seq.
Hit Co... Rule Name Src. Zone Src. Address Src. Expression User IO End User Profile Oest. Zone
lewll Profiles
Templates ZONE (4 Rules)
Environment Wock-Junlper-SV-OPRK « junlper-SV ® Any i untrust
User Firewall Management > block-dients-OPRK X clients ® Any Z untrust

® juniper-SV ® Any
SSL Profiles > juniper-SV-to-internet I untrust
IPS Policy > dients-to-internet X clients ® Any I untrust
NAT Policy > GLOBAL (2 Rules)
UTM Policy > allow-internal-web X clients ® Any L Clients *

Threat Prevention > allow-intemal-ssh X clients -1 ® Any i clients
IPSecVPN >
Shared Objects >
Change Management >
Guided Setup >
Step 3.14
Click Save. Click Update.
In the Update Firewall Policy dialog, click Piiblish and Update. Click Yes.
Update Firewall Policy©
Type* ® Run now

O Schedule at a later time
Si ea - ces that t’’ ■ cpiJdLec .0
1 selected Q :
ea Device Name Publish Req... Configura... Ma... Connection S... Services Domain Device IP Platform OS Version
□ vSRX-1 Required View O in... up vSRX-1 Global 172.25.11.1 VSRX 20.1R1.11
11tems
Step 3.15
Review the Job Status screen.
Wait until the Job State shows Success. Click OK.

Job Status©
* ♦
229683 229684 229685
© © ©
Job Type: Update Devices Job state: Success 0

Job ID: 22968S Percent Complete: 100%
Job Name: Update Devices-229&85 Scheduled Start Time: Sun, 07Jun 202019:19:11 PDT
User: super Actual Start Time: Sun, 07 Jun 2020 19:19:11 POT
End Time: Sun, 07 Jun 2020 19:19:16 PDT
Export to csv Q ¥
vSRX-1 (VSRX-I) Success vSRX-1 [FWPolicyl View view Sun, 07 Jun 2020 19:19:15 PST
1 Rows
OK
Part 4: Simulating an Infected Host
In this lab part, you will simulate a compromised host by downloading simulated malware from a web
server. You will then verify that the malware is detected by ATP cloud and the host is added to the infected
host’s feed.
Step 4.1
Open a web browser and navigate to sky.junipersecurity.net.
Login with the credentials and realm settings provided by your instructor.
juniper KicrxjuoDirC
NETWORKS
r’
(. I Sky ATP
Version 3.0 | Login
(* 1
♦ student@juniper.net
XXXX)^
Q Remember me
Log In

*
I Forgot password and Documentation
Copyright O 2015*3020, Juniper Networks, li I Trademark Notice | Privacy Policy

Step 4.2
In the Sky ATP browser session, navigate to Monitor.
Examine the Hosts table.
* Monitor / Kosts What's new ajsec-realm-1 J 9
X Hosts
Hosts©
C&C Servers
Threat level: O High EO Medium Low None; clean
File Scanning
HTTP File Downloads
Export Set Policy Override v Set Investigation Status v q Y’
Email Attachments
Manual Uploads
□ Host Identifier Host IP Threat Level Infected Host Feed ▼ Last Host Activity C&C Hits Malware... Policy State of Investigation
No data available
Blocked Email >
Telemetry >
■H
©
Step 4.3
Open a virtual console session with the WindowsClient device.
Open the Firefox web browser and navigate to http ://172.17.0.2/fakemalware and download
the file.
ik Probkm iMding page X +

X
« https:. ' .'A'.w .cKar.org downloed/cKv.com ■' C H ’ Googir P ☆ g ♦ *
Opening eic^xom ED
You h*v« chosen to open:
53 f««xom
which k: Biruty File (tt bytes)

from: httpsV/«*ww.«jcer.org
Would you like to seve this fde?
SeveFite
[ Caned
T V '-i I L I I IM
Firefox can't find the server at www.eicar.org.
• Check the address for typing errors such as ww.example.com instead of

www.examplexom
• If you are unable to load any pages, check your computer's network
connection.
« If your computer or network is protected by a firewall or proxy, make sure

that Firefox is permitted to access the Web.
: TryAgkn J|
/h'.’i
1.',
Bl - cb ® 0^ 6fVia»
Step 4.4
Return to the session with the SkyATP web UI.
Navigate to Monitor->Hosts and examine the infected host entries.

Monitor / Hosts What's new ajsec-realm-1 J
X Hosts
Hosts®
C&C Servers
Threat level: (D High Q Medium
Q Low None; clean
File Scanning >
Export Set Policy Override Set Investigation Status Q Y-
Blocked Email >
Telemetry > Host Identifier Host IP Threat Level Infected Host Feed ’ Last Host Activity C&C Hits Malware... Policy State of Investigation
□ 00:50:56:a9;70:5d 10.10.100.140 O 7 Included Jun 7. 202010:22 PM 0 1 Use configured policy Open
■
Question: Is there a host in the infected host feed?
Answer: Yes, you should see the 10.10.100.140 host in the infected
host feed. Note that the Threat Level may differ from the number
shown in this lab guide.
Step 4.5
Return to the CLI session with the vSRX-1 device.
Verify that the infected host entry is added to the infected hosts dynamic address group by issuing the
show security dynamic-address category-name Infected-Hosts command.
lab@vSRX-l> show security dynamic-address category-name Infected-Hosts
No . IP-start IP-end Feed Address
1 10.10.100.140 10.10.100.140 Infected-Hosts/1 ID-fffcl81a
Step 4.6
Return to the CLI session with the vQFX-1 device.
Verify that the firewall filter to block the infected host as been generated and applied to the VLAN
containing the infected host by issuing the show configuration firewall family
ethernet-switching command followed by the show configuration vlans command.
lab@vQFX-l> show configuration firewall family ethernet-switching
filter SDSN_INPUT_vQFX-l_vlO {
term MAC_00:50:56:a9:70:5d {
from {
source-mac-address {
00:50:56:a9:70:5d/48;
}
}
then {
discard;
log;
}
}
term ALLOW_ALL_OTHER_HOST_SDSN {
then accept;

}
}
filter SDSN_OUTPUT_vQFX-l_vlO {
term MAC_00:50:56:a9:70:5d {
from {
destination-mac-address {
00:50:56:a9:70:5d/48;
}
}
then discard;
}
term ALLOW ALL OTHER HOST SDSN {
then accept;
}
}
lab@vQFX-l> show configuration vlans

inactive: v-all {
vlan-id-list 1-4093;
}
vlO {
vlan-id 10;
13-interface irb.lO;
forwarding-options {
input SDSN_INPUT_vQFX-l_vlO;
output SDSN OUTPUT vQFX-1 vlO;
}
}
}
v50 {
vlan-id 50;
}
v55 {
vlan-id 55;
}
v60 {
vlan-id 60;
}
Part 5: Simulating C&C Server Communication
In this lab part, you will simulate a host device attempt to contact a known command and control server.
You will observe the effects of this behavior in the Juniper ATP Cloud GUI.
Step 5.1
Return to the session with the Juniper ATP Cloud GUI.
Navigate to Conf iguration->Third Party Feed and click the toggle to enable the Block List
feed.

IP Filter Feed
office365 □ Enable feed
Email Management >
Go to feed site
Whitelists
Command and Control Feeds
{vg Blacklists
Select to enable open source feeds managed by third parties.
Third Party Feeds
Global Configuration > I The accuracy of these feeds cannot be guaranteed, and false positives generated by these feeds will not be
investigated by juniper Networks. Security policies will block malicious IP addresses and domains based on
X
enabled third party feeds, but these events do not affect host threat scores.
IP Feed
Malware Domain List O Enable feed
Go to feed site
Block List Q Enable feed
Go to feed site
□Shield □ Enable feed
Go to feed site
Tor □ Enable feed
Go to feed site
Ransomware Tracker O Enable feed
Go to feed site Cj
Step 5.2
View the feeds active on the vSRX-1 device by issuing the show services
security-intelligence category summary command.
Note
This might take a few minutes to populate.
Category name cc
Status Enable
Description Coininand and Control data schema
Update interval 1800s
TTL 3456000s
Feed name cc_ip_data
Version 20200608.7
Objects number 89988
Create time 2020-06-08 06:40:18 UTC
Update time 2020-06-08 07:04:07 UTC
Update status Store succeeded
Expired No
Status Active
Options N/A
Feed name cc_url_data
Version 20200608.2
Objects number 42184
Create time 2020-06-08 06:20:21 UTC
Update time 2020-06-08 07:04:10 UTC
Update status Store succeeded
Expired No
Status Active

Options :N/A
Feed name :cc_ip_blocklist
Version :20200607.1
Objects niimber: 2 6438
Create time :2020-06-08 06:53:42 UTC
Update time :2020-06-08 07:04:20 UTC
Expired :No
Status :Active
Options :N/A
Category name :Infected-Hosts

Status :Enable
Description :Host intelligence feed
TTL :3456000s
Feed name :infected_hosts
Version :20200608.3
Objects niimber:!
Create time :2020-06-08 05:45:50 UTC
Update time :2020-06-08 05:46:01 UTC
Expired :No
Status :Active
Options :N/A
Category name :GeoIP

Status :Enable
Description :GeoIP data schema
TTL :157680000s
Feed name :geoip_country
Version :20200602.1
Objects niimber : 329469
Create time :2020-06-08 01:39:30 UTC
Update time :2020-06-08 03:58:30 UTC
Expired :No
Status :Active
Options :N/A
lab@vSRX-l>
Question: Is the enabled 3rd party feed present?
Answer: Yes, it is called cc ip blocklist
Step 5.3
View the contents of the current C&C server feed by issuing the show services
security-intelligence category-name CC command

lab@vSRX-l> show security dynamic-address category-name CC
1 1.0.132.213 1.0.132.213 CC/1 ID-fffcO811
2 1.0.165.13 1.0.165.13 CC/1 ID-fffcO811
3 1.0.228.201 1.0.228.201 CC/1 ID-fffcO816
4 1.0.229.168 1.0.229.168 CC/1 ID-fffcO816
5 1.0.232.87 1.0.232.87 CC/1 ID-fffcO811
6 1.0.232.87 1.0.232.87 CC/1 ID-fffcO816
7 1.0.234.95 1.0.234.95 CC/1 ID-fffcO816
8 1.1.132.61 1.1.132.61 CC/1 ID-fffcO816
9 1.1.135.186 1.1.135.186 CC/1 ID-fffcO811
10 1.1.147.161 1.1.147.161 CC/1 ID-fffcO816
78 1.32.218.157 1.32.218.157 CC/1 ID-fffcO816
Step 5.4
Open a CLI session with the KaliPentester device.
From the CLI session with the KaliPentester device, attempt to ping the IP you noted in the previous step.
After a few seconds, use ctrl-c to cancel.
lab@kali:~$ ping 1.32.218.157
PING 1.32.218.157 (1.32.218.157) 56(84) bytes of data.
A
C
8 packets transmitted. 0 received. 100% packet loss, time 7169ms
Question: Was the ping successful?
Answer: No, the ping should be unsuccessful because it is blocked at

the SRX by the CC policy on the device.
Step 5.5
Verify that C&C block actions have taken place by issuing the show services
security-intelligence statistics command.
lab@vSRX-l> show services security-intelligence statistics
Logical system: root-logical-system
Category Whitelist:
Profile Whitelist:
Total processed sessions: 280
Permit sessions: 0
Category Blacklist:
Profile Blacklist:
Block drop sessions: 0
Category CC:
Profile ajsec-tpp_CC:

Permit sessions: 0
Block close sessions: 0
Close redirect sessions: 0
Profile feed-cc-log-only:
Permit sessions: 0
Category Infected-Hosts:
Profile ajsec-tpp Infected-Hosts:
Permit sessions: 0
Question: Do the statistic indicate sessions blocked due to C&C

server communication?
Answer: Yes, the Block drop sessions counter under

Category CC, profile ajsec-tpp_CCshows a count of 8
indicating sessions dropped due to C&C server communication. The
count might be different than the shown output.
Step 5.6
Return to the SkyATP GUI
Navigate to Monitor->Hosts and examine the Hosts table.
Monitor / Kosts What's new ajsec-realm-1 J 9
Hosts
Hosts®
C&C Servers
Threat level: (D High EO Medium Low None; clean
File Scanning >
Export Set Policy Override Set Investigation Status Q Y-
Blocked Email >
CT
Telemetry > □ Host Identifier Host IP Threat Level Infected Host Feed ’ Last Host Activity C&C Hits Malware... Policy State of Investigation
□ n/a@10.10.100.6 10.10.100.6 □ 5 Excluded Jun 7, 202010:41 PM 2 0 Use configured policy Open
□ 00:50:56:a9:70:5d 10.10.100.140 O 7 Included Jun 7.202010:22 PM 0 2 Use configured policy Open
H
Si
step 5.7
Navigate to Monitor->C&C Servers
Examine the contents of the C&C servers table. Take note of the current threat level of the
10.10.100.6 host.

* Monitor / C&C Servers What's new ajsec-realm-1 J ?
Hosts
Command & Control (C&C) Servers ©
C&C Servers
Threat level: O High [B Medium Low None; clean
File Scanning
HTTP File Downloads

Export q Y-
Email Attachments
External Server IP External Server Hostname Blocked Via Highest Threat L... Count Country ’ Last Seen Action Category
IZ3
Manual Uploads
1.32.218.157 rVa Global Threat Feed • IP O 10 91 Singapore Jun 7. 202010:44... block CnC
Blocked Email >
Telemetry >
H
H
step 5.8
Return to the CLI session with the KaliPentester device.
Launch a script that will attempt to contact 50 different known C&C servers by executing sudo . /
cc feeds.sh.
lab@kali:~$ sudo ./cc feeds.sh
-2020-06-08 00:34:08 — http://lists.blocklist.de/lists/all.txt
Resolving lists.blocklist.de (lists.blocklist.de)... 185.21.103.31,
2a00:1158:2:6d00::2
Connecting to lists.blocklist.de (lists.blocklist.de) |185.21.103.31 | : 80 .. .
connected.
HTTP request sent, awaiting response... 200 OK
Length: 424851 (415K) [text/plain]
Saving to: 'CCS.txt'
CCS.txt 100% [ ] 414.89K 178KB/S in 2.3s
2020-06-08 00:34:11 (178 KB/s) 'CCS.txt' saved [424851/424851]
1.0.156.44 is unreachable

labOkali:
Step 5.9
Return to the session with the SkyATP Web UI.
Navigate to Dashboard. Examine the chart of C&C Server and Malware Source Locations.
My Dashboard
C&C Server and Malware Source Locations Top Infected File Categories
A Show; C&C Servers Previous: 1 month Show; Med. High Threat Previous: 1 month
+
1
‘A
B
/ !
z.
V .•y
t
o
f*
Io I
•4
■n A
% .h'
k
0
.y f
I
5 A. f
z ys 'f
Updated Jun & 2020,10 ;5,2o AM, UTC -07 00 POT More DeUi s
?•
Top Scanned Tile Categories

7
Previous: 1 rrxxith
*.T J
V,
Threat Count
1-49 /
100499
500*
■ 50-99
If
0 I
'.f^r.riFd
Upceird Jun 8^ 2020,10:23 28 AM, UTC -07 00 POT More Detai s Updated Jun & 7070.1023:28 AM UTC -07 00 POT More DeUi s

Step 5.10
Navigate to Monitor->Hosts. Examine the Hosts table. Note the updated Threat Level and C&C
Hits values.
* Monitor / Hosts What's new ajsec-realm-1 J 9
Hosts
Hosts©
C&C Servers
Q Threat level: O High Q Medium Low None; clean
File Scanning >
Export Set Policy Override Set Investigation Status q Y-
Blocked Email >
IBB]
Telemetry > Host Identifier Host IP Threat Level Infected Host Feed ’ Last Host Activity C&C Hits Malware... Policy State of Investigation
□ n/a@i0.10.100.6 10.10.100.6 m 6 Excluded Jun 7.202010:44 PM 50 0 Use configured policy Open
□ 00:50:56:a9:70:5d 10.10.100.140 O 7 Included Jun 7,202010:22 PM 0 2 Use configured policy Open
■
Eg
Step 5.11
Check the box for Host ip 10.10.100.6 in the Hosts table. Click the dropdown for Set Policy
Override and Select Always include in Infected Host Feed.
Examine the updated Hosts table.
♦ Monitor / Hosts What’s new ajsec-realm-1 J 9
Hosts
Hosts©
C&C Servers
Threat level: O High Q Medium Low None; clean
File Scanning >
Export Sot Policy Override Set Investigation Status v Q Y’
Blocked Email >
E3
Telemetry > □ Host Identifier Host IP Threat Level Infected Host Feed ▼ Last Host Activity C&C Hits Malware,
Never include host(s) in infected host feed
Always include hosUs) in infected host feed

.vestigation
ea n/a@10.10.100.6 10.10.100.6 □ 6 Excluded Jun 7, 202010:44 PM 50 0 Use configured policy
□ 00;50:56:a9:70:5d 10.10.100.140 O 7 Included Jun 7. 202010:22 PM 0 2 Use configured policy Open
■
s?
step 5.12
View the current content of the Infected Hosts feed by issuing the show security
dynamic-address category-name Infected-Hosts command.
lab@vSRX-l> show security dynamic-address category-name Infected-Hosts
Step 5.13
View the updated firewall filter settings by issuing the show configuration firewall family
ethernet-switching command.

{master:0}
lab@vQFX-l> show configuration firewall family ethemet-switching
filter SDSN_INPUT_vQFX-l_vlO {
term MAC_00:50:56:a9:64:30 {
from {
00:50:56:a9:64:30/48;
}
}
then {
discard;
log;
}
}
term MAC_00:50:56:a9:70:5d {
from {
00:50:56:a9:70:5d/48;
}
}
then {
discard;
log;
}
}
term ALLOW_ALL_OTHER_HOST_SDSN {
then accept;
}
}
filter SDSN_OUTPUT_vQFX-l_vlO {
term MAC_00:50:56:a9:64:30 {
from {
00:50:56:a9:64:30/48;
}
}
then discard;
}
term MAC_00:50:56:a9:70:5d {
from {
00:50:56:a9:70:5d/48;
}
}
then discard;
}
term ALLOW ALL OTHER HOST SDSN {
then accept;
}
}

Part 6: Cleaning Up
In this lab part, you will return the lab environment to its starting state.
Step 6.1
Open a web browser and navigate to sky.junipersecurity.net.
If not already logged in to the SkyATP web UI, authenticate with the credentials provided by your instructor.
jumper NETVrjh«c
Sky ATP
Version 3.0 | Login
♦ student@juniper.net
xxxxj
Q Remember me
Login
«
/
Create a semrwy realm Supported JUNOS Software
<
Copyrig^ O 2015-2020, Juniper Metworks. In^ k 3 ><35^ wd I Trademark Notice | Privacy Polcy
step 6.2
Navigate to Monitor->Hosts. Check the box for the 10.10.100.6 host. In the Set Policy
Override dropdown, select Use Configured Policy.
Wait for the host to reappear in the Hosts table before continuing. You may need to refresh the page.
A
MOTMCOr Z Hmu What’S new ajsec-realm-1 J ?
X Hosts
Hosts ®
C8tC Servers
Threat level: ©High [1] Medium ...Low None: clean
Q
Ale Scanning >
Export Set Policy Override w Set mvestigabon Status
S Blocked Email >
Telemetry > □ Host Identifier Host IP Threat Level Infected Host Feed * Last Host Activity C&C Hits Malware
Never irxludc host(s) in infected host feed
Always include hostfs) in infected host feed

vestigation
□ n/a^00:50:56:a... 10.10.100.6 m 6 Included manually Jun 8.2020 12:37 AM SO 0 Use configured policy
00:SO:S6:a9:70:Sd 10.10.100.140 O 7 Included Jun 7.2020 10:22 PM 0 2 Use configured pokey Open
Step 6.3
Check the boxes for both hosts. In the Set investigation Status drop down menu select
Resolved Fixed.

* MoTMtor / Hosts What'S r>ew ajscc-realm-1 J 9
X Hosts
Hosts®
C&C Servers
Threat level: O High Q Medium Low None; dean
Ale Scanning >
Export Set Pokiy Override Set inveMigatlon Sut 71 q Y’
Blocked Email >
In Progress
Telemetry > Q Host Mentirier Host IP Threat Level Infected Host Feed ▼ Last Host Activity C&C Hits Malware Policy tion
Resolved • False positive
Q n/aÔO:SO:56:a... 10.10.100.6 □ 6 Excluded Jun 8.202010:27 AM 50 0 Use configured poll

Resotved - Axed
Resolved • Ignored
Q 00:50;56;a9:70:5d 10.10.100.140 O 7 Included Jun 7. 2020 10:22 PM 0 2 Use configured poli
1
<s>
step 6.4
Open a web browser and navigate to the IP address of the Junos Space Security Director.
Navigate to Devices->Secure Fabric. Check the box for ajsec-lab. Click the recycle bin icon.
Click Yes to confirm the delete.
Global
OiWB I q Q t5 1 9
X Security Devices Secure Fabric®

DevKe Discovery
Secure Fabrk
Sites 1 iiriflFi Add Enforcement Ponts + Z 0
NSX Managers
vCenter Servers
Q Site Enforcement Points IP Model Feed Source Feed Source last Updated Oeser ip—
* Q > ajsee-iao ♦2 17225.11.2 *2 VSAX *2 skyaip June 07.2020
1 terns O
Delete the site(s)

The selected slteft) ' ajsec-Ub' be deleted
Ho Yes
Step 6.5
Navigate to Conf igure->Firewall Policy->Standarci Policies.
Check the boxes for the vSRX-1 and vSRX-2 policies. Click the recycle bin icon and click Yes to
confirm the delete.
Global '7
ConilBvr? > rr!..jfPBecy > StandardPeaciet Q O 8
Firewall Policy V
Standard Policies®
Standard Pohcles
UntRed Poboes
Devices
2setKSd [ Ugdate [ G>â< ] •‘.fcxe + 0 Q Y’
Schedules
Profiles □ Sect. Name Rules Devices Publish State Last Modified Created By Modified By Domain
Templates
V POLICIIS APPLIED BEFORE DEVICE SPECIFIC POLICIES (1 polky]
Environment
User Firewall Management >

□ 1 Al Devtc«> -ky Pre Addtuie 2 HotPuOesned wed Jun 032020 6-i 9 PM System Global
AppKahon Firewall Policy > v DEVICE SPECIFIC POLICIES (2 policies)
SSL Profiles > Q A

Delete Firewall Policy m Jun 07.2020 6 so PM Super super Global
IPS Pobey > □ A »nJun07.2020 M8PM super super Global

NAT Policy > Delete the 2 selected items?
V POLICIES APPLIED AFTER DEVKE SPECIFIC POE

UTM Policy > NO Yes
AppKation Policy Based Routi o 2 Al Devices Policy Post edjun 03.2020 6'19 PM System Global
Threat Prevention > a terns
iPSec VPN >

Shared Objects >
Change Management >

Step 6.6
Navigate to Conf igure->Threat Prevention->Policies.
Check the box for ajsec-tpp and click the recycle bin icon to delete. Click Yes to confirm the delete.
Con#iju»e ! Threat ^tewer&on t Q Gtobai

a s ?
X Firewall Policy
Threat Prevention Policies®
Standard
umfwd
Oewces
'< MtacBid t-5 Oovps + / 0
Scheduler
B Profiles ea Name Feed Type C« Server infected Host Malwere HTTP DOoS Melware SM... Melware IMAP Status Policy enforcement 6— Description
Templates
□ ► ajsec ipp SKYATP Block: •2 Block Drop default_profile Updated aiiec-froup Log all traffic
Environment
1 items C
I»1 User Firewall Management >
Application Firewall Pokey >
SSL Profiles > Delete Threat Management Policy
IPS Pokey >
Are you sure you went to delete the selected Threat Menagement
NAT Policy > PoScy<s>?
UTM Policy > NO Yes

Application Policy Based Routi.
Threat Prevention
Step 6.7
Navigate to Conf igure->Threat Prevention->Feed Sources.
Check the box for the ajsec-realm-l SkyATP realm. Click the recycle bin icon and click Yes to confirm
the delete.
Global 9
Conftfur* ! Tbâat Pi»»»nK»r ! Taod Sourcaa Q sr O 15 s
Firewall Policy Feed Sources®

sta'xwrd Poi«cie$
ufvftad Ppbeios
Devices
Schedules
Profiles
Templates
isMected
[ Mor, 3 + z s
Environment
User Firewall Management > □ Realm Sites Devices Location ervpilment Status Token Expiry Feed Status last Downipaded
Application Firewall PoiKy > □ |un 7. 2021 ©0« Jun 8. 2O?aiO'37 3O
$SL Profiles > 1 nems C Confirm Delete

IPS Policy >
NAT Policy > Oetete the selected Item?
UTM Policy > No Yes
Application Policy Based Routi..
Threat Prevention
Poaces
Feed Sources
iPSeeVPN >
Shared Objects >
Change Management >
Guided Setup >
Step 6.8
Navigate to Devices->Security Devices.
Check the boxes for both vSRX devices. Right click and select Operations->Delete Devices. Click
OK to confirm the delete.
In the Job Details dialog, insure that the Job State reaches Success. Click OK.

Global
Q G 13 s 9
X Security Devices Security Devices®

Device Discovery
Q
Secure Fabric
2s«4ect«O •Jpd*M ClUCft J Cv - --: C’-*:k (UsyocbrondtvMtt NMwork Uor« 3 Q Y :
3 NSX Managers
vCenter Servers
Q Device N»me * IF Address OS Version CFU Storage ConneCTion Status Feed Source Feed Source Status Managed Status
Q V5W-2 17? ? 20.1R1 11 ▲ up Not Registered so Changed Oence
Configuration
□ > vSRXd ▲ up Not Registered SO Changed Device...
□ Oparatiom Delete Derices
Reboot Devices
cents 1 of 1 Display SO V
ResyixhrorMze wim Networic
inventory DetaHs
Update Changes
Upload Keys
import
Refresh Certifkace
Asr|rê^y^^T^
Step 6.9
Return to the CLI Session with the vSRX-1 device.
Terminate the session by issuing the exit command.
lab0vSRX-l> exit
Step 6.10
Terminate the session by issuing the exit command
{master:0}
lab0vQFX-l> exit
Step 6.11
Return to the CLI session with the KaliPentester device.
Terminate the session by issuing the exit command
lab0kali:~$ exit


vSRX.1 ^55^
ATP Cloud
Physical
vSRX-VR SSc 172.25.11.254 1
1
Internet
vQFX-1 Console and
VNC Connections
Junos
Space
Policy
Hypervisor
Core ATP On-Prem
Network
vQFX-1 172.25.11.10
Gateway 172.25.11.254
02020 Juniper Networks. Inc Al Rights Reserved

juniper
fit "V/:;*.*! •.
hl
Lab Network Diagram: Juniper Connected Security

Automated Threat Remediation
untrust zone Internet
ge-0/0/1
vSRX-1
loO: 192.168.1.1
(.1) ge-0/0/3
10.11.10.0/24
clientszone
(2}
vQFX-1 xe-0/0/3
irb.10
(-1)
VLAN 10
10.10.100.0/24
(-140)
WindowsClient LinuxClient KaliPentester
02020 Juniper Networks. Inc Al Rights Reserved

juniper
r»i • ACi.* •.

juniperklCTVA/rÔIZC
NETWORKS
Juniper University
Education Services
Corporate and Sales Headquarters

Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4737)
or 408.745.2000
Fax: 408.745.2100
www.juniper.net
APAC and EMEA Headquarters

Juniper Networks International B.V.
Boeing Avenue 240
1119 PZ SCHIPHOL-RIJK
Amsterdam, Netherlands
Phone: 31.0.207.125.700
Fax: 31.0.207.125.701
■3
Copyright 2020
' A • Juniper Networks, Inc. All rights reserved.
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,
services marks, registered marks, or registered services marks
are the property of their respective owners.
Juniper Networks assumes no responsibility for

any inaccuracies in this document. Juniper Networks
reserves the right to change, modify, transfer, or
otherwise revise this publication without notice.
Engineering
Simplicity
EDU-JUN-AJSEC, Revision V20A

Bản Sao Của Ajsec-lg

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bản Sao Của Ajsec-lg

Uploaded by

Copyright:

Available Formats

Juniper University

Advanced Juniper Security

LAB GUIDE Revision V20A

Juniper University Education Services Courseware

Course Number: AJSEC

Lab 2: Firewall Filters................................................. 2-1

Lab 3: Troubleshooting Security Zones and Policies 3-1

Lab 4: Hub-and-Spoke VPNs ............................... 4-1

Lab 5: Advanced NAT...................................................................... 5-1

Lab 6: Implementing Tenant Systems 6-1

Lab 7: PKIandADVPNs ........................... 7-1

Lab 8: Implementing Advanced IPsec VPN Solutions 8-1

www.juniper.net Contents • Lab 1-iii

Lab 10:Seclntel ................................................... 10-1

Lab 11: Juniper ATP On-Prem............. 11-1

Lab 12: Juniper Connected Security—Automated Threat Remediation 12-1

Lab 1-iv • www.juniper.net

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

Chapter 2: Junos Layer 2 Packet Handling and Security Features

Lab 1: Implementing Layer 2 Security

Chapter 3: Firewall Filters

Lab 2: Implementing Firewall Filters

Chapter 4: Troubleshooting Zones and Policies

Lab 3: Troubleshooting Zones and Policies

Lab 4: Implementing Hub-and-Spoke VPNs

Chapter 6: Advanced NAT

Lab 5: Implementing Advanced NAT Features

Chapter 7: Logical and Tenant Systems

Lab 6: Implementing TSYS

Lab 7: Implementing ADVPNs

Chapter 9: Advanced IPsec

Lab 8: Implementing Advanced IPsec Solutions

Chapter 10: Troubleshooting IPsec

Lab 9: Troubleshooting IPsec

Chapter 12: SecIntel

Lab 10: Implementing SecIntel

Chapter 13: Advanced Juniper ATP On-Prem

Lab 11: Implementing Advanced ATP On-Prem

Chapter 14: Automated Threat Mitigation

Lab 12: Identifying and Mitigation of Threats

Appendix A: Group VPNs

www.juniper.net Course Agenda • vii

CLI and GUI Text

Style Description Usage Example

Serif Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxpO, Enabled

GUI Input Select File Save, and type config. ini

Undefined Syntax Variables

Style Description Usage Example

viii • Document Conventions www.juniper.net

Education Services Offerings

About This Publication

Juniper Networks Support

www.juniper.net Additional Information • ix

www.juniper.net Implementing Layer 2 Security • Lab 1-1

Part 1: Loading the Baseline Configuration

Question: What are the management addresses assigned to your

Answer: The answer varies. The sample hostname and IP address

-- JUNOS 20.lRl.il Kernel 64-bit XEN JNPR-11.0-20200219.fbl20e7_buil

Lab 1-2 • Implementing Layer 2 Security www.juniper.net

-- JUNOS 20.lRl.il Kernel 64-bit XEN JNPR-11.0-20200219.fbl20e7_buil