AJSEC 12.b LGD PDF

A�dvanced Junos Security
12.b
Detailed Lab Guide
Worldwide Education Services
1194 North Mathilda Avenue

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

This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, lnc. 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 Junos Security Detailed Lab Guide, Revision 12.b
Copyright© 2013 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a-March 2011
Revision 12.a-June 2012
Revision 12.b--June 2013
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.1.X44-010.4. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating syslem 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 AppSecure {Detailed) ............................... 1-1
Part 1: Verifying Access to the CLI andVMware Client ........................................... 1-2
Part 2: Configuring AppFW and ApplD Features ................................................ 1-5
Part 3: Building Custom Application Signatures ........••••................................... 1-16
Part 4: Implementing AppTrack ............................................................ 1-27
Lab 2: Implementing Layer 2 Security {Detailed) ........................... 2-1

Part 1: Logging In Using the CLI ............................................................. 2-2
Part 2: Configuring Transparent Mode ....................................................... 2-11
Part 3: Securing Layer 2 Traffic in Transparent Mode .......................................... 2-16
Lab 3: Implementing Junos Virtual Routing {Detailed) ....................... 3-1

Part 1: Configuring Internet Access .......................................................... 3-2
Part 2: Configuring lnter-VR Communication ................................................... 3-9
Part 3: Configuring Filter-Based Forwarding .................................................. 3-22
Lab 4: Advanced NAT Implementations {Detailed) .......................... 4-1

Part 1: Loading the Baseline Configuration .................................................... 4-2
Part 2: Configuring NAT Implementation-Port Forwarding ....................................... 4-7
Part 3: Configuring NAT Implementation-Local Environment .................................... 4-16
Part 4: Implementing 1Pv6 NAT-NAT64 ...................................................... 4-26
Part 5: Implementing 1Pv6 NAT-NAT46 ...................................................... 4-35
Lab 5: Hub-and-Spoke IPsec VPNs {Detailed) .............................. 5-1

Part 2: Configuring the Interfaces, Zones, and Policies .......................................... 5-4
Part 3: Configuring IKE and IPsec Properties................................................... 5-8
Part 4:Verifying IPsecVPNs ............................................................... 5-13
Lab 6: Configuring Group VPNs {Detailed) ................................ 6-1

Part 2: Configuring the Group Member IPsecVPN .............................................. 6-5
Part 3: Configuring the Security Policies to Use the IPsecVPN .................................... 6-9
Part 4: Verifying the Group IPsecVPN ....................................................... 6-13
Lab 7: Implementing Advanced IPsec VPN Solutions {Detailed) ............... 7-1

Part 1: Loading the Baseline Configuration. ................................................... 7-2
Part 2: Configuring the Site-to-Site IPsecVPN .................................................. 7-4
Part 3: Configuring the GRE Tunnel over the IPsecVPN ......................................... 7-11
Part 4: Configuring OSPF over the GRE Tunnel ................................................ 7-13
Part 5: Working with Overlapping Address Space .............................................. 7-16
Lab 8: Performing Security Troubleshooting Techniques {Detailed) ............ 8-1

Part 1: Examining Log Messages ............................................................ 8-2
Part 2: Troubleshooting IPsec Tunnels ....................................................... 8-15
www.juniper.net Contents • iii

iv • Contents www.juniper.net
Cours1� Overview
This three-day course, which is designed to build off of the currentJunos Security (JSEC) offering,
delves deeper into Junos security. Through demonstrations and hands-on labs, you will gain
experience in configuring and monitoring the advanced Junos OS security features with advanced
coverage of IPsec deployments. virtualization. AppSecure, advanced Network Address Translation
(NAT) deployments, and Layer 2 security. This course uses Juniper Networks SRX Series Services
Gateways for the hands-on component. This course is based on Junos OS Release 12.1X44-010.4.
Objectives
After successfully completing this course, you should be able to:
Demonstrate understanding of concepts covered in the prerequisite Junos Security
course.
Describe the various forms of security supported by the Junos OS.
Implement features of the AppSecure suite, including Appl0, AppFW, and App Track.
Configure custom application signatures.
Describe Junos security handling at Layer 2 versus Layer 3.
Implement Layer 2 transparent mode security features.
Demonstrate understanding of Logical Systems (LSYS).
Implement address books with dynamic addressing.
Compose security policies utilizing ALGs, custom applications. and dynamic
addressing for various scenarios.
Use Junos debugging tools to analyze traffic flows and identify traffic processing
patterns and problems.
Describe Junos routing instance types used for virtualization.
Implement virtual routing instances.
Describe and configure route sharing between routing instances using logical tunnel
interfaces.
Describe and implement static, source, destination, and dual NAT in complex LAN
environments.
Describe and implement variations of persistent NAT.
Describe and implement Carrier Grade NAT (CGN) solutions for 1Pv6 NAT, such as
NAT64, NAT46, and OS-Lite.
Describe the interaction between NAT and security policy.
Demonstrate understanding of DNS doctoring.
Differentiate and configure standard point-to-point IP Security (IPsec) virtual private
network (VPN) tunnels, hub-and-spoke VPNs, dynamic VPNs, and group VPNs.
Implement IPsec tunnels using virtual routers.
Implement OSPF over IPsec tunnels and utilize generic routing encapsulation (GRE) to
interconnect to legacy firewalls.
Monitor the operations of the various IPsec VPN implementations.
Describe public key cryptography for certificates.
Utilize Junos tools for troubleshooting Ju nos security implementations.
Perform successful troubleshooting of some common Junos security issues.
www.juniper.net Course Overview • v

Intended Audience
This course benefits individuals responsible for implementing, monitoring, and troubleslhooting
Junos security components.
Course Level
Advanced Junos Security is an advanced-level course.
Prerequisites
Students should have a strong level of TCP/IP networking and security knowledge. Stude-nts should
also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE),
and Junos Security (JSEC) courses prior to attending this class.
vi • Course Overview www,juniper.net

Course Agenda
Day1
Chapter 1: Course Introduction
Chapter 2: AppSecure
Implementing AppSecure Lab
Chapter 3: Junos Layer 2 Packet Handling and Security Features
Implementing Layer 2 Security Lab
Chapter 4: Virtualization
Implementing Junos Virtual Routing Lab
Day2
Chapter 5: Advanced NAT Concepts
Advanced NAT Implementations Lab
Chapter 6: IPsec Implementations
Hub-and-Spoke IPsec VPNs Lab
Day3
Chapter 7: Enterprise IPsec Technologies: Group and Dynamic VPNs
Configuring Group VPNs Lab
Chapter 8: IPsec VPN Case Studies and Solutions
Implementing Advanced IPsec VPN Solutions Lab
Chapter 9: Troubleshooting Junos Security
Performing Security Troubleshooting Techniques Lab
Appendix A: SRX Series Hardware and Interfaces
www.juniper.net Course Agenda • vii

Document Conventions
CU and GUI Text

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

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

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

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

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

assigned.
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
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
The Advanced Junos Security Detailed Lab Guide was developed and tested using software
Release 12.1X44-D10.4. Previous and later versions of software might behave differently so you
should always consult the documentation and release notes for the version of code you are running
before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to [email protected].
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.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 AppSecure (Detailed)
Overvi,ew
In this lab, you will implement features of the AppSecure suite. You will begin by
configuring ApplD and AppFW features to protect the VM server against Application Layer
attacks. Then, you will configure a custom application signature to restrict access to
certain sections of the VM server. Finally, you will configure AppTrack to monitor FTP
exchanges between the VM client and the VM server.
The lab is available in two formats: a high-level format designed to make you think through
each step and a detailed format that offers step-by-step instructions complete with
sample output from most commands.
By completing this lab, you will perform the following tasks:
Configure and monitor ApplD and AppFW features.
Configure and use custom application signatures.
Configure and monitor AppTrack.
www.juniper.net Implementing AppSecure (Detailed) • Lab 1-1

Advanced Junos Security
Part 1: Verifying Access to the CLI and VMware Client
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
command-line interface (CLI) to log in to your designated station. Then, you verify
that you can log in to the VMware client and confirm that FTP and Web browsing are
available on the desktop.
Note
You will only be able to FTP and Web
browse within the constraints that are
created on the VMware server.
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 with the details needed to access your
assigned device.
Step i1
Ensure that you know to which station you are assigned. Check with your instructor if
you are unsure. Consult the Management Network Diagram to determine the
management address of your station. In some classrooms, you might also be able to
access the station by domain name.
Question: What is the management address

assigned to your station?
Answer: The answer varies. In this example, the

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

O Show quick connect on sla1tup � Save session

el Open in a tab
11 .Connect � I Cancel j
Step i3
Log in as user lab with the password supplied by your instructor.
srxA-1 (ttyuO)
login: lab
Password:
--- JUNOS 12.1X44-Dl0.4 built 2013-01-08 05:15:31 UTC

lab@srxA-1>
Step 1.4
Refer to the Management Network Diagram to determine the IP address of the
VMware client device attached to your assigned SRX device. The device to which this
lab step refers depends on which SRX device you have been assigned. Connect to
the IP address associated with the appropriate VMware client using the Virtual
Network Computing (VNC) client application provided to you by your instructor. Use
lab123 as the password to connect to the VMware client. Insert a": 1" after the
appropriate IP address to make the connection.
Note
The applications are installed on virtual
network computers. Your access to the
VMware client might vary according to lab
environments. Your instructor will provide
the access method. Please notify your
instructor if you are not sure how to access
the VMware client device.
www.junipe·r.net Implementing AppSecure (Detailed) • Lab 1-3

My Computer
My Network
Places
Recycle Bin
My Documents
Run VNC Viewer
-��---��-
VNC Viewer : ,l\uthentlcation (No Encryption]
Username: �------� CK:)
Pass'rK)fd:
<...........................•.•.••..........•.............•••••• �
Lab 1-4 • Implementing AppSecure (Detailed) www.juniper.net

Question: Can you log in to the VMware client?
Answer: As shown in the output, you should be able

to log in to the VMware client. If you experience any
issues with your login, check that you are using the
appropriate IP address and have inserted a ": 1"
after the address. If you are still experiencing any
issues, notify your instructor.
Question: Do you see icons for FTP and a Web

browser on the VMware client desktop?
Answer: As shown in the output, you should see

icons for FTP and a Web browser on the VMware
client desktop. If you are missing any of the three
previously mentioned applications, notify your
instructor.
Part 2: C1onfiguring AppFW and ApplD Features
In this lab part, you configure an AppFW rule set to block FTP traffic that is being
disguised as Hypertext Transfer Protocol (HTIP) traffic on TCP port 8080. Then, you
will verify that this traffic is being blocked as intended.
Step 2.1
Return to the session established with your assigned SRX device.
From your assigned SRX device, enter configuration mode and load the
labl-start. configfrom the /var/home/lab/aj sec/ directory. Commit
the configuration when complete.
lab@srxA-1> configure
Entering configuration mode
[edit]
lab@srxA-1# load override ajsec/labl-start.config
[edit]
lab@srxA-1# commit
commit complete

Step 2.2
Over the next few steps, you will create an AppFW rule set that blocks certain
unwanted traffic, and allows all other traffic based on the information contained in
the Application Layer.
Examine the current firewall security policies by navigating to the
[edit security policies] hierarchy level and issue the show command.
[edit]
lab@srxA-1# edit security policies
[edit security policies]

lab@srxA-1# show
from-zone Trust to-zone Untrust
policy allow-trust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
from-zone Untrust to-zone Trust {

policy HTTP {
match {
source-address any;
application [ junos-http custom-http-8080 J;
}
then {
permit;
policy FTP {
match {
source-address any;
application junos-ftp;
}
then {
permit;
policy DNS {
match {
source-address any;
application [ junos-dns-tcp junos-dns-udp J;
}
then {
permit;

Step 2.3
Examine the custom-http-8080 application by issuing the top show
applications command.
lab@srxA-1# top show applications
application custom-http-8080 {
protocol tcp;
destination-port 8080;
Question: Based on the output, which types of

traffic does the SRX device permit?
Answer: The SRX device is allowing all traffic from

the Trust to Untrust zones. It is also allowing HTTP,
FTP, and DNS traffic from the Untrust to Trust zones.
Question: Will the HTTP policy block non-HTTP

traffic that is using TCP ports 80 or 8080 as the
destination port?
Answer: No. The HTTP policy is only examining the

traffic up to Layer 4. As long as TCP ports 80 or
8080 are used as the destination port, any
application can be used.
Step 2.4
Return to the VNC session established with the VMware client.
From the VNC session established with VMware client, double-click the gFTP client
icon that is on the desktop.
www.junipe,r.net Implementing AppSecure (Detailed) • Lab 1-7

Advanced Junes Security
... . . . . . . . . . . . .. . L�J
Group
Progress
gFTP 2.0.18. Copyr1ght (CJ 1998-2003 Brl,.n Masney <n1o1sl'leyb@yf".p org>. If you h.ive ;my questions. co mments. or SU99Utlot'li
about tnls progr,1m. ple.ise reel free to email !hemto me. 'ltlu can always l'Ind out the latest l'lews about gFTP from my weDsite al.
http://Wwwgrtp.org/
gFTP comes wn:n A.BSOL.U1cLY NO WARRANTY: fordetails. see !he COPYING flle Th!s Is free sortware, and you are welt:ome to
redistribute itundercertalnconditions:rordetails.s eetheCOPYINGl'ile
Step 2.5
Open an FTP session to the aj secserver. aj sec.juniper. net UHL and use
port 8 o 8 o as the destination port. To log in, use the username of lab and password
of labl23.
User Group
·······-
200 Switching l-o Binary mode.
p..•.:o
257 "/homel1ab" I
Loading directory listing /home/lab rrom server (LC_TIME=en_US.UTF-8)
PA:iV
227 Entering Pa,;slve Mede (.1 72 ..16.10,100,183.2471
�''
Lab 1-8 • Implementing AppSecure (Detailed) www,juniper.net

Step 2.6
From your assigned SRX device, examine the session table by issuing the run
show security flow session command.
lab@srxl\.-1# run show security flow session
Session ID: 24147, Policy name: HTTP/5, Timeout: 1710, Valid
In: 172.16.1.100/42819 --> 172.16.10.100/8080;tcp, If: ge-0/0/8.0, Pkts: 10,
Bytes: 576
Out: 172.16.10.100/8080 --> 172.16.l.100/42819;tcp, If: ge-0/0/9.0, Pkts: 9,
Bytes: 671
Question: Did the traffic make it through the

SRX device? Why or why not?
Answer: Yes, the traffic made it through.The

SRX device believes that this traffic is HTTP traffic
that is using TCP port 8080 even though it is FTP
traffic.
Question: Is this behavior a security threat?
Answer: Yes. An attacker could use this information

to send malicious traffic toward the internal server.
Question: How can you stop this type of unwanted

traffic?
Answer: To stop the unwanted traffic, you can

configure an AppFW rule set that inspects the
Layer 7 data.

Step 2.7
Over the next couple of steps, you will examine the ApplD database for application
signatures that are suitable for your situation.
Look for HTIP-related application signatures in the ApplD database by issuing the
run show services application-identification application
sUllllllary I match http command.
lab@srxA-1# run show services application-identification application si:lllllilary
match http
junos:FRING-HTTP No 1119 33479
junos:VUZE-HTTP No 1098 33538
junos:ZATTOO-HTTP No 1070 33543
junos:DIASPORA-HTTP No 1065 33541
junos:XBOX-HTTP No 1056 33532
junos:XBOX-LIVE-HTTP No 1042 33435
junos:HTTP-VIDEO No 1032 33564
junos:HABBO-HTTP No 1029 33520
junos:IMESH-HTTP No 1026 33511
junos:SOPCAST-HTTP No 1021 33481
junos:YAHOO-MESSENGER-HTTP No 809 33315
junos:HTTP-AUDIO-CONTENT No 806 33565
junos:TEAMVIEWER-HTTP No 495 32992
junos:RTSP-OVER-HTTP No 215 46
junos:HTTP No 64 179
Question: Do you see any suitable application

signatures?
Answer: Although many application signatures exist

with HTIP in their name, the j unos: HTTP might
be helpful.
Step 2.8
Take a closer look at the junos: HTTP application signature by issuing the run
show services application-identification application detail
junos:HTTP command.
lab@srxA-1# run show services application-identification application d,;itail
junos:HTTP
Application Name: junos:HTTP
Application type: HTTP
Description: This signature detects HyperText Transfer Protocol (HTTP), which
is a protocol used by the World Wide Web. It defines how messages
are formatted and transmitted and what actions Web servers and

browsers should take in response to various commands. HTTP usually
runs on TCP port 80.
Application ID: 64
Disabled: No
Number c-f Parent Group(s): 1
Application Groups:
junos:web
Application Tags:
characteristic Can Leak Information
characteristic Supports File Transfer
characteristic Prone to Misuse
characteristic Known Vulnerabilities
characteristic Carrier of Malware
characteristic Capable of Tunneling
risk 5
category Web
Port Mapping:
Default ports: TCP/80,3128,8000,8080
Signature:
Port range: TCP/0-65535
Client-to-server
DFA Pattern:
(\[OPTIONSIHEADIGETIPOSTIPUTIB?DELETEITRACEISEARCHIB?PROPFINDIPROPPATCHIMKCO
LIB?COPYIB?MOVEILOCKIUNLOCKICHECKOUTICHECKINIUNCHECKOUTIVERSION-CONTROLICONT
INUEIREPORTIUPDATEIMKWORKSPACEILABELIMERGEIBASELINE-CONTROLIMKACTIVITYICMDIR
PC_CONNECTIPATCHIUNLINKIPOLLICONNECTIBPROPPATCHI(UN)?SUBSCRIBEIRPC_IN_DATAII
NDEXIREVLOGICCM_POSTIRPC_OUT_DATAIINVOKEIBITS_POSTISMS_POSTIB?PROPPATCHINOTI
FY I X-MS-ENUMATTSIDESCRIBE\])[\s\x07\x0b\xlb] . +
Regex Pattern: None

Server-to-client
DFA Pattern: (. *HTTP/
1 \.[01]\s I.?.?\u [\x3C] ! \ [DOCTYPE\]\u I . ?.?\u[\x3C] \[HTML\]\uI.?. ?\u[\x3C] \?\[
xml\]\ul\[Content-type\J:
) .*
Regex Pattern: None
Minimum data client-to-server: 8
Minimum data server-to-client: 8
Order: 179
Question: Could this application signature be useful

in your situation?
Answer: Yes. From the description and the

parameters in the port mapping and signature
section, this application signature could possibly
help.
www.juniper.net ImplementingAppSecure (Detailed) • Lab 1-11

Question: Should you consider any other application
signatures?
Answer: The answer to this question depends on

whether you plan to create a blacklist or whitelist
AppFW rule set. In this situation, a whitelist
approach is best because the SRX device should
only have to worry about processing HTTP traffic
through an AppFW rule set.
Step 2.9
Navigate to the [edit security application-firewalll hierarchy level
and configure a rule set to only permit HTTP traffic and deny all other traffic. Then,
return to the [edit security policies from-zone Untrust to-zone
Trust] hierarchy level and apply the AppFW rule set to the HTTP security policy.
Also, configure the HTTP security policy to log session initialization attempts and
session closures.
lab@srxA-1# up 1 edit application-firewall rule-sets protect-server
[edit security application-firewall rule-sets protect-server]

lab@srxA-1# set rule HTTP match dynamic-application junos:HTTP

lab@srxA-1# set rule HTTP then permit

lab@srxA-1# set default-rule deny

lab@srxA-1# top edit security policies from-zone Untrust to-zone Trust
[edit security policies from-zone Untrust to-zone Trust]

lab@srxA-1# set policy HTTP then permit application-services
application-firewall rule-set protect-server

lab@srxA-1# set policy HTTP then log session-init session-close

lab@srxA-1#

Question: If you commit the configuration at this
point, will the AppFW logs be recorded locally on the
SRX device?
Answer: The answer depends on what is configured

under the syslog files. If you have a syslog file with
the correct severity and facility levels configured,
the answer is yes. If the correct severity and facility
is not configured, the answer is no.
Step2.10
Navigate to the [edit system sys log] hierarchy level and configure the
AppSecure-logfile to log messages with the severity and facility levels of any
any. Then, configure the log file to only match messages that contain the RT_ FLOW
tag. Commit the configuration when you are finished.
lab@srxl\.-1# top edit system syslog
[edit system syslog]

lab@srxl\-1# set file AppSecure-log any any

[email protected]# set file AppSecure-log match RT FLOW

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step2.11
From the VNC session established with VMware client, disconnect the previous FTP
attempt. Then, attempt the FTP connection using port 8080 again.
www.junip,�r.net Implementing AppSecure (Detailed) • Lab 1-13

'
!,� Fiiename Size; User i Group
Filename Progress
Successfully changed local directory to /llome/lab/ajsec

Looking up ajsecserver.ajsec.juniper.net
Trying ajsecserver.ajsec .juniper .net: BOBO
Connected to ajsecserver.a]sec.juniper.net:8080
220 fvsFT?d 2 0.5) ..
USER !ab
�
Step 2.12
From your assigned SRX device, issue the run show security
application-firewall rule-set all command.
lab@srxA-1# run show security application-firewall rule-set all
Rule-set: protect-server
Rule: HTTP
Dynamic Applications: junos:HTTP
Action:permit
Number of sessions matched: O
Default rule:deny
Number of sessions matched: 1
Number of sessions with appid pending: O
Question: Is the AppFW rule set denying the FTP

session?
Answer: The output suggests that the FTP session is

being denied. However, although the output shows
that the default rule is being hit, it does not
specifically note exactly what is being blocked.
Lab 1-14 • lmplementingAppSecure (Detailed) www,juniper.net

Step2.13
Examine the application system cache (ASC) with the run show service
application-identification application-system-cachecommand
to determine whether there is a result for the recent FTP traffic.
lab@srxl,-1# run show service application-identification
application-system-cache
Application System Cache Configurations:
application-cache: on
nested-application-cache: on
cache-unknown-result: on
cache-entry-timeout: 3600 seconds
pie: 0/0
Logical system name: O
IP address: 172.16.10.100 Port: 8080 Protocol: TCP
Application: FTP Encrypted: No
Question: What information does the output

display?
Answer: The output displays that the FTP session is

being recorded in the ASC. The output also shows
the destination port of 8080.
Step2.14
Examine the AppSecure-log f or the results of the session messages that relate
to the FTP session by issuing the run show log AppSecure-log command.
lab@srxA-1# run show log AppSecure-log
May 10 17:26:28 srxA-1 RT FLOW: RT_FLOW SESSION_CREATE: session created
172.16.l.100/54734->172.16.10.100/8080 None 172.16.1.100/
54734->172.16.10.100/8080 None None 6 HTTP Untrust Trust 24206 N/A(N/A)
ge-0/0/8.0
May 10 17:26:28 srxA-1 RT_FLOW: RT_FLOW SESSION_DENY: session denied
172.16.l.100/54734->172.16.10.100/8080 None 6(0) HTTP Untrust Trust FTP
UNKNOWN N/A(N/A) ge-0/0/8.0 No
May 10 17:26:28 srxA-1 RT FLOW: RT_FLOW_SESSION_CLOSE: session closed
application failure or action: 172.16.1.100/54734->172.16.10.100/8080 None
172.16.1.100/54734->172.16.10.100/8080 None None 6 HTTP Untrust Trust 24206
4(226) 2(132) 1 FTP UNKNOWN N/A(N/A) ge-0/0/8.0 No

Question: What is the reason given for closing the
session?
Answer: The message of application failure

or action is given as the reason for closing the
session.
Part 3: Building Custom Application Signatures
In this lab part, you will configure a custom application signature that you will use in
an AppFW rule set to block specific traffic. Then, you will verify that this traffic is
being blocked by the AppFW rule set.
Step 3.1
From the VNC session established with VMware client, open the Web browser by
double-clicking the Firefox icon.If necessary, you can close the gFTP client now.
Step 3.2
When the Web browser opens, the home page should open to the
http: I I aj secserver.aj sec.juniper. net/test. html URL.Once the
Web browser has opened, click the AJSEC FILES bookmark.
Note
If clicking the AJSEC FILES or the TESTURL
bookmark produces an error, please inform
your instructor immediately.

[!>)AJSEC FlLES [i:!;TESTURL
lnd��f /files
Nan1e J.ast.mo<l.ified S.iz.11 D.!).�_uJption
.> P.�rnnt..Q.ice.�.tQJ:y
El S.BX.i'}_Qi 10-Feb-2011 02,46
� h.�.ci,.d.QSli Ol-Nov-2010 02,04 9.9K
iI
[[) l:!r11L�1i.Q Ol-Nov-2010 02,04 68K 11
�l2il..!L!lill Ol-Nov-2010 02,04 20ij L.l
Step 3.3
Over the next couple steps, you will create a custom application signature that will
block users from accessing the URL that contains the AJSEC files. However, this
custom application signature must allow unhindered HTIP access to the rest of the
VM server.
To begin creating a custom application signature, it is best to copy a current
application signature and make adjustments to it. In the current task, you must
restrict access to a specific part of a URL, but allow access to the rest of the server.
To restrict access in this manner, you must use a custom nested application, which
allows you to specify context values.
From your assigned SRX device, you must first examine a nested application that
uses HTIP as the Layer 7 protocol. Examine the junos:FACEBOOK-ACCESS
nested application by issuing the run show services
application-identification application detail
junos: FACEBOOK-ACCESS command.
lab@srxA-1# run show services application-identification application detail
junos:FACEBOOK-ACCESS
Application Name: junos:FACEBOOK-ACCESS
Application type: FACEBOOK-ACCESS
Description: This signature detects requests to Facebook.com, a social
networking Web site.
Application ID: 311
Disabled: No
Number of Parent Group(s): 1
Application Groups:
junos:social-networking:facebook
Application Tags:
characteristic Loss of Productivity
characteristic Supports File Transfer
characteristic Known Vulnerabilities
characteristic Capable of Tunneling
characteristic Can Leak Information
risk 5
subcategory Facebook
category : Social-Networking
Signature NestedApplication:FACEBOOK-ACCESS
Layer-7 Protocol: HTTP
Chain Order: Yes
Maximum Transactions: 20
Order: 33312
Member(s): 1
Member o
Context: http-header-host
Pattern: (.*\.)?(facebook\.comlfbcdn\.net)(:\d+)?
Direction: CTS
Question: Does this nested application contain the

necessary characteristics for the custom nested
application?
Answer: Yes. The junos: FACEBOOK-ACCESS

application signature is using HTTP as the Layer 7
protocol and has an example of an
http-header-host context that you can use.
Step3.4
Copy the j unos : FACEBOOK-ACCESS nested application by issuing the,
run request services application-identification application
copy junos: FACEBOOK-ACCESS command.
Note
If, when copying the

junos: FACEBOOK-ACCESS application,
you receive an error, commit the
configuration and try again.
Note
If you receive the message about the

application subsystem not responding,
issue the restart
application-identification
operational command to restart the appidd
daemon.

lab@srxA-1# run request services application-identification application copy
junos:FACEBOOK-ACCESS
Please wait while we are copying signature ...

Please wait while we are copying signature .. .

Please wait while we are copying signature ...
Copy application junos:FACEBOOK-ACCESS succeed.
Step 3.5
When copying a built-in application signature, the system copies the application
signature and replaces the junos keyword with the mykeyword. For example,
copying the application signature junos: FACEBOOK-ACCESS creates the custom
application signature my: FACEBOOK-ACCESS.
Navigate to the [edit services application-identification]
hierarchy level and issue a show command to view the recently copied application
signature.
[edit system syslog)
lab@srxl,-1# top edit services application-identification
[edit services application-identification)
lab@srxA-1# show
nested-application my:FACEBOOK-ACCESS
protocol HTTP;
signature my:FACEBOOK-ACCESS {
member mOl {
context http-header-host;
pattern (.*\.)?(facebook\.comlfbcdn\.net) (:\d+)?";
11
direction client-to-server;
maximum-transactions 20;
Question: What must you change in the new

application signature to block access to the AJSEC
FILES URL?
Answer: You must change the signature pattern in

member mo 1 to correctly match the new HTTP
header context. Then, yo_u must add a new
signature member that matches on the context in
the URL. Renaming the nested application name
and signature name to something more appropriate
is also recommended.
Step 3.6
Rename the nested application and signature to my:AJSEC-FILES. Then,
navigate to the [edit services application-identification
nested-application my:AJSEC-FILES signature my:AJSEC-FILES]
hierarchy level.

[edit services application-identification]
lab@srxA-1# rename nested-application my:FACEBOOK-ACCESS to nested-application
my:AJSEC-FILES

lab@srxA-1# edit nested-application my:AJSEC-FILES
[edit services application-identification nested-application my:AJSEC-FILES]

lab@srxA-1# rename signaturemy:FACEBOOK-ACCESS to signaturemy:AJSEC-FILES
[edit services application-identification nested-application my:AJSEC-FILES]

lab@srxA-1# edit signature my:AJSEC-FILES
[edit services application-identification nested-application my:AJSEC-FILES

signature my:AJSEC-FILES] �
lab@srxA-1#
Step 3.7
Configure member mOl with the pattern match of
"(.*\.)?(ajsecserver.ajsec.juniper.net)•.
signature my:AJSEC-FILES]
lab@srxA-1# set member mOl pattern 11 (.*\.)?(ajsecserver.ajsec.juniper.11et)"
Step 3.8
Configure the new member m02 with the context of http-url-parsed, the
pattern of "/files / /files/", and the direction of
client-to-server.
lab@srxA-1# set member m02 context http-url-parsed

lab@srxA-1# set member m02 pattern "/files//files/"

lab@srxA-1# set member m02 direction client-to-server

lab@srxA-1# show
member mOl {
context http-header-host;
pattern "(.*\.)?(ajsecserver.ajsec.juniper.net)";
}
member m02 {
context http-url-parsed;
pattern "/fileslfiles/";

maximum-transactions 20;
Step 3.9
Navigate to the [edit security application-firewall rule-sets
restrict-aj sec-files] hierarchy level. Then, create the rule AJSEC-FILES
that denies traffic when it matches on the nested application signature
my:AJSEC-FILES. Configure the default-rule with the action of permit.
[edit security application-firewall rule-sets restrict-ajsec-filesl
lab@srxP.,-1# top edit security application-firewall rule-sets
restrict-ajsec-files

[email protected]# set rule AJSEC-FILES match dynamic-application my:AJSEC-FILES

[email protected]# set rule AJSEC-FILES then deny

[email protected]# set default-rule permit

lab@srxA-1# show
rule AJSEC-FILES {
match {
dynamic-application my:AJSEC-FILES;
}
then {
deny;
}
default-rule
permit;
Question: Why was the AJSEC-FILES rule not

placed in the protect-server rule set?
Answer: The AJSEC-FILES rule and the default

rule in the protect-server rule set have the
same action of deny. If you attempt to place the
AJSEC-FILES rule in the protect-server
rule set, you receive an error upon commit.
www.juniper.net lmplementingAppSecure (Detailed) • Lab 1-21

Step 3.10
Navigate to the [edit security policies from-zone Untrust
to- zone Trust] hierarchy level. Then, configure the HTTP security policy to
reference the restrict-aj sec-files AppFW rule set. Commit the
configuration when you are finished.
[edit services application-identification nested-application my:AJSEC-E'ILES
lab@srxA-1# top edit security policies from-zone Untrust to-zone Trust

lab@srxA-1# set policy HTTP then permit application-services
application-firewall rule-set restrict-ajsec-files

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.11
From the VNC session established with VMware client, close the Firefox browser.
Then, open the Firefox browser and click the the AJSEC FILES bookmark again.
Ble Edit YJew Hl1tory aookmarkS Iools !:::!elp

....
� Y • �� C3 ft [.@1 !_http://ajsecserver.ajsec.J�n;per.neur;,est.....
@) BADURL @.] GOODURL @IAJSEC FILES �TESTURL
Index of /files
Name Last modified .s.iz!l Description
.,�lllQ.i.r�
E:) SJlX.2!.lQI 10-Feb-2011 02:46
� )?JL<Lr!.ai;x Ol-Nov-2010 02:04 9.9K
� l!r"lllllK..<il Ol-Nov-2010 02:04 68K
� ):,..lliLp..l).f Ol-Nov-2010 02:04 20K
{lo� Ol-Nov-2010 02:04 7.SK
�.!li0.Llmll 17-Feb-2011 01:02 68
� elcar com txt 17-Feb-2011 01:02 68
{lo eic<lC com.zip 17-Feb-2011 01:02 184
{lo .e.i��.r.r&n:iJ.,Z.ill. 17-Feb-2011 01:02 308
� g:QQ.Q. QJ;�
0Q Ol-Nov-2010 02:04 9.8K
� !JQ.9.d.,fill!l Ol-Nov-2010 02:04 68K
� g:QQ.d.,l)..c;IJ Ol-Nov-2010 02:04 21K
{), !).Q.Q.\L.;Qll Ol-Nov-2010 02:04 7.3K
�juniper-rocks docx Ol-Nov-2010 02:04 9.BK
� ss-eicar.com OS-Nov-2010 07:23 77
�ss-eicar.txt 05-Nov-2010 07:22 78
Done

Question: Did the restrict-aj sec-files
AppFW rule set restrict the HTIP transaction?
Answer: No. The HTIP transaction completed as if

the restrict-aj sec-files AppFW rule set
had no effect on it.
Step 3.12
From your assigned SRX device, examine the AppFW rule sets and ASC by issuing
therun show security application-firewall rule-set
restrict-ajsec-£i1es and therun show services
application-identification application-system-cache
commands.
lab@srxA-1# run show security application-firewall rule-set
Rule-set: restrict-ajsec-files
Rule: AJSEC-FILES
Dynamic Applications: my:AJSEC-FILES
Action:deny
Number of sessions matched: O
Default rule:permit
Number of sessions with appid pending: 0

lab@srxA-1# run show services application-identification
application-system-cache
Application System Cache Configurations:
application-cache: on
nested-application-cache: on
cache-unknown-result: on
cache-entry-timeout: 3600 seconds
pie: 0/0
Logical system name: 0
Application: HTTP Encrypted: No
Logical system name: O

Application: FTP Encrypted: No
Step 3.13
Examine the AppSecure -1 og syslog file.


lab@srxA-1# run show log AppSecure-log I last
May 10 21:58:13 srxA-1 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:
172.16.1.100/32803->172.16.10.100/80 junos-http 172.16.1.100/
32803->172.16.10.100/80 None None 6 HTTP Untrust Trust 24662 5(715) S(761) 2
HTTP UNKNOWN N/A(N/A) ge-0/0/8.0 No
172.16.l.100/32804->172.16.10.100/80 junos-http 172.16.1.100/
32804->172.16.10.100/80 None None 6 HTTP Untrust Trust 24663 5(714) S(762) 2
172.16.l.100/32805->172.16.10.100/80 junos-http 172.16.1.100/
32805->172.16.10.100/80 None None 6 HTTP Untrust Trust 24664 5(714) 5(793) 2
May 10 22:04:17 srxA-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
172.16.l.100/38338->172.16.10.100/80 junos-http 172.16.1.100/
38338->172.16.10.100/80 None None 6 HTTP Untrust Trust 24709 N/A(N/A) ge-0/0/
8.0
May 10 22:04:17 srxA-1 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
172.16.l.100/38339->172.16.10.100/80 junos-http 172.16.1.100/
38339->172.16.10.100/80 None None 6 HTTP Untrust Trust 24710 N/A(N/A) ge-0/0/
8.0
May 10 22:04:19 srxA-1 RT FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:
172.16.1.100/38338->172.16.10.100/80 junos-http 172.16.1.100/
172.16.l.100/38339->172.16.10.100/80 junos-http 172.16.1.100/
Question: Can you determine why the

restrict-aj sec-files AppFW rule set is not
working as expected?
Answer: If you have a good understanding of how

the ASC functions, you might understand what is
happening. Before the restrict-aj sec-files
rule set was implemented, the protect-server
rule set was in place. When the protect-server
rule set was employed, an ASC entry was recorded
for the server with destination TCP port 80. When
the restrict-aj sec-files was employed, the
ASC entry for the server on TCP port 80 remained.
This behavior led to the traffic destined to the
AJSEC files section to be allowed when it should
have been denied.

Question: What can you do to resolve the issue?
Answer: You might think that clearing the ASC might

resolve the issue, and this action might appear to
work. However, the same cycle will repeat itself if a
section, other than the AJSEC files section, is
accessed before the AJSEC files section. The only
real solution is to disable the ASC for nested
applications.
Step3.14
Navigate to the [edit services application-identification)
hierarchy level. Once you are there, disable the recording of nested applications in
the ASC and commit the configuration.
lab@srxA-1# top edit services application-identification

lab@srxA-1# set nested-application-settings no-application-system-cache

lab@srxA-1# commit
commit c:::>mplete

lab@srxA-1#
Step3.15
From the VNC session established with VMware client, close the Firefox browser.
Then, open the Firefox browser and click the the AJSEC FILES bookmark again.

@:jAJSEC FILES (<!)1ES1URL
Juniper Rocks!
/
Waiting ror ajsecserver.ajsec.juniper.net. ..
Question: What is the result of attempting to access

the AJSEC files section over HTTP?
Answer: The VM client is unable to access the

AJSEC files section over HTTP.
Question: Are you able to access other sections of

the Web server?
Answer: Yes. The home page that shows "Juniper

Rocks!" displays without issue.
Step 3.16
Return to the open Telnet session for your assigned SRX device. Examine the AppFW
restrict-ajsec-files rule set by issuing the run show security
application-firewall rule-set restrict-ajsec-files command.
Then, examine the AppSecure-log syslog file to find the
RT_FLOW_SESSION_DENY logs for the blocked session.


[email protected]# run show security application-firewall rule-set
Rule-set: restrict-ajsec-files
Rule,: AJSEC-FILES
Dynamic Applications: my:AJSEC-FILES
Action:deny
Default rule:permit
Number of sessions with appid pending: O

[email protected]# run show log AppSecure-log I match DENY I last 10
May 10 18:57:43 srxA-1 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
172.16.l.100/52908->172.16.10.100/80 junos-http 6(0) HTTP Untrust Trust HTTP
MY-AJSEC-FILES N/A(N/A) ge-0/0/8.0 No
Question: Is the SRX device denying the requests to

access the AJSEC file section?
Answer: Yes. The SRX device is denying attempts to

access the AJSEC file section.
Part 4: Implementing AppTrack
In this lab part, you will configure App Track to record statistics about the sessions
that pass through the router.
Step 4.1
To complete this lab part, you will first need to configure an interface policer that
limits the amount of bandwidth that can ingress the ge-0/0/9 interface. You must
apply this policer to extend the transfer sessions so you can see the features of
AppTrack in action.
Navigate to the [edit firewall policer ftp-policer] hierarchy level
and configure a band wid th-limit of lm and a burst -size-limit of 20k.
Then, configure an action of discard. Then, apply the policer to the ge-0/0/9
interface as an input policer.
lab@srxA-1# top edit firewall policer ftp-policer
www.junip,�r.net Implementing AppSecure (Detailed) • Lab 1-27

[edit firewall policer ftp-policer]

lab@srxA-1# set if-exceeding bandwidth-limit lm

lab@srxA-1# set if-exceeding burst-size-limit 20k

lab@srxA-1# set then discard

lab@srxA-1# show
if-exceeding {
bandwidth-limit lm;
burst-size-limit 20k;
then discard;

lab@srxA-1# top edit interfaces ge-0/0/9
[edit interfaces ge-0/0/9]

lab@srxA-1# set unit O family inet policer input ftp-policer

lab@srxA-1#
Step4.2
Navigate to the [edit security] hierarchy level and configure AppTrack to
generate a message upon session creation.
lab@srxA-1# top edit security
[edit security]
lab@srxA-1# set application-tracking first-update
[edit security]
lab@srxA-1#
Step4.3
Apply application tracking to the Trust zone. Commit the configuration when you
are finished.
[edit security]
lab@srxA-1# set zones security-zone Trust application-tracking
[edit security]
lab@srxA-1# commit
commit complete
Step4.4
From the VNC session established with VMware client and close the Firefox browser
if necessary. Then, double-click the gFTP client icon.

fTP Local fiemote a.ookmark.S Jransf'ers LQ.gging Toolj_ Help
.........-1
---�Pass:
····
om s
l/h e11ab/aJ ec ·························-····---···· .. - - ···················-�
(Local] (All Ries] ..
!t("" '
11 ·!,!
Rl@name I Size User Group _(
i I'
L - ___ ______J.,
---====:i: I
�''�- --
- ---·_... !
.---- �
---T�I
..... . ..... . ........., , ;...;..

- -;j"···-
gFTP 2.0.18. Copyright (C} 1998·2003 Brian Masney <n1<1<,:rmyll@g:-tµ.ur9>. If you have any questions, comments. or suggestions
about this program, please reel free to email them to me. '\'bu can always t'ind out the latest news about gFTPrrom my website at
http://Www.grtp.org/
gFTP comes with ABSOWTELY NO WARRANTY: for details. see the COPYING file. This Is free sortware, and you are welcome to
redistribute It under certain conditions: ror details, see the COPYING rile
Successru11y changed local directory to Jllome/lab/aJsec
Step 4.5
Open a connection to the aj secserver.aj sec.juniper. net server using the
default FTP port of 21, username of lab, and a password of labl23. Then, begin
to download the file named 1 OMB.txt.
\mome/lab/ajsec lfhome/lab
__
l1::.1?.t::�D !� Ales] ajse_cserver.ajsec.Juniper.net
. [FTP} (Cached) {All Ales]-+-
&., Filename Size
[�] i�
r Fllen�me
't.. :
. .. ........ .. . .. ·········· ·· · Slze �User
4:095
-
0
Group
CJ .grtp 4.096 500 500

CJ .mozilla 4,096 500 500
Q .bash_hlstory 884 500 500
0 .bash_logout 33 soo 500
C .bash_profile 176 500 500
Q .bashrc 124 500 500
e
' .zshrc 658 500 500
150 Here comes the directory listing

226 Directory send CK.
F�'l..SV
227 Entering ?"nssM? Mode (172 •.16.10,100,133,2311
RFffi Jhom�,li.'lb/lOMB.txt
150 Opemng BINARY ,node data connection for /home/labllOMB.txt (10485i60 bytes).

Step 4.6
From your assigned SRX device, examine the session table to obtain the session IDs
of the FTP control and data sessions by issuing the run show security flow
session command.
[edit security]
lab@srxA-1# run show security flow session
Session ID: 25593, Policy name: FTP/8, Timeout: 1752, Valid
Resource information : FTP ALG, 2, 0
In: 172.16.1.100/39113 --> 172.16.10.100/2l;tcp, If: ge-0/0/8.0, Pkts: 14,
Bytes: 669
Out: 172.16.10.100/21 --> 172.16.l.100/39113;tcp, If: ge-0/0/9.0, Pkts: 13,
Bytes: 914

In: 172.16.1.100/58637 --> 172.16.10.100/22424;tcp, If: ge-0/0/8.0, Pkts:
1982, Bytes: 103648
Out: 172.16.10.100/22424 --> 172.16.l.100/58637;tcp, If: ge-0/0/9.0, Pkts:
2451, Bytes: 3675060
Total sessions: 2
Question: How can you determine which session is

the FTP control session, and which session is the
FTP data session?
Answer: The FTP control session has significantly

fewer packets transferred than the FTP data
session. In the previous output, the second session
is the FTP data session.The control session can
also be identified by the session that is using port
21.
Question: What are the session IDs for the FTP

control and data sessions?
Answer: In the previous output, the FTP control

session has a session ID of 25593, and the FTP
data session has a session ID of 25595. The
session IDs on your SRX device might be different.
Step 4.7
Once the file transfer is complete, examine the AppTrack counters by issuing the
run show security application-tracking counters command.
Lab 1-30 • lmplementingAppSecure(Detailed) www,juniper.net

Advanced Ju nos Secur ity
[edit security]
lab@srxl,-1# run show security application-tracking counters
Application tracking counters:
AppTrack counter type Value

Session create messages 6
Session close messages 5
Session volume updates 0
Failed messages 0
Question: Are any session volume update messages

present? Why?
Answer: No. By default, a session must last longer

than five minutes for the Junos OS to generate a
session volume update message. The FTP transfer
only lasted a little over two minutes.
Step4.8
Examine the AppTrack log messages for the logs pertaining to the FTP data session
by issuing the run show log AppSecure-log I match
ftp-data-session-id command, where the match condition is the session ID
of the FTP data session that you obtained in step 4.6.
[edit security]
lab@srxl\.-1# run show log AppSecure-log I match ftp-data-session-id
May 11 16:45:04 srxA-1 RT_FLOW: APPTRACK_SESSION_CREATE: AppTrack session
created 172.16.l.100/58637->172.16.10.100/22424 None ftp-data UNKNOWN
172.16.l.100/58637->172.16.10.100/22424 None None 6 FTP Untrust Trust 25595
N/A N/A N/A
May 11 16:47:27 srxA-1 RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed
TCP FIN: 172.16.l.100/58637->172.16.10.100/22424 None ftp-data UNKNOWN
6453(336464) 7245(10863956) 144 N/A N/A N/A
Question: What is the elapsed time of the FTP

transfer?
Answer: The elapsed time of the FTP transfer can be

seen in the session close log. In the output
displayed, the session lasted a total of 144
seconds. The elapsed time of your FTP transfer
might be different.
www.junip,�r.net Implementing AppSecur e(Detailed) • Lab 1-31

Step4.9
Configure AppTrack to generate session volume update messages when a session is
active for 2 minutes.Commit the configuration when you are finished.
[edit security]
lab@srxA-1# set application-tracking session-update-interval 2
[edit security]
lab@srxA-1# coilllllit
commit complete
Step4.10
From the VNC session established with the VMware client, begin the FTP transfer of
the 1 OMB.txt file again. Overwrite the existing 1 OMB. txt file when you are
prompted to do so.
gFTP 2.0.18
£TP J,.ocal fiemote a.ookmarkS ]ransrers LQgging Tool.5. Help
EJ L.li:J
.. .. . . . . . . . . . . . . . - -· · · · .·;·, ==
= = ·=· ·=· · ··=· · · :::::. · ·, ·:·= · =· ==· · ·= · =··· = · · ·
:; � tlost [•i:•::.:'.:'.'.�rajse:ju�;P.�'..��t Port !,iser i1ab
!
i,i,ome,lab/ajsec j j..., l/home,1ab
�
{Local} (All Files} �secserver.aisec.juniper.net [FTP] [All Files]• ···------
_________·-··-------,
!,; Rlename Size User Group
The ronowing rile(s) exist on both the local and remote computer
10,485,760 lab Please select what you would like to do
J�
O lOMB.txt � 500
500
Alename [ ajsecserver.<. local files�st_1 Action
i _ _ _ _ 500
_ _ _ ___ ___ ____
� 500
··1
I 500
I " 500
� 500
Rlename Proqress
....
I I
......•....
overwrite Resume S�p Rle ]
e
···········---�· Se1 ct_AJ1 _____....--�
e e ect. Al l
[_·-·-·· D s l _=1
227 Entenng Passive Mode (172.16,10,100,
P.1! ri-t ;horn�.,1.:�b/lOMB.V\t
150 Opening BINARY mode data connectior
�---------------- - - �
226 File send OK.
Successfully transferred /home/lab/lOMB.txt at 66.90 KB/s
Successruny changed mode of JhomeJlab/ajsec/lOMB.txtto 644
�
Step4.11
From your assigned SRX device, issue the run show security flow
session command to obtain the FTP data session ID.
[edit security]
In: 172.16.1.100/44035 --> 172.16.10.100/2l;tcp, If: ge-0/0/8.0, Pkts: 19,
Bytes: 900

Out: 172.16.10.100/21 --> 172.16.1.100/44035;tcp, If: ge-0/0/9.0, Pkts: 16,
Bytes: 1184

In: 172.16.1.100/49470 --> 172.16.10.100/32774;tcp, If: ge-0/0/8.0, Pkts:
3331, Bytes: 174252
Out: 172.16.10.100/32774 --> 172.16.l.100/49470;tcp, If: ge-0/0/9.0, Pkts:
4093, Bytes: 6137772
Total sessions: 2
Question: What is the session ID for the FTP data

session?
Answer: In the previous output, the session ID for

the FTP data session is 25602. The session ID for
the data session on your SRX device might be
different.
Step4.12
Once the FTP transfer is complete, examine the AppTrack counters by issuing the
run show security application-tracking counters command.
[edit security]
lab@srxA-1# run show security application-tracking counters
Application tracking counters:
AppTrack counter type Value

Session create messages 7
Session close messages 6
Session volume updates 3
Failed messages 0
Question: Why does more than one session volume

update message exist when the session only lasted
a little over two minutes?
Answer: The open FTP control session has been

active the entire time; this accounts for the
existence of more than one session volume update
message. The output on your SRX device might
differ slightly from the previous output.
www.juniper.net lmplementingAppSecure (Detailed) • Lab 1-33

Step4.13
Examine the App Track log messages by issuing the run show log
AppSecure-log I match ftp-data-session-id command, where the
match condition is the session ID of the FTP data session that you obtained in
Step 4.12.
[edit security]
lab@srxA-1# run show log AppSecure-log [ match ftp-data-session-id
May 11 17:02:49 srxA-1 RT_FLOW: APPTRACK_SESSION_CREATE: AppTrack session
created 172.16.l.100/49470->172.16.10.100/32774 None ftp-data UNKNOWN
N/A N/A N/A
May 11 17:04:48 srxA-1 RT_FLOW: APPTRACK_SESSION_VOL_UPDATE: AppTrack volume
update: 172.16.l.100/49470->172.16.10.100/32774 None itp-data UNKNOWN
5013(262148) 6138(9205272) 120 N/A N/A N/A
May 11 17: 05:11 srxA-1 RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed
TCP FIN: 172.16.1.100/49470->l 72.16.10.100/32774 None ftp-data UNKNOWN
5901(308684) 7244(10862456) 143 N/A N/A N/A
Question: At which point of the active session did

the Junos OS generate the session volume update
log?
Answer: The session volume update log was

generated 120 seconds from the time the session
became active.
Question: How many bytes did the server send in at

the time the session volume update message was
generated?
Answer: In the previous output, the server had sent

9,205,272 bytes at the time of the session volume
update message. Your results might differ from this
value.
Step4.14
Exit configuration mode and log out of your assigned SRX device.
[edit security]
lab@srxA-1# exit configuration-mode
Exiting configuration mode
lab@srxA-1> exit

srxA-1 (ttyuO)
login:
0 Tell your instructor that you have completed this lab.
Management Network Diagram

ge-0/0/0(on allstudentdevices)
1:1:111(
�
Workstations
Management Addressing
srxA-1 srxD-1 I
srxA-2 I srxD-2 I
srxB-1 vr-device I
srxB-2 Server
srxC-1 Gateway
srxC-2 Term Server
Server Note: Your instructor will provide address and access information.

Pod A Network Diagram: Implementing

AppSecure Lab
�
� Internet
.
'--'
1
·;--------! I
VMClient
172.16.1.100
UntrustZone
ge-0/0/8
__ __
172.16.1.1/24
........
srxA-K
K = pod
---(1or2)
iilil
VMServer
172.16.10.100
y��20�3J11n.1p:rN;i::�. lnc Allrlfbt'$ re$erve(! JUn�.r Worldwide Education Services ._ 1un1

---- A.... --��-- A
Pod B Network Diagram: Implementing

AppSecure Lab
�:--J;;J, VM Client
--../.
172.16.1.100
U ntrustZone
ge-0/0/8
172.16.1.1/24
<(=pod
---(1or2)
�-.L--�
srxB-K
VMServer
172.16.10.100

Pod C Network Diagram: Implementing

AppSecure Lab
�•-• ��-v��lie�t
172.16.1.100
UntrustZone
ge-0/0/8
172161.1/24
,--""""'----, X=pod
--- (1or2)
srxC-K
VMServer
172.16.10.100
Pod D Network Diagram: Implementing

AppSecure Lab
A,-- --Q
� VMClient
172.16.1.100
UntrustZone
Pft-0/0/8
17 2161.1/24
.....-.......----, ---X=pod
(1or2)
srxD-K
ge-0/0/9
17216.10.1/24
Trust Zone
•
,_/ .....
VMServer
172.16.10.100
www.junip,3r.net lmplementingAppSecure (Detailed) • Lab 1-37


Lab
Implementing Layer 2 Security (Detailed)
Overvh�w
In this lab, you will implement Layer 2 security. You will work with the remote student team
within your pod to verify Ethernet switching and transparent mode operations. You will
also configure Layer 2 security, and verify the results.
Verify Ethernet switching behavior.
Implement transparent mode.
Secure Layer 2 traffic.
www.juniper.net Implementing Layer 2 Security (Detailed} • Lab 2-1

Part 1: Logging In Using the CLI
In this lab part, you load the starting configuration for Lab 2. Next, you will examine
Ethernet switching behavior. You will configure two interfaces with Ethernet
switching and will verify the results by passing Layer 2 traffic through your
SRX device.
Note
you the details needed to access your
assigned device.
Step 1.1
Ensure that you know to which student device you have been assigned. Check with
your instructor if you are not certain. Consult the Management Network Diagram to
determine the management address of your student device.

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

and IP address used in the output examples in this
lab are for srxA-1, which uses 10.210.35.131 as its
management IP address. The actual management
address varies between delivery environments.
Step 1.2
Access the command-line interface (CLI) at your station using either the console,
Telnet, or SSH as directed by your instructor.
Protocol: [ T ehet :::::··::::: v.j
Hostname:
Port:
O Show quick connect on startup 0 Save session

0 Open in a tab
I: Connecl ,J I Concel J
Lab 2-2 • Implementing Layer 2 Security (Detailed) www._juniper.net

Step 1.3
Log in as user lab with the password labl23. Enter configuration mode and load
the lab2-start. configfrom the /var/home/lab/ajsec/ directory. Commit the
configuration when complete.
srxA-1 (ttyuO)
login: :tab
Password:

Enterinsr configuration mode
[edit]
lab@srxl,-1# load override ajsec/lab2-start.aonfig
load complete
[edit]
lab@srxl\-1# coIIII!lit
commit complete
[edit]
lab@srxl\-1#
Step 1.4
Check the status of the switched interface you configured using the run show
ethernet-switching interfaces command.
[edit]
lab@srxl'.-1# run show ethernet-switching interfaces
Interface State VLAN members Tag Tagging Blocking
ge-0/0/4.0 up vr241 241 tagged unblocked
Question: Is the correct VLAN associated with

interface ge-0/0/4?
Answer: As shown in the output, the VLAN

associated with interface ge-0/0/4 should match
the VLAN displayed on the lab diagram.
Note
In the next two steps, you will configure the
ge-0/0/1 and ge-0/0/2 interfaces. These
interfaces will be used for testing the
Ethernet switching connection to the pod
team member's SRX device.
www.juniper.net Implementing Layer 2 Security (Detailed) • Lab 2-3

Step i5
Navigate to the [edit interfaces] hierarchy. If your assigned device is SRX1,
configure the ge-0/0/2 interface for vlan-tagging. If your assigned device is
SRX2, configure the ge-0/0/1 interface for vlan-tagging. Also specify the
VLAN ID associated with your pod team member's Juniper customer network, and
configure the IP address 1 72. 20. _y. 50/24, where the value of _y is the VLAN
associated with your pod team member's Juniper customer network.
[edit]
lab@srxA-1# edit interfaces
[edit interfaces]
lab@srxA-1# set interface vlan-tagging
[edit interfaces]
lab@srxA-1# set interface unit Remote-VLAN-ID family inet address
172. 20 .y. 50/24
[edit interfaces]
lab@srxA-1# set interface unit Remote-VLAN-ID vlan-id Remote-VLAN-ID
[edit interfaces]
lab@srxA-1# show interface
vlan-tagging;
unit 242 {
vlan-id 242;
family inet {
address 172.20.242.50/24;
[edit interfaces]
lab@srxA-1#
Step 1.6
Add the interface you configured in the previous step to the untrus t zone. If your
assigned device is SRX1, add the ge-0/0/2 interface. If your assigned device is
SRX2, add the ge-0/0/1 interface. Configure the host-inbound-traffic
command to allow inbound ping and ftp traffic on the interface.
[edit interfaces]
lab@srxA-1# top set security zones security-zone untrust interface
interface.Remote-VLAN-ID host-inbound-traffic system-services ping
[edit interfaces]
lab@srxA-1# top set security zones security-zone untrust interface
interface.Remote-VLAN-ID host-inbound-traffic system-services ftp
[edit interfaces]
lab@srxA-1# top show security zones security-zone untrust
interfaces {
ge-0/0/3.0;
ge-0/0/2.242
host-inbound-traffic
Lab 2-4 • Implementing Layer 2 Security (Detailed) www.juniper.net

system-services
ping;
ftp;
Step 1.7
If your assigned device is SRX1, configure the ge-0/0/1.0 interface for family
ethernet-swi tching with port-mode access. If your assigned device is
SRX2, configure the ge-0/0/2.0 interface for family ethernet-switching
with port-mode access. Also configure the interface with the VLAN member
vrlocal-Juniper-VLAN, where the value of local -Juniper-VLAN is the
remainder of the VLAN ID associated with your local Juniper customer network.
Commit the configuration when complete.
[edit interfaces]
lab@sr��-1# set interface.a family ethernet-switching port-mode access
[edit interfaces]
lab@sr�-1# set interface.a family ethernet-switching vlan members
vrlocal -Juniper-VLAN
[edit interfaces]
lab@srxi�-1# show interface
unit a {
family ethernet-switching
port-mode access;
vlan {
members vr241;
[edit interfaces]
lab@srxl,-1# commit
commit complete
Step 1.8
Check the status of the switched interface you configured using the run show
ethernet-switching interfaces command.
[edit interfaces]
lab@srxJ,-1# run show ethernet-switching interfaces
Interface State VLAN members Tag Tagging Blocking
ge-0/0/1..0 up vr241 241 untagged unblocked
ge-0/0/4.0 up vr241 241 tagged unblocked

Question: How many VLAN members are now
associated with Ethernet switching?
Answer: As shown in the output, you should see two

Ethernet switching interfaces associated for your
local Juniper customer network VLAN. If you do not
see two interfaces displayed, double-check your
configuration.
Ensure that the remote student team within your pod has finished this
section before continuing.
Step 1.9
Note
This lab step requires you to open a
separate Telnet session to the virtual router
to emulate an external host.
Keep the current Telnet session
established with your assigned SRX device
open to monitor results.
The virtual router is a J Series Services
Router configured as several logical
devices. Refer to the Management Network
Diagram for the IP address of the vr-device.
Open a separate Telnet session to the virtual router.
Protocol:
Hostname:
Port e=:J Firewall [None ··----··--··- ················· ,.,]
O Show quick connect on startup � Save session

� Open in a tab
Connect J I Cancel I
Lab 2-6 • Implementing Layer 2 Security (Detailed) www._juniper.net

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

srxA-l al labl23
srxA-2 a2 labl23
srxB-l bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttydO)
login: 11sername
Password:
NOTE: This router is divided into many virtual routers used by different teams.
Please only configure your own virtual router.
You must: use 'configure private' to configure this router.
al@vr-de,vice>
Step 1.11
From the Telnet session established with the virtual router, test your recently
configured Ethernet switching implementation by initiating a rapid ping test to the
remote team's I 72. 20. y. so address that was configured in step 1.5, where yis
the value of the VLAN associated with your local Juniper customer network. Source
the connection from the virtual router's routing instance associated with your local
Juniper customer network. Refer to the lab network diagram if needed.
al@vr-device> ping 172.20.�.50 routing-instance vrlocal-Juniper-VLAN rapid
PING 172.20.241.50 (172.20.241.50): 56 data bytes
--- 172.20.241.50 ping statistics ---

5 packets transmitted, O packets received, 100% packet loss
al@vr-device>

Question: Was the ping test successful? Why or why
not?
Answer: As shown in the output, the ping test was

not successful, because an interface in access
port-mode does not allow an inbound VLAN-tagged
frame.
Step 1.12
From your assigned SRX device, change the port-mode on your untrust family
ethernet-switching interface from access to trunk. If your assigned device is
SRX1, modify the ge-0/0/1 interface. If your assigned device is SRX2, modify the
ge-0/0/2 interface. When finished, navigate to the top of the configuration hierarchy
and commit the configuration.
[edit interfaces]
lab@srxA-1# set interface.O family ethernet-switching port-mode trunk
[edit interfaces]
lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
0 Ensure that the remote student team within your pod has finished this
Step 1.13
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, initiate the piing test
again.
al@vr-device> ping 172.20.y.so routing-instance vrlocal-Juniper-VLAN rapid
PING 172.20.241.50 (172.20.241.50): 56 data bytes
. ! ! ! !
--- 172.20.241.50 ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 2.109/3.216/4.305/0.946 ms
Lab 2-8 • Implementing Layer 2 Security (Detailed) www.Jiuniper.net

Question: Was the ping test successful?
Answer: As shown in the output, the ping test

should be successful.
Note
You might see the first ping response time
out due to the ARP entry being resolved.
Step 1.14
From your assigned SRX device, review the current VLAN member configuration for
Ethernet switching by issuing the command show vlans and answer the following
question.
[edit]
lab@srxl,-1# show vlans
vr241 {
vlan-id 241;
Question: Does the current VLAN member

configuration allow the Ethernet switching hosts to
route Layer 3 traffic through the SRX device?
Answer: The answer is no. The current vlan

configuration does not include a Layer 3 interface.
Step 1.15
In this step, you will configure the vlan interface that will be used to route Layer 3
traffic for the Ethernet switching hosts. Issue the command set interfaces
vlan unitlocal-Juniper-VLAN family inet address
172. 20 .y.1/24, where yis the value of the VLAN associated with your local
Juniper customer network.
[edit]
[email protected]# set interfaces vlan unit local-Juniper-VLAN family inet address
172. 2'0 .y.1/24
[edit]
[email protected]# show interfaces vlan
unit 241 {
family inet
address 172.20.241.1/24;

Step 1.16
Apply the vlan interface you created in the previous step as a Layer 3 interface with
the command set vlans vr local-Juniper-VLAN 13-interface
vlan.local-Juniper-VLAN, where local-Juniper-VLANis the value of
the VLAN associated with your local Juniper customer network.
[edit]
lab@srxA-1# set vlans vrlocal-Juniper-VLAN 13-interface vlan. local-Juniper-VLAN
Step 1.17
Add the interface you configured in the previous step to your local Juniper customer
network security zone. Configure the host-inbound-traffic command to
allow inbound ping on the interface. When finished commit the configuration.
[edit]
lab@srxA-1# set security zones security-zone Juniper-local interface
vlan.local-Juniper-VLAN host-inbound-traffic system-services ping
lab@srxA-1# show security zones security-zone Juniper-local

interfaces {
vlan.241 {
host-inbound-traffic {
system-services {
ping;
[edit]
lab@srxA-1# commit
commit complete
Step 1.18
From the Telnet session established with the virtual router, initiate a rapid ping test
to the Internet host address 172.31.15.1. Source the connection from the virtual
router's routing instance associated with your local Juniper customer network. Refer
to the lab network diagram if needed.
al@vr-device> ping 172.31.15.1 routing-instance vrlocal-Juniper-VLAN rapid
PING 172.31.15.1 (172.31.15.1): 56 data bytes
! ! ! ! !
--- 172.31.15.1 ping statistics
al@vr-device>

Question: Were your pings to the Internet host

successful?
Answer: As shown in the output, your pings should

be successful to the Internet host. If the pings
failed, double-check your configuration and notify
your instructor.
0 Do not proceed to the next lab part until directed by the instructor to do
so.
Part 2: Configuring Transparent Mode
In this lab part, you become familiar with transparent mode operations. The rest of
the lab steps for this part will be performed on SRX1. You will remove any
unnecessary configuration from your assigned SRX device, and configure the ge-0/
0/1 and ge-0/0/4 interfaces to pass Layer 2 traffic in transparent mode. You will
also configure transparent mode device management.
Note
Perform the rest of this lab part only on the

SRX1 device. Both teams should be
working only from SRX1!
Note
In the following steps you will lose access to

the SRX1 device through the management
interface. You must access the SRX1
device through the console port.
Step 2.1
Delete the [edit security] and [edit routing-options] configuration
hierarchies.
[edit]
lab@srxA-1# delete security
[edit]
lab@srxA-1# delete routing-options
Step 2.2
Delete the [edit firewall] and [edit vlans] configuration hierarchies.
Then, delete all of the interfaces.

[edit]
lab@srxA-1# delete firewall
[edit]
lab@srxA-1# delete vlans
[edit]
lab@srxA-1# delete interfaces
Step2.3
Navigate to the [edit interfaces) hierarchy. Configure the ge-0/0/:L interface
forvlan-tagging,family bridge interface-mode trunk,and
vlan-id-list 241-248.
[edit]
[edit interfaces]
lab@srxA-1# set ge-0/0/1 vlan-tagging
[edit interfaces]
lab@srxA-1# set ge-0/0/1 unit O family bridge interface-mode trunk
[edit interfaces]
lab@srxA-1# set ge-0/0/1 unit O family bridge vlan-id-list 241-248
Step2.4
Configure the ge-0/0/4 interface forvlan-tagging, family bridge
interface-mode trunk, andvlan-id-list 241-248.
[edit interfaces]
lab@srxA-1# set ge-0/0/4 vlan-tagging
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit O family bridge interface-mode trunk
[edit interfaces]
lab@srxA-1# set ge-0/0/4 unit O family bridge vlan-id-list 241-248
Step2.5
Navigate to the [edit security) hierarchy. Create a security zone named
Untrust-L2. Apply the ge-0/0/1 interface to the zone.
[edit interfaces]
[edit security]
lab@srxA-1# set zones security-zone Untrust-L2 interfaces ge-0/0/1.0
[edit security]
lab@srxA-1#

Step2.6
Create a security zone named Juniper-L2. Apply the ge-0/0/4 interface to the
zone.
[edit security]
lab@srxA-l#set zones security-zone Juniper-L2 interfaces ge-0/0/4.0
Step2.7
Create a security policy named Allow that permits all traffic from the
Juniper-L2 zone to the Untrust-L2 zone.
[edit security]
lab@srxA-1# set policies from-zone Juniper-L2 to-zone Untrust-L2 policy Allow
match source-address any
[edit security]
lab@srxl,-1# set policies from-zone Juniper-L2 to-zone Untrust-L2 policy Allow
match destination-address any
[edit security]
match application any
[edit security]
then permit
Step2.8
In this step, you will configure a routing instance that will forward the Layer 2
transparent mode traffic. Navigate to the [edit routing-instances
GIG-Switch] hierarchy. Configure the routing instance with instance-type
virtual-switch. Add the ge-0/0/1 and ge-0/0/4 interfaces to the routing
instance.
[edit security]
lab@srxll-1# top edit routing-instances GIG-Switch
[edit routing-instances GIG-Switch]

lab@srxl\-1# set instance-type virtual-switch

lab@srxP,-1# set interface ge-0/0/1.0

lab@srxP,-1# set interface ge-0/0/4.0
Step2.9
Within the routing instance, configure a bridge-domain named Bridgel with
domain-type bridge. Add the VLAN ID local-Juniper-VLAN, where the
value of local-Juniper-VLAN is the VLAN ID associated with SRXl's local
Juniper customer network.
lab@srxl'.-1# set bridge-domains Bridgel domain-type bridge


lab@srxA-1# set bridge-domains Bridgel vlan-id local-Juniper-VLAN

lab@srxA-1# show
instance-type virtual-switch;
interface ge-0/0/1.0;
interface ge-0/0/4.0;
bridge-domains {
Bridge! {
domain-type bridge;
vlan-id 241;
Step2.10
Perform a commit check command on the configuration.
lab@srxA-1# commit check
warning: Interfaces are changed from route mode to transparent mode. Please
reboot the device or all nodes in the HA cluster!
configuration check succeeds
Question: Did you receive a warning message when

issuing this command?
Answer: You should see a warning regarding

changing from route mode to transparent mode.
The SRX device requires a reboot after changing
between these modes.
Step2.11
Commit the configuration, and then reboot the SRX device.
lab@srxA-1# commit
commit complete
warning: Interfaces are changed from route mode to transparent mode. Pl.ease
reboot the device or all nodes in the HA cluster!

lab@srxA-1# run request system reboot
Reboot the system? [yes,no] (no) yes
Shutdown NOW!
[pid 3049]

[edit]
[email protected]#
*** FINAL System shutdown message from [email protected] ***
System �;oing down IMMEDIATELY

...TRIMMED ...
srxl\.-1 [ttyuO)
login:
Step2.12
Log back in as user lab with the password labl23 after the device has finished
· rebooting.
srxll.-1 (ttyuO)
login: 2ab
Password:

[email protected]>
Step2.13
From the Telnet session established with the virtual router, test your transparent
mode configuration by initiating a continuous ping test to the SRX2 team's
172. 20 .y. 50 address, where yis the value of the VLAN associated with your local
Juniper customer network.Source the connection from the virtual router's routing
instance associated with your local Juniper customer network. Refer to the lab
network diagram if needed.
al@vr-device> ping 172.20.y.so routing-instance vrlocal-Juniper-VLAN
PING 17:;:.20.241.50 (172.20.241.50): 56 data bytes
64 byteE: from 172.20.241.50: icmp_seq=O ttl=64 time=3.253 ms
64 byteE: from 172.20.241.50: icmp_seq=l ttl=64 time=3.042 ms
64 byteE: from 172.20.241.50: icmp_seq=2 ttl=64 time=2.992 ms
64 bytes from 172.20.241.50: icmp_seq=3 ttl=64 time=2.685 ms
Question: Were your pings successful?
Answer: As shown in the output, your pings should

be successful. If the pings failed, double-check your
configuration and notify your instructor.
Step2.14
Return to the session established with your assigned SRX1 device.
From your assigned SRX1 device, issue the command show security flow
session, and answer the question that follows.
lab@srxA-1> show security flow session
Session ID: 8829, Policy name: Allow/4, Timeout: 2, Valid
In: 172.20.241.10/116 --> 172.20.241.50/58070;icmp, If: ge-0/0/4.0, Pkts: 1,
Bytes: 102
Out: 172.20.241.50/58070 --> 172.20.241.10/116;icmp, If: ge-0/0/1.0, Pkts: 1,
Bytes: 102
Question: Does the output display the security

policy name that is permitting the traffic between
ge-0/0/4 and ge-0/0/1?
Answer: The answer is yes. The output displays the

security policy named Allow, which is permitting
the traffic.
Step 2.15
From the Telnet session established with the virtual router, press Ctrl + c to
terminate the ping.
--- 172.20.241.50 ping statistics ---

al@vr-device>
Do not proceed to the next lab part until directed by the instructor to do
so.
Part 3: Securing Layer 2 Traffic in Transparent Mode
In this lab part, you secure Layer 2 traffic in transparent mode. The rest of the lab
steps for this part will be performed on SRX1. You will configure a security zone
policy to only allow FTP traffic from the virtual router host to the SRX2 host, and
verify the results.
Note
Perform the rest of this lab part only on the
SRX1 device. Both teams should be
working only from SRX1!

Step3.1
From assigned SRX1 device, navigate to the [edit security policies]
hierarchy. Modify the existing security policy Allow to only permit the predefined
junos-ftp application traffic between the Juniper-L2 and Untrust-L2
zones. When finished, commit the configuration.
[edit]

lab@srxA-1# delete from-zone Juniper-L2 to-zone Untrust-L2 policy Allow match
application

lab@srxA-1# set from-zone Juniper-L2 to-zone Untrust-L2 policy Allow match
application junos-ftp

lab@srxA-1# commit
commit complete

lab@srxl,-1#
Step3.2
From the Telnet session established with the virtual router, initiate an FTP
connection to the SRX2 team's l 72. 20 .y. 50 address, where yis the value of the
VLAN associated with your local Juniper customer network. Source the connection
from the virtual router's routing instance associated with your local Juniper
customer network.
al@vr-device> ftp 172.20.y.so routing-instance vrlocal-Junip�r-VLAN
Connected to 172.20.241.50.
220 srxl'.,-2 FTP server (Version 6.OOLS) ready.
Name (172.20.241.50:al):
Question: Is the FTP connection successful?
Answer: The FTP connection should be successful.
Step3.3
Press Ctrl + c to terminate the FTP connection, and then initiate the same rapid ping
test performed in the previous lab part to the SRX2 address.
220 srxA-2 FTP server (Version 6.00LS) ready.
Name (172.20.241.50:al): Ac

al@vr-device> ping 172.20.y.so routing-instance vrlocal-Juniper-VLAN rapid
PING 172.20.241.50 (172.20.241.50): 56 data bytes
--- 172.20.241.50 ping statistics ---

Question: Is the ping test successful?
Answer: The ping test should not be successful. The

security policy has denied the ping traffic.
Step 3.4
From assigned SRX1 device, create a family bridge firewall filter named TM-Filter
to discard all traffic from interface
ge-0/0/4.0.
lab@srxA-1# top
[edit]
lab@srxA-1# set firewall family bridge filter TM-Filter term 1 from interface
ge-0/0/4.0
[edit]
lab@srxA-1# set firewall family bridge filter TM-Filter term 1 then discard
[edit]
lab@srxA-1#
Step 3.5
Apply the TM-Filter as a family bridge output filter on the ge-0/0/1.0 interface.
Commit your configuration when complete.
[edit]
lab@srxA-1# set interfaces ge-0/0/1.0 family bridge filter output TM-Filter
[edit]
lab@srxA-1# commit
commit complete
Step 3.6
From the Telnet session established with the virtual router, initiate the FTP
connection again.
al@vr-device> ftp 172.20.y.so routing-instance vrlocal-Juniper-VLAN
ftp: connect: Operation timed out
ftp>

Question: Is the FTP connection successful?
Answer: The answer should be no. The FTP

connection should not be successful. The traffic
has been blocked by the firewall filter.
Step 3.7
Type bye to exit the FTP connection. Then, exit the open Telnet session on the
virtual router.
ftp> byE!
al@vr-device> exit
vr-devic:e (ttydO)
login:
Step 3.8
From your assigned SRX1 device, log out using the exit command.
[edit]
[email protected]# exit
lab@srxA,-1> exit
srxA-1 (ttyuO)
login:


ge-0/0/0(on all studentdevices)
srxA-1 srxD-1 I
srxA-2 I srxD-2
srxB-1 vr-device
I srxB-2 Server
'[i]
srxG-1 Gateway
I srxC-2 Term Server
e,.2013Jun1pe:rNetworo, Int Altrtbh teH:rved JUn�J Worldwide EducatmnServices WWN ,un1p

-- I

Layer 2 Security Lab
Host 172.31.15.1
r
UntrustZone
vlan.242
172.20.242.0/24
l) (.10)
vr242
�------- Virtual Routers _
]
-Ju-n-iper--':y/- _ _______ ...!Juniper-WF
__
..._�o:�J��P�t N�two�°= !n�All

nr1� ,...u)r�lj _}Unff?�.[ Worldwide Education Services WHn JUrll


:---� Host 172.3115.1
UntrustZone
srxB-2
172.20 243.Q/24 ge-0/0/1(.50)
17220244 0/24 vlan.244(.1) loO: 192.168.2.1

vlan.243 vlan.244
of'\'), rl)
�e;
�-----1
172.20.244.0/24
---- Virtual Routers

(10)\.
vr244 I
Junipe rSY
- Juniper-WF
13J\ltllperNetw;lin� Inc All rlghhr�,eNl!'(I

�---�--�- -�
Junm Worldwide Education Services I V>JWW JIJfllper n�,

,--fil
Host 172.31.15.1
UntrustZone
srxC-2
172.20 245.0/24 ge-0/0/1(.50)
172 20 246.0/24 vlan.246 (.1) loO 192.168.2.1

a
cl'J. l) vl n.246
ol
�0- r 172.20246.Q/24
(10)
-
'" - i- - SV__, ---- -------Virtual Routers - -------- -1 u i r-W
Jun per - - J n pe F
�""·""'� �r� =" -
�.,Tugf¥1"' '?A!'\
1lJu1upt1 Nttworla, !flt" All ilghh te",t!Wd JUn1Per Worldwide EducaUonSen:ices \'ll'l'IW ,unipern�t
�-�-"---- ----- -- - �


Host 172.31.15.1
UntrustZone
172 20.2470/24 ge-0/0/1(.50) srxD-2

172.20 248 0/24 vlan.248 (.1) lo() 192.168.2.1
vlan.248
cl'). (.1)
l \
�
e.c rJ:)\
c 172.20.248.0/24
� (.10)
"",2"-48�,
��l,--v
��
Virtual Routers ��
Juniper-SV Juniper-WF
<02013JUnlperNetwO,fks, Inc All rt�H reserved

'
Juniper
"""""°"�f, Worldwide Education Services WWI'! JUn1p

Lab
Implementing Junos Virtual Routing (Detailed)
Overvi1ew
In this lab, 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 over the
ge-0/0/1 interface.
Configure Internet access for the VRs.
Configure inter-VR communication.
Configure filter-based forwarding.
www.juniper.net Implementing Junos Virtual Routing (Detailed) • Lab 3-1

Part 1: Configuring Internet Access
In this lab part, you will 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 3. Then, you will configure two VRs-Juniper and ACME. You will then configure
Internet access for these VRs.
Note
assigned device.
Step 1.1


Step 1.2
Lab 3-2 • Implementing Junos Virtual Routing (Detailed) www.juniper.net

D Show quick connect on startup � Save session

0 Open in a tab
J, Connect ' I Cancel I

Step 1.3
Log in as user lab with the password labl2 3. Enter configuration mode and load
the lab3-start. configfrom the /var/home/lab/aj sec/ directory.
srxA-1 (ttyuO)
login: Iab
Password:

Enterin9 configuration mode
[edit]
lab@srxl,-1# load override ajsec/lab3-start.con£ig
[edit]
lab@srxl,-1# commit
commit complete
[edit]
lab@srxA-1#
Note
You may have to reboot the SRX device if
the interfaces mode changes from
transparent to route.
Step 1.4
Navigate to the [edit routing- instances J hierarchy level. Configure two
VRs-Juniper and ACME. The Juniper VR should contain the VLAN interface that
directly connects your SRX device with the Juniper device. Then, the ACMEVR should
contain the VLAN interface that directly connects your SRX device with the ACME
device. When you are finished, commit your configuration.

[edit]
lab@srxA-1# edit routing-instances
[edit routing-instances]
lab@srxA-1# set Juniper instance-type virtual-router
lab@srxA-1# set Juniper interface vlan.local-Juniper-vlan
lab@srxA-1# set ACME instance-type virtual-router
lab@srxA-1# set ACME interface vlan.local-ACME-vlan
lab@srxA-1# show
ACME {
instance-type virtual-router;
interface vlan.201;
}
Juniper {
interface vlan.101;
lab@srxA-1# commit
commit complete
lab@srxA-1#
Note
The next lab steps require you to log in to

the virtual router attached to your team's
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network

Step 1.5
Open a separate Telnet session to the virtual router attached to your team's device.
D Show quick connect on startup 0 Save session

0 Open in a tab
L Connect J[ Cancel I
Step 1.6

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttypO)
login: al
Password:
You must use 'configure private' to configure this router.
al@vr-de�vice>

Step 1.7
Ping the Internet host by issuing the ping 172. 31.15 .1 routing-instance
vrlocal-Juniper-vlan command, where local-Juniper-vlan is the
VLAN ID associated with your directly connected Juniper customer device.. Please
refer to Network Diagram: Lab 3 for the correct VLAN ID value.
al@vr-device> ping 172.31.15.1 routing-instance vrlocal-Juniper-vlan 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 Flg off TTL Pro cks Src Dst
4 5 00 0054 lb05 0 0000 40 01 8d65 172.20.101.10 172.31.15.1

4 5 00 0054 lbOa O 0000 40 01 8d60 172.20.101.10 172.31.15.1
--- 172.31.15.1 ping statistics ---

Question: Why are the pings not successful?
Answer: The message shows that the next

upstream router, your SRX device, cannot reach the
Internet host.
Step 1.8
From your assigned SRX device, issue the run show route table
juniper. inet. 0 and run show route table acme. 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.
lab@srxA-1# run show route table juniper.inet.O
Juniper.inet.O: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
172.20.101.0/24 *[Direct/OJ 01:05:12

> via vlan.101
172.20.101.1/32 *[Local/OJ 01:05:12
Local via vlan.101

lab@srxA-1# run show route table acme.inet.0
ACME.inet.O: 2 destinations, 2 routes (2 active, O holddown, 0 hidden)

172.20.201.0/24 *[Direct/OJ 01:06:05

> via vlan.201
172.20.201.1/32 *[Local/OJ 01:06:05
Local via vlan.201
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 1.9
Configure the Juniper and ACME routing instances to use the main routing
instance's inet.0 routing table for unknown destinations. When you are finished,
commit the configuration.
lab@srxA-1# set Juniper routing-options static route 0/0 next-table inet.O
[email protected],-1# set ACME routing-options static route 0/0 next-table inet.O
lab@srxA-1# commit
commit complete
Step 1.10
Issue the commands run show route table juniper. inet. O and
run show route table acme.inet.O.
lab@srxA-1# run show route table juniper.inet.0
Juniper.inet.O: 3 destinations, 3 routes (3 active, O holddown, O hidden)

0.0.0.0/0 *[Static/SJ 00:21:05

to table inet.O
172.20.101.0/24 *[Direct/OJ 02:26:22
> via vlan.101
172.20.101.1/32 *[Local/OJ 02:26:22
Local via vlan.101
[email protected]# run show route table acme.inet.0
www.juniper.net Implementing Junes Virtual Routing (Detailed) • Lab 3-7

ACME.inet.O: 3 destinations, 3 routes (3 active, O holddown, O hidden)

0.0.0.0/0 *[Static/SJ 00:21:14

to table inet.O
172.20.201.0/24 *[Direct/OJ 02:26:31
> via vlan.201
172.20.201.1/32 *[Local/OJ 02:26:31
Local via vlan.201
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 1.11
From the Telnet session established with the virtual router, ping the Internet host by
issuing theping 172.31.15.1 routing-instance vrlocal-Juniper
vlan command, where local -Juniper-vlan is the VLAN ID associated with
your directly connected Juniper customer device. Please refer to Network Diagram:
Lab 3 for the correct VLAN ID value.
al@vr-device> ping 172.31.15.1 routing-instance vrlocal-Juniper-vlan count 2
PING 172.31.15.1 (172.31.15.1): 56 data bytes
64 bytes from 172.31.15.1: icmp_seq=O ttl=63 time=3.765 ms
64 bytes from 172.31.15.1: icmp_seq=l ttl=63 time=3.366 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 1.12
From your assigned SRX device, issue the run show route table inet. O
command and examine the routing table.
Lab 3-8 • Implementing Ju nos Virtual Routing (Detailed) www.juniper.net

lab@srx�-1# run show route table inet.O
inet.O: 6 destinations, 6 routes (6 active, 0 holddown, O hidden)

0.0.0.0/0 *[Static/SJ lw4d 05:47:13

> to 172.18.1.1 via ge-0/0/3.0
10.210.14.128/27 *[Direct/OJ lw4d 05:47:20
> via ge-0/0/0.0
10.210.14.131/32 *[Local/OJ lw4d 05:47:27
Local via ge-0/0/0.0
172.18.1.0/30 *[Direct/OJ lw4d 05:47:14
> via ge-0/0/3.0
172.18.1.2/32 *[Local/OJ lw4d 05:47:27
192.168.1.1/32 *[Direct/OJ lw4d 05:48:15
> 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. Jhe return traffic uses the
fast path of the flow services module that bypasses
the routing in the inet.0 routing table.
Part 2: Configuring lnter-VR Communication
In this lab part, you will configure inter-VR communication through the use of the
logical tunnel interface.
Step 2.1
Navigate to the [edit interfaces] hierarchy level. Remove the firewall filters
associated with the VLAN interfaces. When you are finished, commit the
configuration.
lab@srxA-1# top edit interfaces
[edit interfaces]
lab@srxA-1# delete vlan unit local-Juniper-vlan family inet filter
[edit interfaces]
lab@srxA-1# delete vlan unit local-Acme-vlan family inet filter
[edit interfaces]
lab@srxA-1# show vlan
unit 101 {
family inet {
address 172.20.101.1/24;
unit 201
family inet
address 172.20.201.1/24;
[edit interfaces]
lab@srxA-1# commit
commit complete
[edit interfaces]
lab@srxA-1#
Step2.2
From the Telnet session established with the virtual router, test communication
between the Juniper and ACME customer devices that are directly connected to your
assigned SRX device. Issue the telnet local-ACME-device-address
routing-instance vrlocal-Juniper-vlan command. Please refer to your
lab 3 diagram for the correct VLAN ID value.
al@vr-device> telnet local-ACME-device-address routing-instance
vrlocal-Juniper-VLAN
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 Telnet session attempt

reveal?
Answer: The Telnet session attempt reveals no

connectivity between your local Juniper device and
ACME device.
Step2.3
Lab 3-10 • lmplementingJunos Virtual Routing (Detailed) www.juniper.net

From your assigned SRX device, issue the commands run show route table
juniper. inet. 0 and run show route table acme. inet. 0.
[edit interfaces]
lab@srxl,-1# run show route table juniper.inet.0

0.0.0.0/0 *[Static/SJ 17:09:16

to table inet.O
172.20.101.0/24 *[Direct/OJ 19:14:33
> via vlan.101
172.20.101.1/32 *[Local/OJ 19:14:33
Local via vlan.101
[edit interfaces]
lab@srxA-1# run show route table acme.inet.O

0.0.0.0/0 *[Static/SJ 17:09:18

to table inet.O
172.20.201.0/24 *[Direct/OJ 19:14:35
> via vlan.201
172.20.201.1/32 *[Local/OJ 19:14:35
Local via vlan.201
Question: Why is the communication between the

Juniper device and ACME 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 share routes between the VRs.
Step 2.4
Navigating to the [edit interfaces lt- 0/0/0] hierarchy level.Configure
unit 1 with the IP address of 172.2 1.1.1/30, and unit 2 with the IP address of
172.2 1.1.2/30.Configure peering between the two units, and configure both units
with Ethernet encapsulation.

[edit interfaces]
lab@srxA-1# edit lt-0/0/0
[edit interfaces lt-0/0/0]

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

lab@srxA-1# set unit 1 peer-unit 2

lab@srxA-1# set unit 1 encapsulation ethernet

lab@srxA-1# set unit 2 family inet address 172.21.1.2/30

lab@srxA-1# set unit 2 peer-unit 1

lab@srxA-1# set unit 2 encapsulation ethernet

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

lab@srxA-1#
Step 2.5
Associate the lt-0/0/0.1 interface with the Juniper VR instance. Associate the
lt-0/0/0.2 interface with the ACME VR instance.
lab@srxA-1# up 2 edit routing-instances
lab@srxA-1# set Juniper interface lt-0/0/0.1
lab@srxA-1# set ACME interface lt-0/0/0.2
Lab 3-12 • lmplementingJunos Virtual Routing (Detailed) www.juniper.net

[email protected]#
Step 2.6
Configure OSPF in the Juniper and ACME VR instances. Place the lt-0/0/0.1 and
the Juniper VLAN interface inside area o in the Juniper VR instance. Place the
lt-0/0/0.2 and the ACME VLAN interface inside area o in the ACMEVR instance. Add
the passive option to both VLAN interfaces inside of OSPF. When you are finished,
lab@srx�-1# set Juniper protocols ospf area O interface lt-0/0/0.1
lab@srx�-1# set Juniper protocols ospf area O interface vlan.local-Juniper-vlan
passive
lab@srxA-1# set ACME protocols ospf area O interface lt-0/0/0.2
lab@srxA-1# set ACME protocols ospf area O interface vlan.local-ACME-vlan
passive
lab@srxA-1# show
ACME {
interface lt-0/0/0.2;
interface vlan.201;
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;
protocols {
ospf {
area 0.0.0.0 {
interface vlan.201 {
passive;
Juniper
interface vlan.101;
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;
www.juniper.net lmplementingJunos Virtual Routing (Detailed) • Lab 3-13

protocols {
ospf {
area 0.0.0.0 {
passive;
lab@srxA-1# commit
commit complete
Step 2.7
Issue the run show ospf interface command.
lab@srxA-1# run show ospf interface
OSPF instance is not running
Question: Why is the OSPF instance not running?
Answer: OSPF is configured under the Juniper

and ACMEVR instances. The previous command is
displaying OSPF information for the main routing
instance.
Step 2.8
Issue the commands run show ospf interface instance Juniper and
run show ospf interface instance ACME.
lab@srxA-1# run show ospf interface instance Juniper
Interface State Area DR ID BDR ID Nbrs
lt-0/0/0.1 DR 0.0.0.0 172.20.101.1 0.0.0.0 0
vlan.101 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
lab@srxA-1# run show ospf interface instance ACME
lt-0/0/0.2 DR 0.0.0.0 172.20.201.1 0.0.0.0 0
vlan.201 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

Question: Are any neighbors detected on the

lt-0/0/0 interfaces?
Answer: No neighbors are detected on the lt-0/0/0

interfaces.
Step 2.9
Test connectivity between the Juniper and ACME VR routing instances by issuing
the run ping 172.21.1.2 routing-instance Junipercommand.
lab@sr�A-1# run ping 172.21.1.2 routing-instance Juniper 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 that a security zone
issue.
Step 2.10
Issue the run show security zones command.
lab@srxl\-1# 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:
vlan.201
Security zone: Juniper-SV

Interfaces bound: 1

Interfaces:
vlan.101
Security zone: untrust

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

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 2.11
Bind the lt-0/0/0.1 interface to the Juniper zone. Bind the lt-0/0/0.2 interface to the
ACME zone. Allow both logical tunnel interfaces to process ping requests and OSPF
packets. When you are finished, commit the configuration.
lab@srxA-1# top edit security zones security-zone Juniper-local
[edit security zones security-zone Juniper-SV]

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

lab@srxA-1# set interfaces lt-0/0/0.1 host-inbound-traffic protocols oe:pf

lab@srxA-1# up 1 edit security-zone ACME-local
[edit security zones security-zone ACME-SV]

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

lab@srxA-1# set interfaces lt-0/0/0.2 host-inbound-traffic protocols os:pf

lab@srxA-1# up
[edit security zones]

lab@srxA-1# show security-zone Juniper-local
address-book {

address vrlOl 172.20.101.0/24;
interfaces {
vla:n.101
system-services {
ping;
}
lt-0/0/0.1
system-services {
ping;
protocols
ospf;

lab@srxA-1# show security-zone ACME-local
address--book {
address vr201 172.20.201.0/24;
}
interfaces {
vlan.201
system-services {
ping;
lt-0/0/0.2
system-services {
ping;
protocols
ospf;

lab@srxA-1# commit
commit complete

lab@srxA-1#

Step 2.12
Test connectivity between the Juniper and ACME VR instances by issuing the
command run ping 172. 21.1.2 routing-instance Juniper.
lab@srxA-1# run ping 172.21.1.2 routing-instance Juniper count 2
PING 172.21.1.2 (172.21.1.2): 56 data bytes
64 bytes from 172.21.1.2: icmp seq=l ttl=64 time=l.290 ms

round-trip min/avg/max/stddev = l.290/4.499/7.709/3.210 ms
Answer: Yes. The ping test is successful.
Step 2.13
Issue the commands run show ospf interface instance Juniper and
run show ospf interface instance ACME.
lab@srxA-1# run show ospf interface instance Juniper
lt-0/0/0.1 BDR 0.0.0.0 172.20.201.1 172.20.101.J. 1
vlan.101 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0

lab@srxA-1# run show ospf interface instance ACME
lt-0/0/0.2 DR 0.0.0.0 172.20.201.1 172.20.101.J. 1
vlan.201 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Question: Are any neighbors detected on the

lt-0/0/0 interfaces?
Answer: Yes. Neighbors are detected on the

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

adjacencies to reach the Full state.

lab@srx�-1# run show ospf neighbor instance all
Instance: ACME
Address Interface State ID Pri Dead
172.21.l.l lt-0/0/0.2 Full 172.20.101.1 128 32
Instance: Juniper
172.21.1.2 lt-0/0/0.1 Full 172.20.201.1 128 32
Question: In what states are the OSPF adjacencies?
Answer: The OSPF adjacencies should reach the

Full state.
Step 2.1!:i
Examine the Juniper and ACME VR instances routing tables.
lab@srxA-1# run show route table juniper.inet.0

0.0.0.0/0 *[Static/SJ 00:38:30

to table inet.O
172.20.101.0/24 *[Direct/OJ 00:38:26
> via vlan.101
172.20.101.1/32 *[Local/OJ 00:38:26
Local via vlan.101
172.20.201.0/24 *[OSPF/10] 00:37:36, metric 2
> to 172.21.1.2 via lt-0/0/0.l
172.21.1.0/30 *[Direct/OJ 00:38:27
> via lt-0/0/0.1
172.21.1.1/32 *[Local/OJ 00:38:27
Local via lt-0/0/0.1
224.0.0.5/32 *[OSPF/10] 00:38:30, metric 1
MultiRecv

lab@srxl,-1# run show route table acme.inet.O
ACME.inet.O: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/SJ 00:38:37

to table inet.0
172.20.101.0/24 *[OSPF/10] 00:37:43, metric 2
> to 172.21.1.l via lt-0/0/0.2
172.20.201.0/24 *[Direct/OJ 00:38:33
> via vlan.201
172.20.201.1/32 *[Local/OJ 00:38:33
Local via vlan.201

Advanced Junos Secur ity
172.21.1.0/30 * [Direct/OJ 00: 38:34
> via lt-0/0/0.2
172.21.1.2/32 * [Local/OJ 00:38:34
224.0.0.5/32 *[OSPF/lOJ 00:38:37, metric 1
MultiRecv
Question: Are OSPF routes being shared between

the Juniper and ACMEVRs?
Answer: Yes. OSPF routes are being shared.
Step2.16
From the Telnet session established with the virtual router, test communication
between the Juniper and ACME customer devices that are directly connected to your
assigned SRX device. Issue the telnet local-ACME-device-address
routing-instance vr local-Juniper-vlan command. Please refer to your
lab 3 diagram for the correct VLAN ID value.
al@vr-device> telnet local-ACME-device-address routing-instance
vrlocal-Juniper-vlan
Trying 172.20.201.10...
A
Escape character is ' l '
vr-device (ttypl)
login:
Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.

Step2.17
Log in to the virtual router to ensure that the Telnet session does not time out. Use
the login information shown in the following table:

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttypO)
login: al
Password:
You must. use 'configure private' to configure this router.
al@vr-device>
Step2.18
From your assigned SRX device, find the recently created Telnet session in the
session table.
lab@srxA-1# run show security flow session application telnet
Session ID: 57866, Policy name: intrazone-Juniper-SV/4, Timeout: 3394, Valid
In: 172.20.101.10/56290 --> 172.20.201.10/23;tcp, If: vlan.101, Pkts: 27,
Bytes: 1568
Out: 172.20.201.10/23 --> 172.20.101.10/56290;tcp, If: lt-0/0/0.1, Pkts: 21,
Bytes: 1543
Session ID: 57867, Policy name: intrazone-ACME-SV/5, Timeout: 3394, Valid

In: 172.20.101.10/56290 --> 172.20.201.10/23;tcp, If: lt-0/0/0.2, Pkts: 27,
Bytes: 1568
Out: 172.20.201.10/23 --> 172.20.101.10/56290;tcp, If: vlan.201, Pkts: 21,
Bytes: 1543
Total sessions: 2
www.juniper.net Implementing Ju nos Virtual Routing (Detailed) • Lab 3-21
Question: Why are two Telnet sessions from the
Juniper device to the ACME device listed 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

intrazone-Juniper-local and
intrazone-ACME-local policies.
Part 3: 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 3.1
Configure the ge-0/0/1 interface with the correct interface address and netmask.
Refer to your lab 3 diagram for the specific interface address.
lab@srxA-1# top edit interfaces ge-0/0/1

lab@srxA-1# set unit O family inet address address/30

lab@srxA-1# show
unit O {
family inet
address 172.19.1.1/30;

lab@srxA-1
Step 3.2
Place the ge-0/0/1 interface in the untrust zone.
lab@srxA-1# top edit security zones security-zone untrust

[edit security zones security-zone untrust]

lab@srx�-1# set interfaces ge-0/0/1

lab@srx�-1#
Step3.3
On your device, configure the FBF-ACME-local security policy to permit any
traffic that is going towards the untrust zone.
[edit s,,,curity zones security-zone untrust]
lab@srxA-1# top edit security policies from-zone ACME-local to-zone untrust
poli,:y FBF-ACME-local
[edit security policies from-zone ACME-SV to-zone untrust policy FBF-ACME-SV]

lab@srxA-1# set match source-address any

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

lab@srxA-1# set match application any

lab@srxA-1# set then permit

lab@srxl,-1#
Step3.4
Configure a RIB group named ACME-to-Main that will copy interface routes
located in the ACME. inet.0 table to the inet.O table. Configure the ACMEVR to place
its interface routes into the ACME-to-Main RIB group. When you are finished,
lab@srxA-1# top edit routing-options rib-groups ACME-to-Main
[edit routing-options rib-groups ACME-to-Main]

lab@srxl,-1# set import-rib [ ACME.inet.0 inet.0
[edit routing-options rib-groups]

lab@srxl,-1# up 2
[edit routing-options]
lab@srxl,-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
rib-groups {
ACME-to-Main
import-rib [ ACME.inet.Oinet.O];

lab@srxA-1# top edit routing-instances ACME routing-options
[edit routing-instances ACME routing-options]

lab@srxA-1# set interface-routes rib-group inet ACME-to-Main

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 3.5
Issue the run show route command.
lab@srxA-1# run show route
inet.O: 13 destinations, 13 routes (13 active, O holddown, 0 hidden)

0.0.0.0/0 *[Static/5] 18:27:17

> to 172.18.1.1 via ge-0/0/3.0
10.210.14.128/27 *[Direct/OJ 4d 03:25:37
> via ge-0/0/0.0
10.210.14.131/32 *[Local/OJ 4d 03:25:37
172.18.1.0/30 *[Direct/OJ 18:27:17
> via ge-0/0/3.0
172.18.1.2/32 *[Local/OJ 18:27:17
172.19.1.0/30 *[Direct/OJ 01:22:26
> via ge-0/0/1.0
172.19.1.1/32 *[Local/OJ 01:22:26
172.20.201.0/24 * [Direct/OJ 00: 22:31
> via vlan.201
172.20.201.1/32 * [Local/OJ oo:22:31
Local via vlan.201
172.21.1.0/30 *[Direct/OJ 00:22:31
> via lt-0/0/0.2
1 72.21.1.2/32 *[Local/OJ 00:22:31
192.168.1.1/32 *[Direct/OJ ld 21:45:54
> via loo.a

0.0.0.0/0 *[Static/5] 16:43:42

to table inet.O
172.20.101.0/24 *[OSPF/10] 16:42:47, metric 2

> to 172.21.1.1 via lt-0/0/0.2

172.20.201.0/24 *[Direct/OJ 16:43:38
> via vlan.201
172.20.201.1/32 *[Local/OJ 16:43:38
Local via vlan.201
172.21.1.0/30 *[Direct/OJ 16:43:38
> via lt-0/0/0.2
172.21.1.2/32 *[Local/OJ 16:43:38
224.0.0.5/32 *[OSPF/lOJ 16:43:42, metric 1
MultiRecv
Juniper.inet.O: 7 destinations, 7 routes (7 active, 0 holddown, O hidden)

0.0.0.0/0 *[Static/SJ 16:43:42

to table inet.O
172.20.101.0/24 *[Direct/OJ 16:43:38
> via vlan.101
172.20.101.1/32 *[Local/OJ 16:43:38
Local via vlan.101
172.20.201.0/24 *[OSPF/lOJ 16:42:47, metric 2
> to 172.21.1.2 via lt-0/0/0.1
172.21.1.0/30 *[Direct/OJ 16:43:38
> via lt-0/0/0.1
172.21.1.1/32 *[Local/OJ 16:43:38
224.0.0.5/32 *[OSPF/lOJ 16:43:42, metric 1
MultiRecv
Question: Are the interface routes in the

ACME. inet.O routing table present in the inet.0
routing table?
Answer: Yes. The interface routes in the

ACME. inet.O routing table should be present in the
inet.0 routing table.

Question: In the next several steps, you enable

filter-based forwarding to send traffic between the
ACME-SV device to the ACME-WF device over the
ge-0/0/1 interface. Why is it necessary to copy
these routes into the inet.0 routing table?
Answer: The traffic sent to the ACME device will

arrive on the ge-0/0/1 interface on the SRX2
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 device is located
inside the ACME. inet.0 routing table, the main
routing instance does not have a method to send
traffic to the ACME device. Copying routes from the
ACME. inet.O routing table to the inet.0 routing
table allows this traffic to be sent to the ACME
device when it arrives on the SRX device.
Step 3.6
Configure a forwarding routing instance named FBF-instance. Configure a
default static route that will send all traffic to the remote SRX device over the
ge-0/0/1 interface.
lab@srxA-1# top edit routing-instances FBF-instance
[edit routing-instances FBF-instance]

lab@srxA-1# set instance-type forwarding

lab@srxA-1# set routing-options static route 0/0 next-hop
remote-ge-0/0/1-address

lab@srxA-1# show
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.19.1.2;

lab@srxA-1#

Step3.7
Configure the FBF-fil ter firewall filter to send any traffic destined to the remote
ACME device to the FBF-instance routing instance. Configure a counter named
FBF-counterto count any packets that match the filter.
lab@srxA-1# top edit firewall family inet filter FBF-filter term FBF
[edit firewall family inet filter FBF-filter term FBF]

lab@srxA-1# set from destination-address remote-ACME-address

lab@srxA-1# set then routing-instance FBF-instance

lab@srxA-1# set then count FBF-counter

lab@srxA-1# up
[edit firewall family inet filter FBF-filter]

lab@srxi�-1# show
term FBF{
from {
destination-address
172.20.202.10/32;
}
then {
count FBF-counter;
routing-instance FBF-instance;

lab@srxl�-1#
Step3.8
Apply the FBF-fil ter firewall filter as an input filter on the VLAN interface that is
associated with the local ACME device. When you are finished, commit the
configuration.
lab@sr�,-1# top edit interfaces vlan.local-ACME-VLAN
[edit interfaces vlan unit 201]

lab@sr�-1# set family inet filter input FBF-filter

lab@sr�,-1# commit
commit complete

[email protected]#

Step3.9
From the Telnet session established with the virtual router, issue the command
ping remote-ACME-address routing-instance vrlocal-AC'ME-vlan
to establish communication between the ACME-SV and ACME-WF customer devices.
al@vr-device> ping remote-ACME-address routing-instance vrlocal-ACME-vlan count
2
PING 172.20.202.10 (172.20.202.10): 56 data bytes
4 5 00 0054 36d8 O 0000 40 01 4c93 172.20.201.10 172.20.202.10

4 5 00 0054 36e0 0 0000 40 01 4c8b 172.20.201.10 172.20.202.10
--- 172.20.202.10 ping statistics ---

Answer: No. The ping test is not successful.
Step3.10
From your assigned SRX device, issue the command run show firewall
filter FBF-filter.
[edit interfaces vlan unit.201]
lab@srxA-1# run show firewall filter FBF-filter
Filter: FBF-filter
Counters:
Name Bytes Packets
FBF-counter 168 2
Question: Is the FBF-fil terfirewall filter being

applied to this traffic?
Answer: Yes. The counter is incrementing.

Question: Where is the FBF-fil ter sending this
traffic?
Answer: The FBF-fil ter is sending this traffic to

the FBF-instance routing instance.
Step3.11
Issue the run show route table FBF-instance. inet. O command.
lab@srxA-1# run show route table FBF-instance.inet.0

lab@srxA-1#
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 FBF-instance routing instance through
the use of RIB groups.
Step3.12
Configure the Main-to-FBF RIB group to copy interface routes from the inet.0
routing table to the FBF-instance. inet. o routing table. Configure a policy to
allow only the 172.19.1.0/30 prefix to be copied from the inet. o routing table.
When you are finished, commit the configuration and exit to operational mode.
lab@srxA-1# top edit policy-options policy-statement only-172.19.1.0/30 term
accept-route
[edit policy-options policy-statement only-172.19.1.0/30 term accept-route]

lab@srxA-1# set from interface ge-0/0/1
www.juniper.net Implementing Ju nos VirtualRouting (Detailed) • Lab 3-29

lab@srxA-1# set to rib FBF-instance.inet.O

lab@srxA-1# set then accept

lab@srxA-1# up
[edit policy-options policy-statement only-172.19.1.0/30]

lab@srxA-1# set term reject-routes then reject

lab@srxA-1# show
term accept-route {
from interface ge-0/0/1.0;
to rib FBF-instance.inet.O;
then accept;
term reject-routes
then reject;

lab@srxA-1# top edit routing-options rib-groups Main-to-FBF
[edit routing-options rib-groups Main-to-FBF]

lab@srxA-1# set import-rib [ inet.O FBF-instance.inet.0

lab@srxA-1# set import-policy only-172.19.1.0/30

lab@srxA-1# up 2
lab@srxA-1# set interface-routes rib-group inet Main-to-FBF
lab@srxA-1# 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.inet.O inet.O J;
}
Main-to-FBF {
import-rib [ inet.O FBF-instance.inet.O J;
import-policy only-172.19.1.0/30;

lab@srxA-1# commit and-quit
commit complete
lab@srxA-1>
Step3.13
Issue the show route table FBF-instance. inet. O command and
examine the routing table.
lab@srxl\-1> show route table FBF-instance.inet.O
FBF-inst:ance.inet.O: 2 destinations, 2 routes (2 active, O holddown, O hidden)

+ = Active Route, - = Last Active, * Both
0.0.0.0/0 * [Static/SJ oo:01:21

> to 172.19.1.2 via ge-0/0/1.0
172.19.1.0/30 *[Direct/OJ 00:01:21
> via ge-0/0/1.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-FBF RIB
group.The o. o. o.0/0 prefix is now resolvable
because the next hop of 1 72.19 .1.2 is
reachable.
Ensure that the remote student team within your pod has finished the
previous step before continuing.
Step3.14
From the Telnet session established with the virtual router, issue the command
ping remote-ACME-address routing-instance vrlocal-ACME-vlan
to establish communication between the ACME-SV and ACME-WF devices.
al@vr-device> ping remote-ACME-address routing-instance vrlocal-ACME-vlan rapid
PING 172.20.201.10 (172.20.201.10): 56 data bytes
! ! ! ! !
--- 172.20.201.10 ping statistics ---
5 packets transmitted, s packets received, 0% packet loss

Advanced Ju nos Security
Answer: Yes, the ping should be successful. If not

check your configuration or your instructor.
Step3.15
Initiate a Telnet session from the local ACME device to the remote ACME clevice.
Issue the telnet remote-ACME-address routing-instance
vrlocal-ACME-vlan command.
al@vr-device> telnet remote-ACME-address routing-instance vrlocal-ACME-vlan
Trying 172.20.202.10 ...
Escape character is ' A l'.
vr-device (ttypl)
login:
Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.
Step3.16
Log in to the virtual router to ensure that the Telnet session does not time out. Use
the login information shown in the following table:

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttypO)
login: al
Password:

PleaE:e only configure your own virtual router.
al@vr-device>
Step 3.17
From your assigned SRX device, issue the command
show security flow session application telnet and examine the
session table.
lab@srxl\-1> show security flow session application telnet
Session ID: 7881, Policy name: FBF-ACME-SV/4, Timeout: 1594, Valid
In: 172.20.201.10/62847 --> 172.20.202.10/23;tcp, If: vlan.201, Pkts: 26,
ByteE:: 1515
Out: 172.20.202.10/23 --> 172.20.201.10/62847;tcp, If: ge-0/0/1.0, Pkts: 20,
ByteE:: 1490
Session ID: 7927, Policy name: ACME-WF-to-ACME-SV/14, Timeout: 1772, Valid

In: 172.20.202.10/62254 --> 172.20.201.10/23;tcp, If: ge-0/0/3.0, Pkts: 26,
Bytes: 1515
Bytes: 1542
Total sessions: 2
Question: Why are two transit Telnet sessions

present?
Answer: There is one session for the Telnet traffic

that you initiated from your local ACME device, and
another session that was initiated from the remote
ACME device.
Question: Which interfaces is the Telnet traffic that

was initiated from your local ACME device using?
Answer: The ACME VLAN and the ge-0/0/1

interfaces are being used for the Telnet session.

Question: Why is the remotely initiated Telnet

session using the ge-0/0/3 interface and not the
ge-0/0/1 interface?
Answer: Even though the return traffic for the

remotely initiated Telnet session is matching the
firewall filter that is applied to the ACME VLAN
interface, the flow module has already determined
which interface the return traffic should use when
the initial packets of the Telnet session entered the
SRX device. This means that the return traffic for
the remote Telnet session must use the ge-0/0/3
interface.
Step3.18
From the Telnet session established with the virtual router, exit the sessic,n.
al@vr-device> exit
Step3.19
From your assigned SRX device, log out using the exit command.
lab@srxA-1> exit
srxA-1 (ttyuO)
login:


srxA-1 srxD-1
srxA-2 srxD-2
srxB-1 vr-device
srxB-2 Server
srxG-1 Gateway
srxG-2 Term Server ______,,

Junos Virtual Routing Lab
(1) ge-0/0/1 ge-0/0/1 (.2)

172 1910/30 srxA-2
(1) vlan.201 -- vlan.!00�) vlan.202

Interface ge-0/0/4 --
172 20.201 0/24 172 20 102 0/24 172.20.202.0/24
(.� (.� (.�
ACME-SV -- Virtual Ro uters -- Ju niper-WF ACME-WF
JU(1JW Worldwide Education Services

��---,�-=-VA --�= -
1;;JuptrN��. !M:.Altr!gtiUuutiwd mvwJun1pern"'t


Host 172.31.15.1
(.1) ge-0/0/1 172.19.1.D/30
vlan.103 (.1) vlan.203 -- n e face e- lan 1

l t r g 0/0/4 -- v . 04
172.20.203.D/24 172.20.104.0/24
(.� (.�
-- Virtual Routers --
Juniper-SY ACME-SY Juniper-WF AC M EWF
-
tt,2013JunlperNetw'>OO, Inc All rl�\$reserved

- � - - A - - <""'-"•- -1
Jun� Worldwide Education Services WNW Jun1p

c
c
\',,
Ai-----�
'<'Y' t:{J Host 172.31.15.1
'b'),•
'},'>'
�
(.1) ge-0/0/1 172.19.1.0/30
vlan.105 (.1) vlan.205 --

Interfacege-0/0/4
172.20.205.0/24
(10)
Juniper-SY
-
0:�0.!.3Jullli;,t:rNt.t'#ork$, lne-.AUt!�ts tt�IJ:r.tl!d
�- -�--�-1-- - -
JUn!£?€r Worldwide Education Services WWY'J 1un1p


(.1) ge-0 /0/1 172.191.Q/30
vlan.107 n
(.1) vla .207 --- n rfaceg - -- vlan.108
l te e 0/0/4
172 20 2070/24 172.20.1080/24
(. � (.�
Juniper -SY ACME-SY ...__ Virtual Routers -- Juniper-WF ACME-WF


Lab
Advanced NAT Implementations (Detailed)
In this lab, you will implement Network Address Translation (NAT) in several real-world
scenarios. You will configure and monitor source and destination NAT, and you will see
how NAT rules work together with security policies to address different real-world
objectives. Then, you will examine how routing-behavior can impact some NAT
implementations and resolve those issues so the desired objectives can be
accomplished.
Use the Junos command-line interface (CLI) to load the baseline configuration.
Use the Junos CLI to make configuration changes necessary to implement
various NAT scenarios.
Configure and monitor pool-based destination NAT.
Configure and monitor interface-based source NAT.
Configure and monitor proxy address resolution protocol (ARP).
Configure and monitor NAT64 and NAT46 operations.
www.juniper.net Advanced NAT Implementations (Detailed) • Lab 4-1

Part 1: Loading the Baseline Configuration
In this lab part, you load the baseline configuration. You will also work witi1 the
remote student team within your pod, and execute a quick verification that you can
reach the remote team's device through the use of the ping utility and review the
route being used. You will also make configuration changes that will allow you to
implement advanced NAT scenarios presented in subsequent parts.
Step 1.1


Step 1.2
O Show quick connect on sta1tup � Save session

00penina tab
I, Connect ,! J Cancel l
Step 1.3
configuration and exit to operational mode when complete.
srxA-1 (ttyuO)
login: lab
Lab 4-2 • Advanced NAT Implementations (Detailed) www.juniper.net

Password:

lab@srxl\.-1> configure
[edit]
lab@srxl\.-1# load override ajsec/lab4-start.config
load complete
[edit]
commit complete
lab@srxl,-1>
Step 1.4
Verify that you can reach the remote pod team's SRX interfaces that are connected
to their virtual routers. Use rapid pings to verify connectivity to both of the remote
pod team's SRX interfaces that are connected to the Juniper and ACME virtual
routers.
lab@srxA-1> ping remote-Juniper-address source local-Juniper-address rapid
PING 172.20.102.1 (172.20.102.1): 56 data bytes
! ! ! ! !
--- 172.20.102.1 ping statistics ---
lab@srxA-1> ping remote-ACME-address source local-ACME-address rapid

PING 172.20.202.1 (172.20.202.1): 56 data bytes
! ! ! ! !
--- 172.20.202.1 ping statistics ---
Question: Do your pings complete?
Answer: Yes, your pings should complete at this

time. If they do not complete, ensure the remote
team has finished loading the baseline
configuration and have committed their
configuration. If you are still having trouble, contact
the instructor for assistance.
Step 1.5
Review the routing table and determine which route is used to reach the remote
device networks.

lab@srxA-1> show route
inet.O: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

0.0.0.0/0 *[Static/SJ Sd 21:39:57

> to 172.18.1.1 via ge-0/0/3.0
10.210.35.128/26 *[Direct/OJ Sd 21:39:57
> via ge-0/0/0.0
10.210.35.131/32 *[Local/OJ Sd 21:39:57
172.18.1.0/30 *[Direct/OJ Sd 21:40:01
> via ge-0/0/3.0
172.18.1.2/32 *[Local/OJ Sd 21:40: 01
172.20.101.0/24 *[Direct/OJ Sd 21:39:46
> via vlan.101
172.20.101.1/32 *[Local/OJ Sd 21:39:57
Local via vlan.101
172.20.201.0/24 *[Direct/OJ 5d 21:39:46
> via vlan.201
172.20.201.1/32 *[Local/OJ Sd 21:39:57
Local via vlan.201
192.168.1.1/32 *[Direct/OJ 19:35:09
> via loo.a
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
Enter configuration mode. Configure the ge-0/0/2 interface with the address shown
in the lab network diagram.
[edit]
[edit interfaces]
lab@srxA-1# set ge-0/0/2 unit O family inet address address/24
[edit interfaces]
lab@srxA-1#

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 publi cfacing
- IP
addresses without needing to assign them
to the interface.
SRX1 will own the 10. o.1. 0/25 address
range in this topology. SRX2 will own the
1 o. o.1.128/25 address range.
Step 1.7
Create a new security zone named Public-Facing and add the ge-0/0/2
interface to the zone.
[edit interfaces]
lab@srxll,-1# top edit security zones
[edit se,curity zones]

lab@srxll,-1# set security-zone Public-Facing interfaces ge-0/0/2

[email protected]#
Step 1.8
Create a new security policy named Allow-Outbound-Telnet. This policy allows
Telnet traffic originating from the local Juniper customer network to initiate sessions
to any external Telnet server through the ge-0/0/2 interface. Use the existing
vrJuniper-local-vlan address-book entry for your policy's
source-address match. Use the predefined application j unos-telnet for
your policy's application match.
[email protected]# up 1 edit policies from-zone Juniper-local to-zone Public-Facing
[edit security policies from-zone Juniper-SV to-zone Public-Facing]

lab@srxA-1# edit policy Allow-Outbound-Telnet
[edit security policies from-zone Juniper-SV to-zone Public-Facing policy

Allow-Outbound-Telnet]
lab@srxA-1# set match source-address vrJuniper-local-vlan

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

lab@srxA-1# set match application junos-telnet

lab@srxA-1# set then permit
www.junip,er.net Advanced NAT Implementations (Detailed) • Lab 4-5

lab@srxA-1# show
match {
source-address vrlOl;
application junos-telnet;
then {
permit;

lab@srxA-1#
Note
You will configure inbound security policies

later as part of your NAT implementations.
Step 1.9
Delete the existing static default route and create a new static default route for your
assigned SRX device. The new route should use the IP address associated with the
remote team's ge-0/0/2 interface as the next hop.
lab@srxA-1# top edit routing-options
lab@srxA-1# delete static route 0/0
lab@srxA-1# set static route 0/0 next-hop address
lab@srxA-1# show static
route 0.0.0.0/0 next-hop 10.0.1.129;
lab@srxA-1#
Step 1.10
Navigate to the top of the configuration hierarchy. Remove all stateless firewall filter
configuration on your assigned SRX device. When you are finished, commit the
configuration.

Note
You must also delete any configuration that

applied a firewall filter to an interface.
Theshow I display set I match
text CLI command can be very helpful
when looking for a particular string within
your configuration. Including I display
set provides context when the matching
text is displayed.
lab@srxA-1# top
[edit]
lab@srxJ\-1# delete firewall
[edit]
lab@srxJ\-1# show I display set I match "filter"
set interfaces loO unit O family inet filter input protect-cp
set interfaces vlan unit 101 family inet filter input Juniper-SV-to-ACME-SV
set interfaces vlan unit 201 family inet filter input ACME-SV-to-Juniper-SV
[edit]
lab@srxA-1# delete interfaces loO unit O family inet filter
[edit]
lab@srxA-1# delete interfaces vlan unit local-Juniper-unit family inet filter
[edit]
lab@srxl,-1# delete interfaces vlan unit local-ACME-unit family inet filter
[edit]
lab@srxl,-1# commit
commit complete
[edit]
lab@srxA-1#
so.
Part 2: Configuring NAT Implementation-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 telnet to a resource
on your internal network through a public-facing IP address associated with the
ge-0/0/2 interface of your assigned SRX device.

Step 2.1
Navigate to the [edit security nat destination] hierarchy. Configure the
destination NAT pool Telnet-Server with the virtual router address associated
with your local ACME customer network.
[edit]
lab@srxA-1# edit security nat destination
[edit security nat destination]

lab@srxA-1# set pool Telnet-Server address local-ACME-vr-address/32

lab@srxA-1#
Step 2.2
Configure the rule-set From-Internet NAT with a directional context that will
perform NAT on traffic coming from the Public-Facing 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@srxA-1# edit rule-set From-Internet
[edit security nat destination rule-set From-Internet]

lab@srxA-1# set from zone Public-Facing

lab@srxA-1#
Step 2.3
Configure a rule named To-Telnet-Server to match traffic sourced from the
172.20.96.0/20 and 172.20.192.0/19 prefixes. Then, apply the rule to traffic
destined for the remote team's external NAT address. If your assigned device is
SRXl, apply this rule to traffic destined to the 1 o. o.1. 126 address. If your
assigned device is SRX2, apply this rule to traffic destined to the 1 o. o.1.. 254
address.
Note
The 172.20.96.0/20 prefix will

accommodate the local and remote Juniper
customer networks.
The 172.20.192.0/19 prefix will
accommodate the local and remote ACME
customer networks.

lab@srxl,-1# edit rule To-Telnet-Server
[edit security nat destination rule-set From-Internet rule To-Telnet-Server]

lab@srxl,-1# set match source-address 172.20.96.0/20

lab@srxl,-1# set match source-address 172.20.192.0/19

lab@srxl,-1# set match destination-address address/32

lab@srxl,-1# set match destination-port 23

lab@srxA-1# set then destination-nat pool Telnet-Server

lab@srxA-1# up 3 show
destination {
pool Telnet-Server
address 172.20.201.10/32;
rule-set From-Internet {
from zone Public-Facing;
rule To-Telnet-Server {
match {
source-address [ 172.20.96.0/20 172.20.192.0/19 ];
destination-address 10.0.1.126/32;
}
then {
destination-nat pool Telnet-Server;

[email protected]#
Question: Will a host from the remote ACME

customer zone be able to telnet to your Telnet
server after you commit the current changes?
Answer: No external hosts will be able to access

your Telnet server yet. A security policy that allows
the traffic has not been configured.

Question: Will additional security policy

configuration be required?
Answer: Yes. You created the new zone

Public-Facing in an earlier step. However, no
security policies are in place that allow traffic
originating from the zone Public-Facing. You
will create the appropriate security policy in a
subsequent step.
Question: Will host-inbound-services need

to be configured for the ge-0/0/2 interface of your
assigned SRX device?
Answer: No. The host-inbound-services

command 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 SRX device.
Question: Will proxy-arp need to be configured

for our implementation?
Answer: Yes. The target destination IP address is

one of many in the 1 o. o. 1. address/2 5
address range that is not configured on the
ge-0/0/2 interface. In our topology, the remote
team's SRX device will recognize the destination
IP address is on a local segment and send out an
ARP request. Withoutproxy-arp, no reply is given
to the ARP request because the IP address is not
assigned to any host on the network.

Step 2.4
Configure proxy-arp on your assigned SRX device. The SRX device should
respond to any ARP requests for availa ble IP addresses in the address ranges
allocated for your assigned SRX device. SRX1 will use 1 o. o. 1. 2 to
10.0.1.126. SRX2 will use 10.0.1.200 to 10.0.1.254.
lab@srxA-1# up 3
[edit security natl

lab@srxA-1# set proxy-arp interface ge-0/0/2 address address to address
[edit security natl

lab@srxA-1# show proxy-arp
interface ge-0/0/2.0 {
address {
10.0.1.2/32 to 10.0.1.126/32;
[edit security natl

lab@srxA-1#
Step 2.5
Navigate to the [edit security address-book Public-Facing]
hierarchy level. Configure address-book entries for the remote student team's
Juniper and ACME customer networks. Place these address-book entries into an
address-book address-set named Remote-Partner. Attach the
address-book to the Public-Facing zone.
[edit security natl
lab@srxl,-1# up 1 edit zones security-zone Public-Facing
[edit security address-book Public-Facing)

lab@srxl,-1# set address Remote-Partner-Juniper address/24

lab@srxl',-1# set address Remote-Partner-ACME address/24

lab@srxl'.-1# set address-set Remote-Partner address Remote-Partner-Juniper
[edit security address-book Public-Facing]

lab@srxl',-1# set address-set Remote-Partner address Remote-Partner-ACME

lab@srxl'.-1# set attach zone Public-Facing

lab@srxll,-1# show
address Remote-Partner-Juniper 172.20.101.0/24;
address Remote-Partner-ACME 172.20.201.0/24;
address-set Remote-Partner {
address Remote-Partner-Juniper;
address Remote-Partner-ACME;
}
attach {
zone Public-Facing;

lab@srxA-1#
Step 2.6
Configure a security policy named Allow-To-Telnet-Server that will allow
Telnet traffic from the remote team's Juniper and ACME customer networl<s to your
assigned device's local ACME customer network. Configure the source-address
to match the address-set Remote-Partner, and use the existing vr2oy
address-book entry for your policy's destination-address match. The
value of y is the remainder of the VLAN ID associated with your local ACME
customer network. Next, commit the configuration and exit to operational mode.
lab@srxA-1# up 2 edit policies from-zone Public-Facing to-zone ACME-local
[edit security policies from-zone Public-Facing to-zone ACME-SV]

lab@srxA-1# set policy Allow-To-Telnet-Server match source-address
Remote-Partner

lab@srxA-1# set policy Allow-To-Telnet-Server match destination-address vr20�

lab@srxA-1# set policy Allow-To-Telnet-Server match application junos-telnet

lab@srxA-1# set policy Allow-To-Telnet-Server then permit

lab@srxA-1# show
policy Allow-To-Telnet-Server {
match {
source-address Remote-Partner;
destination-address vr201;
}
then {
permit;

commit complete
lab@srxA-1>

Ensure that the remote student team within your pod has finished this
Step 2.7
Note
This lab step requires you to open a

separate Telnet session to the virtual router
to emulate an external host.
Open a separate Telnet session to the virtual router.
O Show quick connect on startup 0 Save session

0 Open in a tab
I, Connect 1 ! I Cancel I

Step 2.8
Student Device User Name Password

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttydO)
login: username
Password:
al@vr-device>
Step 2.9
From the Telnet session established with the virtual router, test your recently
configured NAT implementation by initiating a Telnet connection to the remote
team's external NAT address you configured in step 2.5. If your assigned device is
SRX1, use the 1 o. o. 1. 2 54 address. If your assigned device is SRX2,use the
1 o. o.1. 126 address. Source the connection from the virtual router's routing
instance associated with your local Juniper customer network. Refer to the lab
network diagram if needed.
al@vr-device> telnet address routing-instance vrlocal-Juniper-VLAN
Trying 10.0.1.254...
Escape character is ' A l'
vr-device (ttypl)
login:

Question: What is the result of the Telnet session?
Answer: As shown in the output, the Telnet session

should be successfully established.
Step 2.10
From your assigned SRX device, issue the show security flow session
command.
Session ID: 42005, Policy name: Allow-Outbound-Telnet/10, Timeout: 1784, Valid
In: 172.20.101.10/54242 --> 10.0.l.254/23;tcp, If: vlan.101, Pkts: 9, Bytes:
619
Out: 10.0.1.254/23 --> 172.20.101.10/54242;tcp, If: ge-0/0/2.0, Pkts: 8,
Bytes: 589
Total sessions: 1
Question: Which input and output interfaces are

used for the Telnet session?
Answer: The VLAN interface is used as the input

interface. The ge-0/0/2 interface is used as the
output interface.
Note
You might see more than one session. In
addition to the session you initiated, you
might also see a session originating from
your local Juniper customer network as the
remote student team tests their
implementation.
Step 2.11
terminate the Telnet session.
vr-device (ttypl)
login: "cclient aborted login

Connection closed by foreign host.
al@vr-device>

Do not proceed to the next lab part until directed by the instruc1tor to do
so.
Part 3: Configuring NAT Implementation-Local Environment
In this lab part, you make additional configuration changes to expand your
implementation to allow internal hosts to reach internal resources that are publicly
available by connecting to the public-facing IP address on your SRX 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 Telnet session established with the virtual router, initiate a Telnet session
to the external NAT address on the ge-0/0/2 interface for your assigned SF�X device.
If your assigned device is SRX1, use the 1 o. o. l .126 address. If your assigned
device is SRX2,use the lo. o. l. 2 54 address. Source the telnet connection from
the virtual router's routing instance associated with your local Juniper customer
network as shown on the lab network diagram.
al@vr-device> telnet address routing-instance vrlocal-Juniper-VLAN
Trying 10.0.1.126 ...

Is NAT occurring?

does not establish. 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
From your assigned SRX device , Enter configuration mode and review the existing
NAT implementation to see if you can identify the problem.
[edit]
lab@srxA-1# edit security nat destination rule-set From-Internet

lab@srxA-1# show
from zone Public-Facing;
rule To-Telnet-Server {
match {
source-address [ 172.20.96.0/20 172.20.192.0/19 ];
}
then {

lab@srxA-1#
Question: Can you identify the problem?
Answer: The rule-set From-Internet NAT

currently applies only to traffic originating in the
zone Public-Facing. Other traffic is not being
evaluated for NAT.
Step 3.3
Modify the existing rule set From-Internet so sessions initiated from the local
Juniper and ACME customer networks will be evaluated for NAT. When you are
finished, commit the configuration.
lab@srxA-1# set from zone Juniper-local

lab@srxi\-1# set from zone ACME-local

lab@srxi\-1# show
from zone [ ACME-SV Juniper-SV Public-Facing J;
rule To··Telnet-Server {
match {
source-address [ 172.20.96.0/20 172.20.192.0/19 J;
}
then {

lab@srxA-1# commit
commit complete
Step 3.4
From the Telnet session established with the virtual router, initiate the Telnet
session again. If your assigned device is SRX1, use the 1 o. o. 1. 126 adclress. If
your assigned device is SRX2,use the 1 o. o.1. 254 address.
al@vr-device> telnet address routing-instance VR-Juniper-instance
Trying 10.0.1.126 ...

does not establish.
Step 3.5
session command.
Total sessions: O

prevent a session from establishing?
Answer: The output indicates that no session is

forming. One likely reason is that the initiating flow
does not match a security policy with a permit
action between the source zone and the destination
zone.
Step 3.6
Review the existing security policy that accommodates the traffic sent between the
local Juniper and ACME customer networks.
lab@srxA-1# top edit security policies

lab@srxA-1# show from-zone Juniper-local to-zone ACME-local

lab@srxA-1#

Question: Can you identify the problem?
Answer: No security policies are in place to

accommodate traffic between the two local
customer networks.
Step 3.7
Create a security policy that accommodates Telnet traffic sent from your local
Juniper customer network to your local ACME customer network. Use the existing
vrl oyaddress-book entry for your policy's source-addres s match, where the
value of yis the remainder of the VLAN ID associated with your local Juniper
customer network. Configure the destination-addres s to match the
address-book entry vr20Y, where the value of yis the remainder of the VLAN ID
associated with your local ACME customer network. When you are finished, commit
the configuration.
[email protected],-1# edit from-zone Juniper-local to-zone ACME-local
[edit security policies from-zone Juniper-SV to-zone ACME-SV]

[email protected],-1# set policy Allow-Internal-Telnet match source-address vrlOy

lab@sr:X.Z,-1# set policy Allow-Internal-Telnet match destination-address vr20V

lab@srxA-1# set policy Allow-Internal-Telnet match application junos-telnet

[email protected],-1# set policy Allow-Internal-Telnet then permit
[edit se,curity policies from-zone Juniper-SV to-zone ACME-SV]

lab@srxA-1# show
policy Allow-Internal-Telnet {
match {
}
then. {
permit;

[email protected]# commit
commit complete

lab@srxA-1#

Step3.8
session again. If your assigned device is SRX1, use the 1 o. o. 1.126 address. If
your assigned device is SRX2,use the lo. o. 1.254 address.
al@vr-device> telnet address routing-instance VR-Juniper-instance
Trying 10.0.1.126...
Escape character is 'Al•
vr-device (ttypO)
login:

is successful.
Step3.9
session command.
Session ID: 24091, Policy name: Allow-Internal-Telnet/12, Timeout: 1760, Valid
619
Bytes: 589
Total sessions: 1
Question: Is the Telnet session found in the session

table?
Answer: Yes. The Telnet session is found in the

session table.
Step3.10

vr-device (ttypl)
login: ACClient aborted login

al@vr-device>
Step3.U
From your assigned SRX device, use the run show security nat
destination SUlllIIlary command to confirm that traffic initiated from the ACME
customer zone will be evaluated by the rule-set From-Internet NAT.
lab@srX:11.-1# top
[edit]
lab@srX:11.-1# run show security nat destination summary
Total pools: 1
Pool name Address Routing Port Total
Range Instance Address
Telnet-Server 172.20.201.10 - 172.20.201.10 default 0 1
Total rules: 1
Rule name Rule set From Action
To-Telnet-Server From-Internet ACME-SV
Juniper-SV
Public-Facing Telnet-Server
[edit]
lab@srxA-1#
Step3.12
Use the run show security policies command to confirm that intrazone
traffic is configured for the ACME customer zone.
[edit]
lab@srxl,-1# run show security policies from-zone ACME-local to-zone ACME-local
From zone: ACME-SV, To zone: ACME-SV
Policy: intrazone-ACME-SV, State: enabled, Index: 5, Scope Policy: 0, Sequence
number: 1
Source addresses: any
Destination addresses: any
Applications: any
Action: permit
Step3.13

From the Telnet session established with the virtual router, initiate a Telnet session
to the external NAT address on the ge-0/0/2 interface for your assigned SRX device.
If your assigned device is SRX1, use the 1 o.o.1. 126 address. If your assigned
device is SRX2,use the 1 o.o.1. 2 54 address. Source the telnet connection from
the virtual router's routing instance associated with your local ACME customer
network.
al@vr-device> telnet address routing-instance vrlocal-ACME-VLAN
Trying 10.0.1.126...

does not establish.
Step3.14
From the Telnet session established with your assigned SRX device, issue the run
show security flow session command.
[edit]
128
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.
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.

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 SRX device, destination NAT is
performed and the initiating flow is sent on 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 SRX 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.15
Configure double NAT by adding interface-based source NAT to disguise the
IP address of the originating host.Name the NAT rule set
Accommodate-Switched-Network. Name the rule NAT-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.
[edit]
lab@srxA,-1# edit security nat source
[edit se,curity nat source]

lab@srxA,-1# edit rule-set Accommodate-Switched-Network
[edit se,curity nat source rule-set Accommodate-Switched-Network]

[email protected]# set from interface vlan. local-ACME-unit

[edit security nat source rule-set Accommodate-Switched-Network]
lab@srxA-1# set to interface vlan.local-ACME-unit
[edit security nat source rule-set Accommodate-Switched-Network]

lab@srxA-1# edit rule NAT-Return-Flow
[edit security nat source rule-set Accommodate-Switched-Network rule

NAT-Return-Flow]
lab@srxA-1# set match source-address local-ACME-network/24

NAT-Return-Flow]
lab@srxA-1# set match destination-address 0/0

NAT-Return-Flow]
lab@srxA-1# set then source-nat interface

NAT-Return-Flow]
lab@srxA-1# show
match {
source-address 172.20.201.0/24;
}
then {
source-nat
interface;

NAT-Return-Flow]
lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 3.16
session again. If your assigned device is SRX1, use the 1 o. o.1.126 address. If
your assigned device is SRX2,use the 1 o. o .1. 254 address.

al@vr-device> telnet address routing-instance vrlocal-ACME-VLAN
Trying 10.0.1.126 ...
A
Escape character is ' l'.
vr-device (ttyp3)
login:

is successful.
7
Step 3.1
session command.
[edit]
619
Out: 172.20.201.10/23 --> 172.20.201.l/21318;tcp, If: vlan.201, Pkts: 8,
Bytes: 589
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
SRX device. The destination host will use the
Layer 2 information associated with your assigned
SRX device for delivery
Note
The return flow will now transit your

assigned SRX devices. The SRX device will
perform the reverse NAT operations and
the originating host will receive the syn-ack
from the expected IP address.
Step 3.18

vr-device (ttypl)

al@vr-device>
so.
Part 4: Implementing 1Pv6 NAT-NAT64
In this lab part, you configure and verify operations for NAT64.This 1Pv6 NAT
implementation requires both destination NAT and source NAT for proper operation.
Both pod teams will configure the same 1Pv6 subnet addressing within the local
Juniper customer network, and will perform NAT64 to properly translate ttle 1Pv6
addresses to 1Pv4 addresses.
The 1Pv6 NAT implementation will allow an 1Pv6 host within the Juniper customer
network on the virtual router to telnet to an 1Pv4 host resource on the remote
student team's ACME customer network through a public-facing IP address
associated with the ge-0/0/2 interface of your assigned SRX device.
Step4.1
Configure your VLAN interface associated with your local Juniper customer's network
with the 1Pv6 address 2001:db8::1/64.
[edit]
lab@srxA-1# set interfaces vlan unit local-Juniper-unit family inet6 address
2001:dbS::1/64
Step4.2
Delete the 1Pv4 address from your VLAN interface associated with your local Juniper
customer's network.
[edit]
lab@srxA-1# delete interfaces vlan unit local-Juniper-unit family inet
Step4.3
For steps 4.3-4.5, you will configure destination NAT64 to translate the 1Pv6
destination traffic to an 1Pv4 address. Navigate to the [edit security nat
destination] hierarchy. Configure a destination NAT pool named
ipv6-dest-pool with the IP address of the remote student team's external NAT
address. If your assigned device is SRX1, use the lo. o. l. 254 address. If your
assigned device is SRX2,use the 10. o.1.126 address.
[edit]

lab@srx�-1# set pool ipv6-dest-pool address address

lab@srx..�-1# show
pool ipv6-dest-pool
address 10.0.1.254/32;

lab@srxA-1#
Step4.4
Configure a destination NAT rule set named ipv6-dest with a directional context
that will perform NAT on traffic coming from your local Juniper customer network's
zone.
[email protected]�-1# set rule-set ipv6-dest from zone Juniper-local
Step4.5
Configure a rule within the rule set ipv6 -dest named ipv6-local to match
traffic destined for the 1Pv6 address 2001:dbB::5/128. Next, specify that the
destination address of the matching traffic will be translated to the pool
ipv6-dest-pool.
lab@srxA-1# set rule-set ipv6-dest rule ipv6-local match destination-address
2001:dbS::5/128

lab@srxl\-1# set rule-set ipv6-dest rule ipv6-local then destination-nat pool
ipv6 ··dest-pool
Step4.6
For steps 4.6-4.8, you will configure source NAT64 to translate the 1Pv6 source
traffic to an 1Pv4 address. Navigate to the [edit security nat source)
hierarchy. Configure a source NAT pool named ipv6-source-pool with an
external NAT64 IP address on the Public-Facing zone subnet. If your assigned
device is SRX1, specify the 1 o. o. 1. 1 o address. If your assigned device is SRX2,
specify the 1 o. o. 1. 21 o address.
lab@srxA-1# top edit security nat source
[edit security nat source]

lab@srxJ!,-1# set pool ipv6-source-pool address address

lab@srxJ!,-1#

Step4.7
Configure a source NAT rule set named ipv6-source with a directional context
that will perform NAT on traffic coming from your local Juniper customer network's
zone and destined for the Public-Facing zone.
lab@srxA-1# set rule-set ipv6-source from zone Juniper-local

lab@srxA-1# set rule-set ipv6-source to zone Public-Facing
Step4.8
Configure a source NAT rule named ipv6-host to match traffic from the source
address 2001:dbS::10/128. Specify the rule to match the destination address of
the IP address of the ipv6-dest -pool you configured in Step 4.3. If your
assigned device is SRX1, use the 1 o. o. 1. 2 54 address. If your assigned device is
SRX2,use the 1 o. o. 1. 126 address. Also specify that the source address of the
matching traffic will be translated to the pool ipv6-source -pool.
lab@srxA-1# set rule-set ipv6-source rule ipv6-host match source-address
2001:dbS::10/128

lab@srxA-1# set rule-set ipv6-source rule ipv6-host match destination-address
address

lab@srxA-1# set rule-set ipv6-source rule ipv6-host then source-nat pool
ipv6-source-pool

lab@srxA-1# show
pool ipv6-source-pool
address {
10.0.1.10/32;
rule-set ipv6-source {
from zone Juniper-SV;
to zone Public-Facing;
rule ipv6-host {
match {
source-address 2001:dbS: :10/128;
}
then {
source-nat
pool {
ipv6-source-pool;
Lab 4-28 • Advanced NAT Implementations (Detailed) www.j1Jniper.net

Step4.9
Navigate to the [edit security nat destination rule-set
From-Internet rule To-Telnet-Server] hierarchy. Configure an
additional matching source address for the remote team's external NAT address that
was configured in step 4.6. If your assigned device is SRX1, specify the
1 o. o.1 . 21 o address. If your assigned device is SRX2, specify the 1 o. o. 1 . 1 o
address.
lab@sr��-1# top edit security nat destination rule-set From-Internet rule
To-T,:!lnet-Server

lab@srxA-1# set match source-address address
[edit s,�curity nat destination rule-set From-Internet rule To-Telnet-Server]

lab@srxA-1# show
match {
source-address [ 172.20.96.0/20 172.20.192.0/19 10.0.1.210/32 J;
}
then {

lab@srxA-1#
Step4.10
Within your local Juniper customer network security zone, create an address book
entry named ipv6-address for the 1Pv6 address 2001:dbS::10/128.
lab@srxl,-1# top set security address-book Juniper-local address ipv6-address
2001::dbS::10/128
Step4.11
Create another address book entry named Remote-Public under the
Public-Facing security zone for the 1 o. o.1. 0/24 subnet.
lab@srxl,-1# top set security address-book Public-Facing address Remote-Public
10.0.1.0/24
Step4.12
Configure NDP proxy on your assigned SRX device at the [edit security natl
hierarchy. The SRX device should respond to any NDP requests for the 1Pv6 address
2001:db8::5/128 on your local vlan interface within your Juniper customer
network.

lab@srxA-1# top edit security nat
[edit security natl

lab@srxA-1# set proxy-ndp interface vlan.local-Juniper-unit address
2001:db8: :5/128
[edit security natl

lab@srxA-1# show
proxy-ndp {
address {
2001:db8::5/128;
Step4.13
Navigate to the [edit security policies] hierarchy. Configure a security
policy named Allow-ipv6-Telnet from your local Juniper customer zone to the
Public-Facing zone to allow only telnet traffic. Configure the source address to
match the address book entry ipv6-address. Specify the destination address as
any.
[edit security natl

lab@srxA-1# set from-zone Juniper-local to-zone Public-Facing policy
Allow-ipv6-Telnet match source-address ipv6-address

Allow-ipv6-Telnet match destination-address any

Allow-ipv6-Telnet match application junos-telnet

Allow-ipv6-Telnet then permit

lab@srxA-1#
Step4.14
Configure another security policy named Allow-Remote-Public from the
Public-Facing zone to your local ACME customer zone to allow only telnet traffic
from the remote student team. Configure the source-address to match the
address book entry Remote-Public. Configure the destination-address to
match the address-book entry vr2 oy, where the value of y is the remainder of the
VLAN ID associated with your local ACME customer network.

lab@srxA-1# set from-zone Public-Facing to-zone ACME-local policy
Allow-Remote-Public match source-address Remote-Public

Allow-Remote-Public match destination-address vr20y

Allow·-Remote-Public match application junos-telnet

Allow-Remote-Public then permit

lab@srxA-1# show from-zone Public-Facing to-zone ACME-local
policy Allow-Remote-Public
match {
source-address Remote-Public;
}
then {
permit;
Step 4.15,
Enable 1Pv6 flow-based mode on your assigned SRX device at the [edit
security forwarding-options] hierarchy and then commit the
configuration. The SRX will require a reboot to enable 1Pv6 flow-based mode. Issue
the command request system reboot after the commit is complete.
lab@srxA-1# top set security forwarding-options family inet6 mode flow-based

lab@srxi\-1# commit
warning: You have enabled/disabled inet6 flow.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
commit complete

lab@srxl\-1# run request system reboot
Reboot the system ? [yes,no] (no) yes
Shutdown NOW!
[pid 3934]

*** FINAL System shutdown message from lab@srxA-1 ***
System going down IMMEDIATELY

Note
You might not see a message for the

SRX device to reboot after the commit
completes. This means that the SRX device
has already been enabled for 1Pv6
flow-based mode.
Step4.16
Log back into the SRX device as user lab after it has finished rebooting.
srxA-1 (ttyuO)
login: lab
Password:
--- JUNOS 12.1X44-D10.4 built 2013-01-08 05:51:59 UTC

lab@srxA-1>
Ensure that the remote student team within your pod has finished steps
4.1 to 4.16 before continuing.
Step4.17
Test your recently configured NAT64 implementation. Return to the Telnet session
established with the virtual router.
From the Telnet session established with the virtual router, initiate an 1Pv6 Telnet
session to the 1Pv6 address 2001:dbS::5. Source the telnet connection from the
routing instance associated with your local Juniper customer network.
al@vr-device> telnet inet6 2001:dbS::5 routing-instance vrlocal-Juniper-VLAN
Trying 2001:dbB::5...
Connected to 2001:dbB::5.
vr-device (ttypl)
login:

should establish successfully.

Step4.18
command.
Session ID: 11232, Policy name: Allow-ipv6-Telnet/ll, Timeout: 1788, Valid
In: 2001:db8::10/57707 --> 2001:db8::5/23;tcp, If: vlan.101, Pkts: 9, Bytes:
799
Out: 10.0.1.254/23 --> 10.0.l.10/21868;tcp, If: ge-0/0/2.0, Pkts: 8, Bytes:
589
Total sessions: 1
Question: What does the output display?
Answer: The output displays that NAT has modified

both the source and destination of the 1Pv6 address
as the packet traversed the SRX device.
Note
The return flow will now transit your

assigned SRX devices. The SRX device will
perform the reverse NAT operations and
the originating host will receive the syn-ack
from the expected IP address.
Note
You might see more than one session. In

addition to the session you initiated, you
might also see a session originating from
your local Juniper customer network as the
remote student team tests their
implementation.
Step4.rn
Issue the commands show security nat destination rule all and
show security nat source rule ipv6-host.
lab@srxl�-1> show security nat destination rule all
Total destination-nat rules: 2
Total referenced IPv4/IPv6 ip-prefixes: 4/1
Destination NAT rule: To-Telnet-Server Rule-set: From-Internet

Rule-Id 1
Rule position 1
From zone ACME-SV
Juniper-SV
Public-Facing

Match
Source addresses 172.20.96.0 - 172.20.111.255
172.20.192.0 - 172.20.223.255
10.0.1.210 - 10.0.1.210
Destination addresses 10.0.1.126 - 10.0.1.126
Destination port 23
Action Telnet-Server
Translation hits 0
Destination NAT rule: ipv6-local Rule-set: ipv6-dest

Rule-Id 2
Rule position 2
From zone Juniper-SV
Destination addresses 2001:db8: :5 - 2001:db8: :5
Destination port 0
Action ipv6-dest-pool
Translation hits 5
lab@srxA-1> show security nat source rule ipv6-host
source NAT rule: ipv6-host Rule-set: ipv6-source

Rule-Id 2
Rule position 2
From zone Juniper-SV
To zone Public-Facing
Match
Source addresses 2001:db8::10 - 2001:db8::10
Destination addresses 10.0.1.254 - 10.0.1.254
Destination port 0 - 0
Action ipv6-source-pool
Persistent NAT type N/A
Persistent NAT mapping type address-port-mapping
Inactivity timeout 0
Max session number 0
Translation hits 2
Question: Do you see translation hits occurring in

the output for the 1Pv6 NAT rules?
Answer: Yes, the output should display that NAT has

modified both the source and destination of the
1Pv6 address, and that translation hits have
occurred.
Step4.20
Lab 4-34 • Advanced NAT Implementations (Detailed) www.j,uniper.net

vr-device (ttypl)

al@vr-device>
so.
Part 5: Implementing 1Pv6 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. Both pod teams
will configure source and destination NAT to perform NAT46, to translate the 1Pv4
addresses to 1Pv6 addresses.
The 1Pv6 NAT implementation will allow an 1Pv4 host within the ACME customer
network on the virtual router to telnet to an 1Pv6 host resource on the remote
student team's Juniper customer network through a public-facing IP address
associated with the ge-0/0/2 interface.
Step 5.1
For steps 5.1-5.3, you will configure destination NAT to translate a local 1Pv4
address within the ACME customer network to a public facing address that will be
used for NAT46. Enter configuration mode and navigate to the [edit security
nat destination] hierarchy. Configure a destination NAT pool named
nat46public-dest-pool with a public-facing address that will be used for
NAT46. If your assigned device is SRX1, specify the address 1 o. o.1. 211. If your
assigned device is SRX2, configure the address 1 o. o. 1. 11.
[edit]
lab@srx�-1# edit security nat destination

lab@srxA-1# set pool nat46public-dest-pool address address
Step 5.2
Configure a destination NAT rule set named nat46public-dest with a
directional context that will perform NAT on traffic coming from your local ACME
customer network's zone.
lab@srxA-1# set rule-set nat46public-dest from zone ACME-local

Step 5.3
Configure a rule within the rule set nat46public-dest named ipv4-.local to
match traffic destined for 172. 20. address. 5/32, where address is your local
ACME customer network. Then specify that the destination address of the matching
traffic will be translated to the pool nat46public-dest-pool.
lab@srxA-1# set rule-set nat46public-dest rule ipv4-local match
destination-address 172.20.address.5/32

lab@srxA-1# set rule-set nat46public-dest rule ipv4-local then destination-nat
pool nat46public-dest-pool
Step 5.4
Configure another destination NAT pool named nat46remote-dest-pool with
the 1Pv6 address 2008:dbS::10/128. This pool will be used to perform NAT46 on
the traffic from the remote student team's ACME customer network.
lab@srxA-1# set pool nat46remote-dest-pool address 2001:dbS::10/128
Step 5.5
Under the destination NAT rule-set From-Internet, configure another source NAT
rule named nat46-remote to match Telnet traffic sourced from the
172.20.192.0/19 prefix. Apply this rule to traffic destined to the remote team's
nat46public-dest-pool IP address. If your assigned device is SRX1, specify
the address Io. o .1 .11. If your assigned device is SRX2, configure the address
1 o. o. 1 . 211. Specify that the destination address of the matching traffic will be
translated to the pool nat46remote-dest-pool.
Note
The 172. 20 .192. 0/19 prefix will

accommodate the local and remote ACME
customer networks.

lab@srxA-1# set rule-set From-Internet rule nat46-remote match source-address
172.20.192.0/19

lab@srxA-1# set rule-set From-Internet rule nat46-remote match
destination-address address

lab@srxA-1# set rule-set From-Internet rule nat46-remote match destination-port
23

lab@srxA-1# set rule-set From-Internet rule nat46-remote then destination-nat
pool nat46remote-dest-pool

Step 5.6
For steps 5.6-5.8, you will configure source NAT46 to translate the source 1Pv4
address to an 1Pv6 address. Navigate to the [edit security nat source)
hierarchy. Configure a source NAT pool named nat46-source-pool with the
1Pv6 address 2001:db8::6/128.
[email protected]# top edit security nat source

[email protected]# set pool nat46-source-pool address 2001:dbB::6/128

[email protected]#
Step 5.7
Configure a NAT rule-set named nat46-source with a directional context that will
perform source NAT on traffic coming from the Public-Facing zone and
destined for your local Juniper customer network's zone.
lab@srxA-1# set rule-set nat46-source from zone Public-Facing

lab@srxA-1# set rule-set nat46-source to zone Juniper-local
Step 5.8
Configure a source NAT rule for the nat46-source rule-set named nat46-host
to match traffic sourced from the 172.20.192.0/19 prefix. Apply this rule to traffic
destined to the 2001:db8::10/128 address. Then specify that the source address of
the matching traffic will be translated to the pool nat46-source-pool.
lab@srxJl,-1# set rule-set nat46-source rule nat46-host match source-address
172.20.192.0/19

lab@srxA-1# set rule-set nat46-source rule nat46-host match destination-address
2001:dbB::10/128

lab@srxA,-1# set rule-set nat46-source rule nat46-host then source-nat pool
nat4 6'-source-pool
Step 5.9
Configure NDP proxy on your assigned SRX device at the [edit security natl
hierarchy. The SRX device should respond to any NDP requests for the 1Pv6 address
2001:db8::6/128 on your local vlan interface within your Juniper customer
network.
[email protected]# top set security nat proxy-ndp interface vlan.1oca1-Juniper-unit
address 2001:dl>S::6/128

Step5.10
Configure proxy-arp on your local vlan interface within your ACME customer
network for 172. 20. address. 5/32, where address is your local ACME
customer network.
lab@srxA-1# top set security nat proxy-arp interface vlan.local-ACME-un.it
address 172.20.address.5/32
Step5.11
Create another address book entry named Remote-NAT46 under the
Public-Facing zone for the remote student team's source NAT address for
NAT46. If your assigned device is SRX1, use the address 1 o. o. l. 211. If your
assigned device is SRX2, use the address 1 o. o. 1. 11.
lab@srxA-1# top set security address-book Public-Facing address Remote-NAT46
address
Step5.12
Navigate to the [edit security policies] hierarchy. Configure a security
policy named Allow-NAT46-Local to allow Telnet traffic from your local ACME
customer zone to the remote student team's source NAT address for NAT46 on the
Public-Facing zone. Configure the source-addres s to match the
address-book entry vr20Y, where the value of yis the remainder of the \/LAN ID
associated with your local ACME customer network. Configure the
destination-address to match the address book entry Remote-NJlT46.

lab@srxA-1# set from-zone ACME-local to-zone Public-Facing policy
Allow-NAT46-Local match source-address vr20V

Allow-NAT46-Local match destination-address Remote-NAT46

Allow-NAT46-Local match application junos-telnet

Allow-NAT46-Local then permit
Step5.13
Configure another security policy named Allow-NAT46-Remote to allow Telnet
traffic from the remote student team on the Public-Facing zone to your local
Juniper customer zone. Configure the source address to match the address book
entry Remote-Partner-ACME. Configure the destination address to match the
address book entry ipv6-address. When finished, commit the configuration and
return to operational mode.
lab@srx�-1# set from-zone Public-Facing to-zone Juniper-local policy
Allow-NAT46-Remote match source-address Remote-Partner-ACME

lab@srx�-1# set from-zone Public-Facing to-zone Juniper-local policy
Allo,v-NAT46-Remote match destination-address ipv6-address

lab@srx.�-1# set from-zone Public-Facing to-zone Juniper-local policy
Allow-NAT46-Remote match application junos-telnet

lab@srxA-1# set from-zone Public-Facing to-zone Juniper-local policy
Allo,v-NAT46-Remote then permit

commit complete
lab@srxA-1>
Ensure that the remote student team within your pod has finished
Part 5 before continuing.
Step 5.14
Verify your recently configured NAT46 implementation. Return to the Telnet session
established with the virtual router.
From the Telnet session established with the virtual router, initiate a new Telnet
session to the address 172. 20. address. 5, where address is your local ACME
customer network. Source the Telnet connection from the virtual router's routing
instance associated with your local ACME customer network as shown on the lab
network diagram.
al@vr-device> telnet 172.20.address.5 routing-instance vrlocal-ACME-VLAN
Trying 172.20.201.5 ...
vr-device (ttypl)
login:

should establish successfully.

Step 5.15
command.
Session ID: 20265, Policy name: Allow-NAT46-Local/16, Timeout: 1780, Valid
In: 172.20.201.10/64888 --> 172.20.201.5/23;tcp, If: vlan.201, Pkts: 9, Bytes:
619
Out: 10.0.1.211/23 --> 172.20.201.10/64888;tcp, If: ge-0/0/2.0, Pkts: 8,
Bytes: 589
Total sessions: 1
Question: Does the output display 1Pv6

translations?
Answer: No, the output does not display any 1Pv6

NAT translations when testing the Telnet connection
from your local pod team's virtual router. However,
the remote student team within your pod should
see 1Pv6 translations when you test your Telnet
connection, and vice versa.
Step 5.16
terminate the Telnet session, then log out using the exit command.
vr-device (ttypl)

al@vr-device> exit
Step 5.17
From your assigned SRX device, log out of your assigned device using the exit
command.
lab@srxA-1> exit
srxA-1 (ttyuO)
login:

Tell your instructor that you have completed this lab.

Mana@mentAddressing
srxA-1 srxD-1 I
srxA-2 srxD-2 I
srxB-1 vr-<levice I
srxB-2 Server
srxC-1 Gateway
srxC-2 I Term Server

Pod A Network Diagram: Advanced NAT

Implementations Lab (Parts 1-3)
172.20 1010/24
L::'.::J
�)
vr201
--'
Jun ipe r ':N
- ,__M_
AC E--':N
-- Virtual Routers -- Juniper-WF
:(12013JunlperNetwork,,
, r
lnc.AAnfits remve(! Juniper Worldwide Education SeMces WWW 1un1p
-- �-��
- --·- ----· -----l-- ---- "�
Pod A Network Diagram: Advanced NAT

10.0.1.D/24
vlan.202
1Pv6Subnet
Added
ACME-':N Juniper-WF AC M E W
- F
�--��- ��
;s,... , "' ," r
JUnL�f
.,,,
;1)::!�J.3J1Jnii.trNttw\?fk$, l�t Allrl#l1S m"l'M'd Worldwide Education Services W'l•}W JUlllP

- �� - --

Pod B Network Diagram: Advanced NAT

:--El
vlan.103
-- Virtual Routers _....

Juniper-SY ACME-SY Junipe r-WF ACME-WF
13JunlperNetwol'IOf Inc AU tlghti resenti,d JUnlPer

,,cc�
Worldwide Education Services WWW Juniper net
---'-� -� ��-�-"""-- - -� -
Pod B Network Diagram: Advanced NAT

1001 0/24
vlan.204
1Pv6Subnet
Added
vr103 I
Juniper- SY Juniper-WF

Pod C Network Diagram: Advanced NAT

vlan.105
--VirwalRouters .--
Juniper-SY ACME-SY Junipe r-WF ACME-WF
()-2013Jt1nlperNetwork,, lttt: AIJnJts re1erv� JUn� Worldwide Education Services WNW JUn1p
--- - -A- �� j
Pod C Network Diagram: Advanced NAT

Implementations Lab {Parts 4-5)
(.1) ge-0/0/2 10010/24
vlan.206
1Pv6Subnet
Added
Juniper-SY ACME-WF
IS)::?01JJunlp..,tJetwork;., lM AUrl�1S ,,..i:r�lj JUn1Per

""'�
Worldwide Education Services IWNI Jlln1p
-----'" � " - - ----1

Pod D Network Diagram: Advanced NAT

Implementations Lab (Parts 1-3}
Host 172.31.15.1
vlan.107 (�lan208
172 20 208.Q/24
(10)
Juniper-SY ACME-SV -- Virtual Routers -- Juniper-WF ACME-WF

i.(F' ¥"J, ""� , '
13{�;":.��ln¢,Allrlght$((1'Serve:d ...._� �� Junm WorldwideEducationServices Wll>IWJUrllpernet
Pod D Network Diagram: Advanced NAT

Implementations Lab (Parts 4-5}
(1) ge-0/0/2 10010/24
vlan.208
1Pv6Subnet
Added (10)
ACME-SV Juniper-WF ACME-WF


Lab
Hub-and-Spoke IPsec VPNs (Detailed)
In this lab, you will load the baseline configuration for your device. The configuration will
include interfaces, interfaces assigned to their zones, security policies to allow traffic
between zones, and a stateless firewall filter for selective packet-based services. You will
then configure your device to act as a hub in a hub-and-spoke IP Security (IPsec) virtual
private network (VPN). You will use the loopback interface as your gateway interface. The
spokes have been preconfigured with all the necessary requirements. The IPsec tunnel
will be configured to encrypt and pass traffic for the Local-VR network attached to each
student device. After completing your configuration, you will verify the IPsec functionality
on your local device.
Use the Junos command line interface (CLI) to load the baseline configuration.
Use the Junos CLI to configure the IPsec VPN parameters.
Assign interfaces to security zones.
Implement security policies between zones.
Verify that the expected traffic traverses the VPN.
Monitor the effects of the configuration from both the local device.
www.juniper.net Hub-and-Spoke IPsec VPNs (Detailed) • Lab 5-1

equipment. Once you are familiar with the access details, you will use the CU to log
in to your designated station. Then, you will load the starting configuration for Lab 5.
Next, you will run a ping command from the Local-VR routing instance to ensure
connectivity.
Note

assigned device.
Step 1.1
your instructor if you are not certain. Consult the management network diagram to


Step 1.2
Access the CU at your station using either the console, Telnet, or SSH as directed by

� Open in a tab
I, Connect � J C,ncel j
Lab 5-2 • Hub-and-Spoke IPsec VPNs (Detailed) www.juniper.net

Step 1.3
the lab5-start. configfrom the /var /home/lab/aj sec/ directory.
srxA-1 (ttyuO)
login: lab
Password:

[edit]
lab@srxA-1# load override ajsec/lab5-start.config
[edit]
lab@srx/\.-1# commit
commit complete
[edit]
lab@srxA-1#
Step i4
In this lab you, use the Local-VR device, which is a routing instance on your assigned
SRX device, to test connectivity through the IPsec tunnels. Verify the connectivity of
the Local - VR routing instance by pinging the address of the Internet interface that
is associated with your assigned SRX device (ge-0/0/3).
[edit]
lab@srxA-1# run ping remote-ge-0/0/3-address routing-instance Local-VR rapid
PING 172.18.1.1 (172.18.1.1): 56 data bytes
! ! ! ! !
round-trip min/avg/max/stddev = l.825/l.947/2.051/0.096 ms

time. If they do not complete, contact the instructor
for assistance.
Step i5
Review the routing table of the Local-VR routing instance to determine which route is
used to reach the IP address in the previous step.
[edit]
lab@srxl\.-1# run show route table Local-VR.inet.O
www.juniper.net Hub-and-Spoke JPsec VPNs (Detailed) • Lab 5-3

Local-VR.inet.O: 3 destinations, 3 routes (3 active, 0 holddown, O hidden)
0.0.0.0/0 * [Static/SJ 00:31:55

> to 172.20.100.1 via lt-0/0/0.2
172.20.100.0/24 * [Direct/OJ 00:31:55
> via lt-0/0/0.2
172.20.100.10/32 *[Local/OJ 00:31:55

Internet router?
Answer: The default route (0.0.0.0/0), which is

statically configured, is used to reach the Internet
router.
Part 2: Configuring the Interfaces, Zones, and Policies
In this lab part, you configure the additional interfaces for this lab. You will create a
vpn zone and assign the appropriate interfaces. You will then create policies to
allow traffic to use this zone.
Step 2.1
Configure the stO interface with the IP address and network that is defined in the
following table for your assigned device. Ensure that the stO interface can facilitate
multiple Internet key exchange (IKE) and IPsec security associations
establishments.
stO Address Per Device

Assigned stO Address
Device
srxA-1 10.10.10.1/24
srxA-1 10.10.10.2/24
srxB-1 10.10.20.1/24
srxB-1 10.10.20.2/24
srxC-1 10.10.30.1/24
srxC-1 10.10.30.2/24
srxD-1 10.10.40.1/24
srxD-2 10.10.40.2/24
Lab 5-4 • Hub-and-Spoke !Psec VPNs (Detailed) www.juniper.net

Note
The network diagram for Lab 5 also shows

the necessary stO address for your
assigned device.
[edit]
lab@srxA,-1# edit interfaces stO.O
[edit interfaces stO unit OJ

lab@srxA,-1# set family inet address address/24

lab@srxA,-1# set multipoint
[edit interfaces sto unit OJ

[email protected]# show
multipoint;
family inet
address 10.10.10.1/24;

[email protected]#
Question: Why did you have to configure the stO

interface as a multipoint interface?
Answer: Recall from the lecture that the IPsec

tunnel is point-to-multipoint from the hub's
perspective. Therefore, you must configure the stO
interface as a multipoint interface.
Step 2.2
Navigate to the [edit security zones] hierarchy and add the loopback
interface to the untrust zone. When you add the loO interface to this zone, allow
IKE as host-inbound-traffic for this interface.
lab@srxA-1# top edit security zones

lab@srxA-1# set security-zone untrust interfaces loO.O host-inbound-traffic
system-services ike

lab@srxA-1#

Question: Why do we want to allow IKE on this

interface?
Answer: In this lab, the loopback interface acts as

the ingress and egress interface for our tunnel.
Therefore, the source of local IKE negotiation
packets comes from this interface. This interface is
also the destination of incoming IKE packets. For
the negotiation to succeed, we must enable the
interface to accept this traffic.
Step 2.3
Create a zone named vpn and add the stO interface. Verify the recent changes to
both zones.
lab@srxA-1# set security-zone vpn interfaces stO.O

lab@srxA-1# show security-zone vpn
interfaces {
stO.O;

lab@srxA-1# show security-zone untrust
interfaces {
ge-0/0/3.0;
loo.a {
system-services {
ike;
Step 2.4
Navigate to the [edit security policies] hierarchy and create two policies.
The first policy should allow traffic from the trust zone to enter the vpn zone and
should be named local -VR-to-vpn. The second policy should allow traffic to
enter the trust zone from the vpn zone and should be named
vpn-to-local-VR. When you are finished, commit the configuration c1nd exit to
operational mode.
lab@srxA-1# up 1 edit policies from-zone trust to-zone vpn
[edit security policies from-zone trust to-zone vpn]

lab@srxA-1# set policy local-VR-to-vpn match source-address any


lab@srxA-1# set policy local-VR-to-vpn match destination-address any

lab@srxA-1# set policy local-VR-to-vpn match application any

lab@srxA-1# set policy local-VR-to-vpn then permit

lab@srxA-1# show
policy local-VR-to-vpn
match {
source-address any;
application any;
}
then {
permit;

lab@srxA-1# up 1 edit from-zone vpn to-zone trust
[edit security policies from-zone vpn to-zone trust]

lab@srxl,-1# set policy vpn-to-local-VR match source-address any

lab@srxA-1# set policy vpn-to-local-VR match destination-address any

lab@srxl,-1# set policy vpn-to-local-VR match application any

lab@srxA-1# set policy vpn-to-local-VR then permit

lab@srxl,-1# show
policy vpn-to-local-VR
match {
source-address any;
application any;
}
then {
permit;

commit complete
lab@srxA-1>
www.juniper.net Hub-and-Spoke IPsec VPNs (Detailed) • Lab 5- 7

Note
For the purposes of this lab, we want to
allow all traffic, from the Local-YR network
to the spoke sites, to pass through the
IPsec VPN and vice versa. In a production
network this might not be the ideal
situation, and you can limit the traffic
allowed to pass through the IPsec tunnel by
restricting the source, destination, and
applications allowed.
so.
Part 3: Configuring IKE and IPsec Properties
In this lab part, you configure the properties to establish the IKE security
associations (SAs). You will also configure the necessary IPsec properties to
establish your IPsec SAs.
Step 3.1
Enter configuration mode and navigate to the [edit security ike] hierarchy.
Begin by defining an IKE policy named policy-1. The spokes are configured to
use main mode, and they also takes advantage of the predefined standard
proposal-set. The spokes are also configured to use a pre-shared-key; the
key is juniper. Configure your IKE policy to match the spokes' settings. Heview the
policy before continuing.
[edit]
lab@srxA-1# edit security ike
[edit security ike]

lab@srxA-1# set policy policy-l mode main
[edit security ike]

lab@srxA-1# set policy policy-l proposal-set standard
[edit security ike]

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

lab@srxA-1# show
policy policy-1 {
mode main;
Lab 5-8 • Hub-and-Spoke !Psec VPNs (Detailed) www.juniper.net

proposal-set standard;
pre-shared-key ascii-text "$9$TF6ABicvWxpOWxNdg4QFn"; ## SECRET-DATA
[edit security ike]

lab@srxA-1#
Step 3.2
Configure the gateway properties that are used to establish the IPsec VPN to the
spoke sites. You must define these gateways as spoke-1, spoke-2, and
spoke-3. As mentioned previously, you are using your loopback interface as the
gateway interface to reach the spokes. You should also specify the IP addresses on
the spokes with which you want to peer. This IP address is defined under the
address key word. This IP address is the spokes' loopback address, which is
defined on your network diagram. Take a quick look at the gateway configuration
before moving on.
[edit security ike]
lab@srxA-1# set gateway spoke-1 ike-policy policy-1
[edit security ike]

lab@srxA-1# set gateway spoke-1 address spoke-1-loopback-address
[edit security ike]

lab@srxA-1# set gateway spoke-1 external-interface loO.O
[edit security ike]

lab@srxA-1# set gateway spoke-2 ike-policy policy-1
[edit security ike]

lab@srxA-1# set gateway spoke-2 address spoke-2-loopback-address
[edit security ike]

[email protected]# set gateway spoke-2 external-interface loO. 0
[edit security ike]

[email protected]# set gateway spoke-3 ike-policy policy-1
[edit security ike]

[email protected]# set gateway spoke-3 address spoke-3-loopback-address
[edit security ike]

[email protected]# set gateway spoke-3 external-interface loO. 0
[edit security ike]

[email protected]# show
policy policy-1 {
mode main;
pre-shared-key ascii-text "$9$0VD91EyM87s2alK2aZU.m01R"; ## SECRET-DATA
}
gateway spoke-1 {
ike-policy policy-1;
address 192.168.10.3;
external-interface loO.O;

}
gateway spoke-2 {
address 192.168.10.4;
}
· gateway spoke-3 {
address 192.168.10.5;
Step 3.3
Navigate to the [edit security ipsec] hierarchy. Begin by defining the policy
named policy-sec. The spokes are configured to use the predefined standard
proposal-set. You must configure your local policy to use the same
proposal -set.
[edit security ike]
lab@srxA-1# up 1 edit ipsec
[edit security ipsec]

lab@srxA-1# set policy policy-sec proposal-set standard

lab@srxA-1#
Step 3.4
Configure the VPN parameters. You should name the VPNs
device-name-to-spoke-l,device-name-to-spoke-2,and
device-name-to-spoke-3 where device-name is your local SRX device's
host-name, and you must bind the stO.O interface to the VPNs. Then, define the
parameters to use for the IKE and IPsec SA negotiations. Begin by specifying the
gateway you need to use. You will use the gateways named spoke-1 for
device-name-to-spoke-1, spoke-2 for device-name-to-spoke-2, and
spoke-3 for device-name-to-spoke-3, which you defined in Step 3.3. After
specifying the gateways, indicate that this VPNs should use the IPsec policy named
policy-sec, which was defined in Step 3.3. The last step for your VPNs is to
configure the establish-tunnels immediately option. This option causes
the device to signal the IPsec VPN upon commit, instead of waiting for interesting
traffic to trigger the signaling of the VPN.
lab@srxA-1# set vpn device-name-to-spoke-1 bind-interface stO.O

lab@srxA-1# set vpn device-name-to-spoke-1 ike gateway spoke-1

lab@srxA-1# set vpn device-name-to-spoke-1 ike ipsec-policy policy-sec

lab@srxA-1# set vpn device-name-to-spoke-1 establish-tunnels iim11ediately


lab@srXJ\-1# set vpn device-name-to-spoke-2 ike gateway spoke-2


lab@srxA-1# set vpn device-name-to-spoke-2 establish-tunnels immediately


lab@srxA-1# set vpn device-name-to-spoke-3 ike gateway spoke-3


lab@srxA-1# set vpn device-name-to-spoke-3 establish-tunnels immediately

[email protected],-1# show
policy policy-sec {
vpn srxA-1-to-spoke-l {
bind-interface stO.O;
ike {
gateway spoke-1;
ipsec-policy policy-sec;
establish-tunnels immediately;
vpn srxA-1-to-spoke-2
ike {
gateway spoke-2;
establish-tunnels immediately;
vpn srxA,-1-to-spoke-3
bind-interface st0.0;
ike {
gateway spoke-3;
esta.blish-tunnels immediately;

Step 3.5
The next step is to define the traffic that you want to traverse the VPN, also known
as interesting traffic.As you might remember from the lecture, the hub-and-spoke
solution only works as a route-based VPN. Navigate to the [edit
routing-options] hierarchy level and configure static routes for each spoke's
hosts that are associated with your assigned SRX device. These host addresses are
defined on your network diagram in the Spoke Hosts table for your assigned
SRX device. Remember that you must use the interface address of the spoke's stO
interface for the next hop of the static route. The addresses of the stO interfaces for
the spokes can also be found on your network diagram.After you add these static
routes, commit the configuration, and exit to operational mode.
lab@srxA-1# set static route spoke-I-host-address next-hop spoke-1-stO-address
lab@srxA-1# set static route spoke-2-host-address next-hop spoke-2-stO-address
lab@srxA-1# set static route spoke-3-host-address next-hop spoke-3-stO-address
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.l;
route 192.171.10.3/32 next-hop 10.10.10.3;
route 192.171.10.4/32 next-hop 10.10.10.4;
route 192.171.10.5/32 next-hop 10.10.10.5;
commit complete
lab@srxA-1>
Do not proceed to the next lab part until directed by the instruc:tor to do
so.

Part 4: Verifying IPsec VPNs
In this lab part, you verify your IPsec VPN using operational mode commands. You
will begin by verifying that the IKE negotiation has completed and you have valid
SAs. You will then verify that you have established IPsec SAs. Next, you will use the
ping utility to verify that traffic traverses the IPsec tunnel to reach the spoke hosts.
After verifying that traffic traverses the IPsec tunnels, you will examine the next-hop
tunnel binding (NHTB) table.
Step4.1
Enter configuration mode and begin by verifying that your IKE SAs has been
established by issuing the run show security ike
security-associations command.
[edit]
lab@srxA-1# run show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
6356229 UP 06d4bed7e8f843bf b29ad645317fc091 Main 192.168.10.3
6356230 UP 53f6a5586c6d39e9 b16e00218bbcdbdf Main 192.168.10.4
6356231 UP 1134243107e8c9ea cda8320e185dc9d9 Main 192.168.10.5
Question: How many IKE SAs do you see?
Answer: As shown in the previous output, you

should see three IKE SAs.
Question: What is the State of the SAs?
Answer: The State should be UP. If the State is

displaying something different, please review your
IKE configuration and contact your instructor if
needed.
Step4.2
Next, take a look at the IPsec SA by issuing the run show security ipsec
[edit]
lab@srxA-1# run show security ipsec security-associations
Total active tunnels: 3
ID Algorithm SPI Life:sec/kb Mon vsys Port Gateway
<131073 ESP:3des/shal beea905b 3077/ unlim root 500 192.168.10.3
>131073 ESP:3des/shal 7328eaf7 3077/ unlim root 500 192.168.10.3
<131074 ESP:3des/shal 3flb22d6 3077/ unlim root 500 192.168.10.4
>131074 ESP:3des/shal c48fa439 3077/ unlim root 500 192.168.10.4

<131075 ESP:3des/shal 38edad35 3077/ unlim root 500 192.168.10.5
>131075 ESP:3des/shal c568clf 3077/ unlim root 500 192.168.10.5
Question: How many IPsec SAs do you see?
Answer: You should see three active tunnels, which

creates six IPsec SAs. If you do not see six SAs,
please review your IPsec configuration and contact
your instructor for assistance if needed.
Step4.3
Review the current statistics for your IPsec VPN using the run show security
ipsec statistics command.
[edit]
lab@srxA-1# run show security ipsec statistics
ESP Statistics:
Encrypted bytes: 0
Decrypted bytes: 0
Encrypted packets: 0
Decrypted packets: O
AH Statistics:
Input bytes: O
Output bytes: O
Input packets: o
Output packets: O
Errors:
AH authentication failures: 0, Replay errors: O
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: O
Question: Do you see any values?
Answer: No, the values should all be o.If any values

are already associated with this command, they
might be from previous sessions. You can clear
these statistics by issuing the command clear
security ipsec statistics.
Step4.4
Execute a quick verification test from your Local-VR routing instance to determine
whether traffic traverses your IPsec tunnel.You should ping each spoke's. host
address and source the ping from the Local - VR routing instance.Ping each host
address 5 times.Refer to your network diagram to obtain the host addresses of your
assigned spoke devices.

[edit]
lab@srxA-1# run ping spoke-1-host-address routing-instance Local-VR rapid
PING 192.171.10.3 (192.171.10.3): 56 data bytes
! ! ! ! !
--- 192.171.10.3 ping statistics ---
[edit]
lab@srxA-1# run ping spoke-2-host-address routing-instance Local-VR rapid
PING 192.171.10.4 (192.171.10.4): 56 data bytes
! ! ! ! !
--- 192.171.10.4 ping statistics ---
round-trip min/avg/max/stddev = l.994/2.952/5.650/l.363 ms
[edit]
lab@srxi\-1# run ping spoke-3-host-address routing-instance Local-VR rapid
PING 192.171.10.5 (192.171.10.5): 56 data bytes

Question: Did the ping tests succeed?
Answer: The ping tests to spoke 1 and spoke 2

succeeded; however, the ping test to spoke 3 did
not succeed.
Step 4.5
Examine the output from the run show security ipsec statistics
command.
[edit]
lab@srxA-1# run show security ipsec statistics
ESP Statistics:
Encrypted bytes: 1360
Decrypted bytes: 1260
Decrypted packets: 15
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: O
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
Bad headers: 0, Bad trailers: 0

Question: What does the output show?
Answer: The output shows that some of the traffic is

not being encrypted.
Step 4.6
Examine the routing table for the routes that lead to the spoke host address for your
assigned device.
[edit]
lab@srxA-1# run show route spoke-1-host-address table inet.0
inet.O: 14 destinations, 14 routes (14 active, O holddown, O hidden)

192.171.10.3/32 * [Static/SJ 01: 05: 06

> to 10.10.10.3 via stO.O
[edit]
lab@srxA-1# run show route spoke-2-host-address table inet.O

192.171.10.4/32 * [Static/SJ 01: 05: 10

> to 10.10.10.4 via stO.O
[edit]
lab@srxA-1# run show route spoke-3-host-address table inet.O

0.0.0.0/0 * [Static/SJ 21: 00: 55

> to 172.18.1.1 via ge-0/0/3.0

Question: Why is the static route that points to the
spoke 3 host address not present in the routing
table?
Answer: Although it might be difficult to answer this

question with the current available information, you
might remember from your network diagram that
spoke 3 is not a device that runs the Junos OS.
Because spoke 3 is not a Ju nos device, the NHTB
route cannot be automatically obtained.
Step 4.7
Issue the run show security ipsec next-hop-tunnels command to
view the current next-hop tunnel bindings.
[edit]
lab@srxA-1# run show security ipsec next-hop-tunnels
Next-hop gateway interface IPSec VPN name Flag
10.10.10.3 stO.O srxA-1-to-spoke-l Auto
10.10.10.4 stO.O srxA-1-to-spoke-2 Auto
Question: Is the next-hop tunnel binding for spoke 3

missing?
Answer: Yes. The next-hop tunnel binding for spoke

3 is not present in the output.
Question: What can you do to fix the NHTB

problem?
Answer: To fix the NHTB problem you must manually

add a static next-hop tunnel binding for spoke 3.
Step 4.8
Navigate to the [edit interfaces stO unit o family inet] hierarchy
level and add a static next hop tunnel binding for spoke 3's stO interface that is
associated with your assigned SRX device. When you are finished, commit the
configuration and exit to operational mode.

[edit)
lab@srxA-1# edit interfaces stO.O family inet
[edit interfaces stO unit O family inet]

lab@srxA-1# set next-hop-tunnel spoke-3-stO-address ipsec-vpn
local-device-to-spoke-3

lab@srxA-1# show
next-hop-tunnel 10.10.10.5 ipsec-vpn srxA-1-to-spoke-3;
address 10.10.10.1/24;

commit complete
Exiting configuration ·mode
lab@srxA-1>
Step4.9
Issue the show security ipsec next-hop-tunnels to view the current
next hop tunnel bindings.
lab@srxA-1> show security ipsec next-hop-tunnels
Next-hop gateway interface IPSec VPN name Flag IKE-ID
XAUTH username
10.10.10.3 sto.o srxA-1-to-spoke-l Auto
192.168.10.3
10.10.10.4 stO.O srxA-1-to-spoke-2 Auto
192.168.10.4
10.10.10.5 sto.o srxA-1-to-spoke-3 Static
192.168.10.5
Question: Is the next-hop tunnel binding present for

spoke 3?
Answer: Yes. Spoke 3 now has a static next-hop

tunnel binding.
Step4.10
Examine the routing table for the routes that lead to the spokes host address that
are associated with your assigned SRX device.
lab@srxA-1> show route spoke-l-host-address table inet.O

192.171.10.3/32 * [Static/SJ 01: 08: 56

> to 10.10.10.3 via stO.O

lab@srxA-1> show route spoke-2-host-address table inet.O

192 .171.10. 4/32 * [Static/SJ 01: 08: 58

> to 10.10.10.4 via sto.o
lab@srxA-1> show route spoke-3-host-address table inet.O

192 .171.10. 5/32 * [Static/SJ oo: 00: 12

> to 10.10.10.5 via stO.O
Question: Is a static route present for each of the

spoke host addresses?
Answer: Yes. All three static routes are present and

point towards the stO.O interface.
Step4.11
Clear the IPsec statistics by issuing the clear security ipsec statistics
command. Then, issue 5 ping packets, which are sourced from the interface that is
directly connected to the Juniper customer device, to each spoke host address that
is associated with your assigned SRX device.
lab@srxA-1> clear security ipsec statistics
lab@srxA-1> ping spoke-1-host-address routing-instance Local-VR rapid

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

PING 192.171.10.4 (192.171.10.4): 56 data bytes
! ! ! ! !
--- 192.171.10.4 ping statistics ---
round-trip min/avg/max/stddev = l.980/2.257/2.594/0.201 ms

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

Question: Did all three ping tests succeed?
Answer: Yes. All three ping tests are successful.
Step4.12
Issue the show security ipsec statistics command to verify that the
ping packets entered the IPsec tunnels.
lab@srxA-1> show security ipsec statistics
ESP Statistics:
AH Statistics:
Input bytes: O
Output bytes: O
Input packets: O
Output packets: O
Errors:
ESP authentication failures: 0, ESP decryption failures: O
Question: Did all the ping packets enter the IPsec

tunnels?
Answer: Yes. The output shows that 15 packets

were encrypted and 15 packets were decrypted.
These results show that every ping request packet
and every ping reply packet used the IPsec tunnels.
Step4.13
Log out of your assigned SRX device to return it to the login prompt.
lab@srxA-1> exit
srxA-1 (ttyuO)
login:


ge- 0/0/0(on all studentdevic:es)
ManagementAddressing
srxA-1 srxD-1
srxA-2 srxD-2
srxB-1 vr-device
srxB-2 Server
\ srxC- 1 ---�- Gateway

srxC-2 Term Server-- ---ii
Pod A Network Diagram: Hub-and-Spoke

IPsec VPNs Lab
A1
- Spoke Hosts A2
- Spoke Hosts
Spoke1A-1 Spoke1A-2
Spoke1 192.171.10.3 stO: 1010.10 3/24 stO 10.10.10.6/24 Spoke1 192.1711
- 0.6
Spoke2 192.171.10.4 loO 192.168.10.3 loO 192.168.10. 6 Spoke2 192.171.10.7
Spoke3 192.171.10.5 Spoke3 192.171.10.8
Spoke
stO 10.10.10. 4/24
loO 192.168.10.4
Spoke3A-1
stO: 1010.10.5/ 24
loO 192.168.10.5
NonJunos / �NonJunos
Device Device
srxA-1 srxA-2
stO 10.10.10.1/24 stO 10.1010.2/24
loO 192.168.10.1 'O) (.1) loO 192.168.10. 2
( ":!!.------"-----�
Local-VR L\:·::;;
---� 172.20.200.G/24

Pod B Network Diagram: Hub-and-Spoke

IPsec VPNs Lab
-
· B-1 SpokeHosts B·2 SpokeHosts
,
SpokelB-1 SpokelB-2
Spoke 1 192.171.20.3 Spoke 1 192.171.20.6
stO 10.10.20.3/24 stO: 10 10.20.6/24
Spoke2 192.171.20.4 loO: 192.168.20.3 loO 192.168.20.6 Spoke2 192.171.20.7
Spoke3 192.171.20.5 Spoke3 192.171.20.8
Spoke3B-1
stO: 10.10.20.5/24
loO 192.168.20.5
NonJunos / """NonJunos
Device Device
srxB-1 srxB-2
stO 10.10.20.1/24 stO 10.10.20.2/24
loO: 192.168.20.1 (.l) loO: 192.168.20.2
. O�ll-- "-=====;;..J
Local-VR ll(,1::l.
=
172.20.100.0/24 L----' 172.20.200.0/24
©2013JuniperNetwork,, Int AJlo:(ht� reserved JUn�f Worldwide Education Services 'l'll"IW )lHllP
- .
Pod C Network Diagram: Hub-and-Spoke

IPsec VPNs Lab
C-1 Spoke Hosts C-2 Spoke Hosts
Spoke1C-1
Spoke1 192.171.30.3 Spokel 192.171.30.0
stO: 10.10.30.3/24 �
Spoke2 192.171.30.4 loO: 192.168.30.3 Spoke2 192.171.30.7
Spoke3 192.171.30.5 Spoke3 192.171.30.8
NonJunos NonJunos
Device Device
srxC-2
stO 10.10.30.2/24
�-
( 10)
Local-VR �· _.: =) loO: 192.168.30.2
(i
--------'
172.20 1000/24 '----.J '----.J 172.20.200.0/24
0:?0.l3J1Jnlp1;rNetworlu:, lne .e.nrl:1tiUrt�erm1 JUn�

--- -- - - -----�
WorldwideEducatlonServices WJW'IJUfll
�"'---- -

Pod D Network Diagram: Hub-and-Spoke

IPsec VPNs Lab
-
D-1Spoke Hosts D-2SpokeHosts
Spoke10-1 Spokel 0-2
Spokel 192.171.40.3 Spoke1 192.171.40.6
stO: 10. 10.40.3/24 stO: 10.10.40.6/24
/
Spoke2 192.171. 40.4 loO 192.168.40.3 loO 192.168.40.6 Spoke2 192.171.40.7
Spoke3 192.171. 40.5 Spoke3 192.171. 40.8
Spoke30-1
stO 10.10 .40.5/24
loO 192.168.40.5
NonJunos / "'NonJunos
Device Device
srxD-1 srxD-2
stO 10.10 40 1/24 10 402/24
I 1
._
1 o0:_ 1_ 9 _ ._ 1_.._.._
_2 _.1_68.40 9 2.168.40.2
-!.;r-1�0:!JJ Local-VR Local-VR .
172.20.100.0/24 .____..... ... --� ( 172202000/24
(.1)
.10)
'ir
,&2 ,i "� _,[;'
/?;---- =-�--�- =
'l'. JUf7l1Der WorldwideEducatlonServices ¥'1WWJUA1pernet


Lab
Configuring Group VPNs (Detailed)
Overview
include interfaces, interfaces zone assignments, security policies to allow traffic between
zones, and a stateless firewall filter for selective packet-based services. You will then
configure your device to act as a member of a group IP Security (IPsec) virtual private
network (VPN). You will use the loopback interface as your gateway interface. The key
server has been preconfigured with all the necessary requirements. The IPsec tunnel will
be configured to encrypt and pass traffic for the Juniper customer networks attached to
each student device within a single pod. After completing your configuration, you will
verify the IPsec VPN status on your local device. You will also verify functionality and
reachability from the virtual router device. For all IP addresses and network information,
please refer to the Network Diagram: Lab 6 slide in your Lab Diagrams handout.
Use the Junos command-line interface (CLI) to load the baseline configuration.
Use the Junos CLI to configure the group IPsec VPN parameters.
Verify that the expected traffic traverses the VPN.
Monitor the effects of the configuration from the local device.
Verify reachability by using the virtual router (VR) device.
www.juniper.net Configuring Group VPNs (Detailed) • Lab 6-1

In this lab part, you change the current configuration for the loopback IP address.
You will then add the loopback to the appropriate zone and allow appropriate
host-bound traffic. You will configure the appropriate policies to allow
communication to the loopback interface.
Step 1.1


Step 1.2
Quick Connect (8}

Protocol:
Hostname:
Po1t

� Open in a tab
Connect J I Cancel
Step 1.3
Log in as user lab with the password lab123. Enter configuration mode and load
srxA-1 (ttyuO)
login: lab
Password:
Lab 6-2 • Configuring Group VPNs (Detailed) www.juniper.net


[edit]
lab@srxA-1# load override ajsec/lab6-start.config
load complete
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.4
Navigate to the [edit interfaces] hierarchy. Change the loopback interface
address to correlate with the loopback address for your assigned device, as defined
in the network diagram.
[edit]
[edit interfaces]
lab@srxA-1# show loO
unit O {
family inet {
filter {
input protect-cp;
address 192.168.1.1/32;
[edit interfaces]
[email protected],-1# delete loO. 0 family inet address address
[edit interfaces]
lab@srx A -1# set loO.O family inet address address
[edit interfaces]f
lab@srx A -1# show loO
unit O {
family inet {
filter {
input protect-cp;
address 192.168.11.1/32;
[edit interfaces]
lab@srxA-1#

Step 1.5
Navigate to the [edit security zones security-zone untrust]
hierarchyand add the loopback interface. After adding the interface , configure the
loopback interface to allow Internet keyexchange (IKE) packets.
[edit interfaces]
lab@srxA-1# top edit security zones security-zone untrust

lab@srxA-1# set interfaces loO.O

lab@srxA-1# set interfaces loO.O host-inbound-traffic system-services ike

lab@srxA-1#
Step 1.6
Navigate to the [edit security policies] hierarchyand create a policyto
allow traffic between the two interfaces configured under the untrust zone. The
name for this policyshould be intra-zone-policy. This policyshould allow all
traffic to pass between these interfaces. When finished, navigate to the top of the
configuration hierarchy, and commit the configuration.
lab@srxA-1# up 2
[edit security]
lab@srxA-1# edit policies

lab@srxA-1# edit from-zone untrust to-zone untrust
[edit security policies from-zone untrust to-zone untrust]

lab@srxA-1# set policy intra-zone-policy match source-address any

lab@srxA-1# set policy intra-zone-policy match destination-address any

lab@srxA-1# set policy intra-zone-policy match application any

lab@srxA-1# set policy intra-zone-policy then permit

lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#

so.
Part 2: Configuring the Group Member IPsec VPN
In this lab part, you configure the local group IPsec VPN parameters needed to
establish the VPN to the key server. Please refer to network diagram for the IP
address information for the key server. You will begin by defining your IKE policy and
gateway information. You then will configure the correct parameters for the IPsec SA.
Throughout this lab part, we include examples of the corresponding key server's
configuration.
Note
The following configuration is the key
server's IKE policy configuration that
corresponds to your next step.
[edit security group-vpn server]

instructor@vr-device# show ike policy group-ike-policy
mode main;
pre-shared-key ascii-text "$9$eC3MLNs2aikPdbkP5Q9CKM8"; ## SECRET-DATA
Step 2.1
Navigate to the [edit security group-vpn member ike] hierarchy and
create an IKE policy named policy-1. Configure the policy to use main mode to
use the predefined standard IKE proposal. Finally, specify the pre-shared-key
to authenticate with the key server. The key is defined as juniper.
[edit]
lab@srxA-1# edit security group-vpn member ike
[edit security group-vpn member ike]

lab@srxA-1# set policy policy-I mode main

lab@srxA-1# set policy policy-I proposal-set standard

lab@srxA-1# set policy policy-I pre-shared-key ascii-text juniper

lab@srxA-1#

Note
The following configuration snippet is one
of the key server's IKE gateway
configurations, which corresponds to your
next step.
This specific configuration snippet is only
for srxA-1. Each student device will have a
similar configuration on the key server.

instructor@vr-device# show ike gateway group-gate-srxA-1
ike-policy group-ike-policy;
address 192.168.11.1;
Step 2.2
Create a gateway named group-gateway. Apply the IKE policy that you created in
the previous step. Next, configure the remote gateway address as the key server IP
address specified in the lab diagram. Finally, specify your assigned device's loO.O
interface address as the local address that will be used to negotiate the 11-<E SA.
lab@srxA-1# set gateway group-gateway ike-policy policy-1

lab@srxA-1# set gateway group-gateway address Key-Server-Address

lab@srxA-1# set gateway group-gateway local-address local-loopback-address
Note
The following configuration represents the
key server's IPsec proposal that will be
used in the IPsec policy.
You will not locally define an IPsec proposal
or policy, because the key server is
responsible for pushing these parameters
to all group members.

instructor@vr-device# show ipsec
proposal group-proposal {
authentication-algorithm hmac-shal-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;

Note
The following configuration defines the
group properties, for the student devices in
Pod A, on the key server. Note that the
policies that define interesting traffic are
defined on the key server under the group
configuration. Please note that this
configuration is only for the devices
participating in group 1. For members of
another group, the server configuration is
very similar, but will contain the appropriate
group, server address, gateways, and policy
addresses. All other properties are
configured the same.

instructor@vr-device# show group group-1
group-id l;
ike-gateway group-gate-srxA-1;
ike-gateway group-gate-srxA-2;
anti-replay-time-window 100;
server-address 192.168.11.3;
server-member-communication {
communication-type unicast;
retransmission-period 30;
number-of-retransmission 3;
encryption-algorithm aes-256-cbc;
sig-hash-algorithm shal;
ipsec-sa group-1-sa {
proposal group-proposal;
match-policy dynamicl {
source 172.20.101.0/24;
destination 172.20.102.0/24;
source-port O;
destination-port O;
protocol O;
match-policy dynamic2
source 172.20.102.0/24;
destination 172.20.101.0/24;
source-port O;
destination-port O;
protocol O;

Question: According to the policies in the preceding
example, which traffic will be permitted to traverse
the IPsec VPN?
Answer: Any traffic from the 172.20.101.0/24

network being sent to the 172.20.102.0/24
network and vice versa will be permitted.
Question: What re-key method will be used based

on the server-member-communication
configuration?
Answer: The key server will be using the

unicast-push method to distribute the re-key
messages, because the communication-type
has been defined as unicast.
Step 2.3
Navigate to the [edit security group-vpn member ipsec] hierarchy and
create a VPN named vpn-group. Define your IKE gateway you created in the
previous step to be used for this VPN. Also define the external interface from which
to signal the IKE and IPsec SAs as your local loO.O interface. Finally, configure your
device to be a member of VPN group number according to the following table.
VPN Group Number

Assigned VPN Group
Device Number
srx.A-1 1
srx.A-1 1
srxB-1 2
srxB-1 2
srxC-1 3
srxC-1 3
srxD-1 4
srxD-2 4

lab@srxA-1# up

[edit security group-vpn member]
lab@srxA-1# edit ipsec
[edit security group-vpn member ipsec]

lab@srxA-1# set vpn vpn-group ike-gateway group-gateway

lab@srxA-1# set vpn vpn-group group-vpn-external-interface loO.O

lab@srxA-1# set vpn vpn-group group group-number

lab@srxA-1# show
vpn vpn-group {
ike-gateway group-gateway;
group-vpn-external-interface loO.O;
group l;
Step 2.4
Navigate to the top of the configuration hierarchy, and commit the configuration.
lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
so.
Part 3: Configuring the Security Policies to Use the IPsec VPN
In this lab part, you alter the current security policies to send the Juniper customer
traffic into the IPsec VPN that you have created.

Step 3.1
Navigate to the [edit security policies] hierarchy and create a security
policy named secure- traffic that allows traffic from the Juniper customer zone
to the untrust zone. Use the existing vrlOyaddress-book entry for your policy's
source-address match. The value of yis the remainder of the VLAN ID
associated with your local Juniper customer network. Configure the
destination-address to match the address-book entry vrlOlf, where the
value of lf is the remainder of the VLAN ID associated with your remote team
member's Juniper customer network. Indicate that matching traffic should be sent
to the IPsec VPN.
[edit]

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

lab@srxA-1# set policy secure-traffic match source-address vrlO.Y

lab@srxA-1# set policy secure-traffic match destination-address vrlOX

lab@srxA-1# set policy secure-traffic match application any

lab@srxA-1# set policy secure-traffic then permit tunnel ipsec-group-vpn
vpn-group

lab@srxA-1# show
policy internet-Juniper-SV {
match {
application junos-ping;
}
then {
permit;
policy secure-traffic {
match {
destination-address vrl02;
application any;
}
then {
permit
tunnel
ipsec-group-vpn vpn-group;


lab@srxA-1#
Question: Which policy in the policy chain will be

evaluated first?
Answer: The internet-Juniper-local policy

will be evaluated first in this policy chain.
Question: Will traffic ever be evaluated by the policy

you just created? If not, explain why.
Answer: No, the traffic will never be evaluated by

the second policy in the chain because the first
policy will permit this traffic to enter into the
untrust zone without putting the traffic into the
VPN.
Step 3.2
Re-order the policies under the [edit security policies from-zone
Juniper-local to-zone untrust] hierarchy level using the insert
command. When finished, navigate to the top of the configuration hierarchy, and
lab@srxA-1# insert policy secure-traffic before policy internet-Juniper-local

lab@srxA-1# show
policy secure-traffic {
match {
destination-address vrl02;
application any;
}
then {
permit
tunnel
ipsec-group-vpn vpn-group;
policy internet-Juniper-SV

match {
application junos-ping;
then {
permit;

lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Question: What will happen with traffic destined to

the remote Juniper site's addresses?
Answer: The traffic will be permitted by the first

policy and sent into the group VPN tunnel.
Question: What will happen with traffic from the

Juniper customer destined to any other network
address?
Answer: If the traffic is ping traffic it will be sent to

the untrust zone and out to its destination. If the
traffic is any other type, it will be denied by the
policy.
0 Before proceeding, ensure that the remote student team in your pod
finishes the previous steps.

Part 4: Verifying the Group IPsec VPN
In this lab part, you verify that both the IKE SA and IPsec SA have been negotiated.
You will also verify that you have an established key encryption key (KEK) SA for your
VPN. You will then review the policies that have been sent to your device from the
key server. Finally, you will verify that traffic from your local Juniper site will use the
IPsec VPN to reach the remote Juniper site using the ping utility.
Step4.1
Verify that the IKE SA has been correctly negotiated using the run show
security group-vpn member ike security-associations command.
[edit]
lab@srxA-1# run show security group-vpn member ike security-associations
1 UP Oe3d5fc9f338a9b7 bl5c33725729b52c Main 192.168.11.3
Question: Do you have an IKE SA?
Answer: Yes, at this point you should see an SA.
Question: What is the State of the SA?
Answer: The State should be UP.If the State is

IKE configuration and contact your instructor, if
needed.
Step4.2
Verify that you have a valid IPsec SA using the run show security group-vpn
member ipsec security-associations command.
[edit]
lab@srxA-1# run show security group-vpn member ipsec security-associations
ID Server Port Algorithm SPI Life:sec/kb Gid vsys
>133955586 192.168.11.3 848 ESP: 3des/shal 6669c709 1038/ unlim 1 root
<133955586 192.168.11.3 848 ESP: 3des/shal 6669c709 1038/ unlim 1 root

Question: Do you see IPsec SAs?
Answer: Yes, you should see 1 active tunnel. If you

do not see an SA, please review your IPsec
configuration and contact your instructor for
assistance, if needed.
Step4.3
Next, verify that you have a valid KEK SA using the run show security
group-vpn member kek security-associations command.
[edit]
lab@srxA-1# run show security group-vpn member kek security-associations
Index Remote Address State Initiator cookie Responder cookie Groupid
3 192.168.11.3 UP 047ee7f0deb048d5 1699fe96e61343b5 1
Question: Do you see a KEK SA?
Answer: Yes, you should see an established KEK. If

you do not see an SA, please review your
assistance, if needed.
Step4.4
Use the run show security dynamic-policies command to review the
policies being used on your local device that were sent down from the key server.
[edit]
lab@srxA-1# run show security dynamic-policies
From zone: Juniper-SV, To zone: untrust
Policy: secure-traffic-0001, State: enabled, Index: 1048582, Scope Policy: 6,
Sequence number: 1
Source addresses:
N/A: 172.20.101.0/24
Destination addresses:
N/A: 172.20.102.0/24
Applications: Unknown, Unknown( [0-0]->[0-0]/0)
Action: permit, tunnel
Step4.5
Issue the run clear security group-vpn member ipsec statistics
command to clear the group VPN statistics.
[edit]
lab@srxA-1# run clear security group-vpn member ipsec statistics

Note
the virtual router attached to your team's
device. The virtual routers are logical
devices created on a J Series Services
Router. Refer to the Management Network
Although you have two virtual routers
attached to your student device, you only
need to establish a single session.
Step4.6
Open a separate Telnet session to the virtual router attached to your device.

0 Open in a lab
11 Connect J I Cancel J

Step4.7

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttydO)
login: username
Password:
al@vr-device>
Step4.8
From the Telnet session established with the virtual router, verify that your local
Juniper customer device can ping the remote team's Juniper customer device. To
confirm reachability, ping the remote virtual routers attached to the remote peer
device. Source the ping from the virtual router's routing instance associated with
your local Juniper customer network. Refer to the lab network diagram if needed.
Ping this destination 5 times.
al@vr-device> ping remote-Juniper-vr-address routing-instance
vrlocal-Juniper-VLAN count 5
PING 172.20.102.10 (172.20.102.10): 56 data bytes
64 bytes from 172.20.102.10: icmp_seq=l ttl=62 time=3.950 ms
--- 172.20.102.10 ping statistics ---



time. If they do not, review your SAs and contact
your instructor as needed to assist with
troubleshooting.
Step4.9
Once you have verified that the pings complete, log out of the virtual router and
close out the session.
al@vr-device> exit
vr-device (ttydO)
login:
Step4.10
From your assigned SRX device, review the IPsec statistics to verify that the ping
packets you sent from the virtual router device used the IPsec VPN. This can be
accomplished using the run show security group-vpn member ipsec
statistics command.
[edit]
lab@srxA-1# run show security group-vpn member ipsec statistics
ESP Statistics:
AH Statistics:
Input bytes: O
Output bytes: O
Input packets: O
Output packets: O
Errors:

Question: Do you see encrypted and decrypted
packets?
Answer: Yes, you should see at least 5 encrypted

and s decrypted packets. Note that you might see
more than that depending on the number of pings
that were sent. You will also see additional statistics
if the remote team has finished their verification
also.
Step4.11
Exit configuration mode and log out of your assigned device using the exit
command.
[edit]
lab@srxA-1# exit
lab@srxA-1> exit
srxA-1 (ttyuO)
login:


ManagementAddressing
�-1 I srxD-1 I
xA-2 srxD-2 I
j srxB-1 I vr-device I
srxB-2 Server
srxC-1 Gateway
srxC-2 Term Server
Pod A Network Diagram: Configuring Group

VPNslab
Key Server
loO 192.168.11.3
-- lnterfacege-0/0/4 --
172.20.201.0/24 172.20.102.0/24
(� (�

Pod B Network Diagram: Configuring Group

VPNsLab
Key Server
loO: 192.168.21.3
172 20 203 0/24
(.10)
�1f)2013Jun10,erNeh!fQfi<j, lnC Affrl!ht� reserve4

""'"" �>-' ___,....,,.._ -- -- - -� - -- -
�-·
JUn1Per Worldwide Education Services www1un11ernet
Pod C Network Diagram: Configuring Group

VPNsLab
Key Server
loO: 192.168.31.3
vlan.105
172.20.205.Q/24
(.10)
Juniper-SY ACME-WF
t,::?OJ.JJ•Jn!11trNttwt\rk:, IntAllrl:;hh rtO:MJi

-- -
JUnJN Worldwide Education Services 0/WM 1un1 tr net

Pod D Network Diagram: Configuring Group

VPNsLab
(.l) v lan.20?
-- lnterfacege-0/0/4 ---
172 20 2070/24 172 20 108 0/24
(.� (.�
Juniper-SY ACME-SV --- Virtual Routers -- Juniper-WF ACME- WF


Lab
Implementing Advanced IPsec VPN Solutions (Detailed)
Overviiew
include interfaces, interfaces assigned to their zones, security policies to allow traffic
between zones, and a stateless firewall filter for selective packet-based services. You will
then configure your device to peer with the remote device in your pod through a route
based site-to-site IP Security (IPsec) VPN. You will use the external ge-0/0/3 interface as
your gateway. You will then configure a generic routing encapsulation (GRE) tunnel to
operate over the site-to-site IPsec VPN. After establishing GRE through the IPsec tunnel
you will configure your device to establish an OSPF adjacency with the remote peer over
this GRE tunnel as well as with the local Juniper customer site. Next, you will configure
static NAT to route traffic between the overlapping address space of your assigned
Local-VR device and the remote Local-VR device. After completing your configuration, you
will verify the functionality on your local device using show commands as well as using
the ping utility. For all IP addresses and network information please refer to the Lab 7
network diagram for your assigned pod.
Use the Junos command line interface (CU) to load the baseline configuration.
Use the Junos CU to configure the IPsec VPN parameters.
Use the Junos CU to configure the GRE tunnel.
Use the Junos CU to configure the OSPF protocol.
Verify that the expected traffic traverses the VPN using the OSPF route.
Use the Junos CU to configure static NAT.
Monitor the effects of the configuration from the local device.
www.juniper.net Implementing Advanced IPsec VPN Solutions (Detailed) • Lab 7-1

Part 1: Loading the Baseline Configuration.
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 7.
Next, you will examine the routing tables to determine the paths that traffic will use.
Step 1.1


user is assigned to the srxD-1 station, which uses
Step 1.2
your instructor. Refer to the Management Network Diagram for the IP adclress
O Show quick comeci on startup 0 Save session

� Open in a lab
� . Connect �
. '
I Cancel I
Step 1.3
Log in as user lab with the password labl23. Enter configuration mode and load
the lab7-start. configfrom the /var/home/lab/ aj sec/ directory.
Lab 7-2 • Implementing Advanced IPsec VPN Solutions (Detailed) www.juniper.net

srxA-1 (ttyuO)
login: Iab
Password:

lab@srxl,-1> configure
[edit]
lab@srxl,-1# load override ajsec/lab7-start.config
[edit]
lab@srxl,-1# commit
commit complete
[edit]
lab@srxl,-1#
Step 1.4
Review the routing tables and determine which routes are used to reach the remote
device networks.
lab@srxll-1# run show route

0.0.0.0/0 *[Static/SJ lwOd 19:16:15

> to 172.18.1.1 via ge-0/0/3.0
10.210.14.128/27 *[Direct/OJ lwOd 19:16:23
> via ge-0/0/0.0
10.210.14.137/32 *[Local/OJ lwOd 19:16:33
172.18.1. 0/30 *[Direct/OJ lwOd 19:16:16
> via ge-0/0/3.0
172.18.1.2/32 *[Local/OJ lwOd 19:16:32
172.20.100.0/24 *[Direct/OJ 22:01:25
> via ge-0/0/14.0
172.20.100.1/32 *[Local/OJ 22:01:25
172.20.107.0/24 *[Direct/OJ 23:49:19
> via vlan.107
172.20.107.1/32 *[Local/OJ 23:49:23
Local via vlan.107
172.20.2:07.0/24 *[Direct/OJ 23:49:19
> via vlan.207
172.20.207.1/32 *[Local/OJ 23:49:23
Local via vlan.207
192.168.1.1/32 *[Direct/OJ 23:49:23
> via loO.O
Local-VR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)


0.0.0.0/0 * [Static/SJ 22:01:25

> to 172.20.100.1 via ge-0/0/15.0
172.20.100.0/24 *[Direct/OJ 22:01:25
> via ge-0/0/15.0
172.20.100.10/32 *[Local/OJ 22:01:25

remote networks?
Answer: The default routes (0.0.0.0/0) in the

default routing instance and the Local-VR routing
instance, which is statically configured, are 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 VPI\J. You will
configure the Internet key exchange (IKE) and IPsec parameters to establish the
IPsec tunnel between the external ge-0/0/3 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 IP address and network that is defined in the
following table for your assigned device.
stO Address Per Device
Assigned stO Address

Device
srxA-1 10.10.10.1/24
srxA-2 10.10.10.2/24
srxB-1 10.10.20.1/24
srxB-2 10.10.20.2/24
srxC-1 10.10.30.1/24
srxC-2 10.10.30.2/24
srxD-1 10.10.40.1/24
srxD-2 10.10.40.2/24

Note
The network diagram also shows the
necessary stO address for your assigned
device.
[edit]
[edit interfaces]
lab@srxA-1# set stO unit O family inet address stO-address/24
[edit interfaces]
lab@srxl,-1#
Step 2.2
Navigate to the [edi t security ike] hierarchy and create a policy called
policy-1. Configure the IKE policy to use main mode and take advantage of the
pre-defined standard proposal-set. Configure your policy to use a
pre-shared-key, the key should be defined as juniper. Review the policy
before moving on.
[edit interfaces]
lab@srxl,-1# top edit security ike
[edit security ike]

lab@srxl,-1# set policy policy-1 mode main
[edit security ike]

lab@sr:iu,-1# set policy policy-1 proposal-set standard
[edit security ike]

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

lab@srxl,-1# show
policy policy-1 {
mode main;
pre··shared-key ascii-text "$9$LZS7dsaZjP5F245Fn/OOX7-"; ## SECRET-DATA
[edit security ike]

lab@srxl,-1#
Step 2.3
Configure the gateway properties that will be used to establish the IPsec VPN to the
remote site. You will define this gateway as gateway-1. As mentioned earlier, you
will be using your external ge-0/0/3 interface as the gateway interface to reach the
remote site. You will also need to specify the IP address of the remote device's
external ge-0/0/3 interface. This IP address is defined under the address key
word. Take a quick look at the gateway configuration before moving on.
www.juniper.net Implementing Advanced IPsec VPN Solutions (Detailed) • Lab 7 -5

Advanced JunosSecurity
[edit security ike]
lab@srxA-1# set gateway gateway-1 address remote-teams-ge-0/0/3-IP-address
[edit security ike]

lab@srxA-1# set gateway gateway-1 external-interface ge-0/0/3
[edit security ike]

lab@srxA-1# set gateway gateway-1 ike-policy policy-1
[edit security ike]

lab@srxA-1# show gateway gateway-1
address 172.18.2.2;
external-interface ge-0/0/3;
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.
[edit security ike]
lab@srxA-1# up 1 edit ipsec

lab@srxA-1# set policy policy-sec proposal-set standard

lab@srxA-1#
Step 2.5
Configure the VPN parameters.Navigate to the [edit securit y ipsec vpn
device-name-to-remote-device-name] hierarchy and bind the stO
interface and unit to your VPN.You will then define the parameters to use for the IKE
and IPsec security association (SA) negotiations. Begin by specifying the gateway
you need to use.You will use the gateway named gateway-1, which you defined
in Step 2.2. After specifying the gateway, indicate that this VPN will use the IPsec
policy named policy-sec, which was defined in Step 2.3.The last step for your
VPN is to configure the establish-tunnels immediately option. This option
will cause the device to signal the IPsec VPN after the configuration commits,
instead of waiting for interesting traffic to trigger the signaling of the VPN.
lab@srxA-1# edit vpn device-name-to-remote-device-name
[edit security ipsec vpn srxA-1-to-srxA-2]

lab@srxA-1# set bind-interface stO.O

lab@srxA-1# set ike gateway gateway-1

lab@srxA-1# set ike ipsec-policy policy-sec

lab@srxA-1# set establish-tunnels immediately
Lab 7-6 • ImplementingAdvanced IPsecVPN Solutions(Detailed) www.juniper.net

lab@srxA-1# show
ike {
gateway gateway-1;
establi:ah-tunnels immediately;

lab@srxA-1#
Step 2.6
Navigate to the [edit security zones] hierarchy and allow IKE as
host-inbound-traffic for the ge-0/0/3 interface within the untrust zone.
lab@srxA-1# top edit security zones

lab@srxi,-1# set security-zone untrust interfaces ge-0/0/3 host-inbound-traffic
systE!ln-services ike

lab@srxl,-1#
Question: Why do we want to allow IKE on this

interface?
Answer: In this lab, the ge-0/0/3 interface will be

the ingress and egress interface for our IPsec VPN.
Therefore, the source of local IKE negotiation
packets will come from this interface. This interface
will also be the destination of incoming IKE packets.
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 interface. Verify the recent changes to
both zones.
lab@srxA-1# set security-zone vpn interfaces stO.O

lab@srxA-1# show security-zone vpn
interfaces {
stO.O;
www.juniper.net Implementing Advanced IPsec VPN Solutions (Detailed) • Lab 7- 7

lab@srxA-1# show security-zone untrust
interfaces {
ge-0/0/3.0 {
system-services {
ike;
Step 2.8
Navigate to the [edit security policies] hierarchy and create two policies.
The first policy will allow traffic from the Juniper customer zone to enter tile vpn
zone and will be named juniper-to-vpn. The second policy will allow traffic to
enter the Juniper customer zone from the vpn zone and will be named
vpn-to-juniper. Once you have verified your configuration, commit these
changes and exit to operational mode.
lab@srxA-1# up 1 edit policies from-zone Juniper-local to-zone vpn
[edit security policies from-zone Juniper-SV to-zone vpn]

lab@srxA-1# set policy juniper-to-vpn match source-address any

lab@srxA-1# set policy juniper-to-vpn match destination-address any

lab@srxA-1# set policy juniper-to-vpn match application any

lab@srxA-1# set policy juniper-to-vpn then permit

lab@srxA-1# show
policy juniper-to-vpn {
match {
source-address any;
application any;
}
then {
permit;

lab@srxA-1# up 1 edit from-zone vpn to-zone Juniper-local
[edit security policies from-zone vpn to-zone Juniper-SV]

lab@srxA-1# set policy vpn-to-juniper match source-address any

lab@srxA-1# set policy vpn-to-juniper match destination-address any

lab@srxA-1# set policy vpn-to-juniper match application any

lab@srxA-1# set policy vpn-to-juniper then permit

lab@srxA-1# show
policy vpn-to-juniper {
match {
source-address any;
application any;
}
then {
permit;

lab@srxl,-1# commit and-quit
commit complete
lab@srxl,-1>
Note

allow all traffic, from the local Juniper
customer network to the remote Juniper
customer 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.
Before proceeding, ensure that the remote student team in your pod
Step 2.9
Verify that the IKE SA has been correctly negotiated using the show security
ike security-associations command.

lab@srxA-1> show security ike security-associations
2742735 UP 5d6e9e5ffdcl2d0c 9d8066e7ea59307b Main 172.1!3.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

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
lab@srxA-1> show security ipsec security-associations
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<131073 ESP:3des/shal e9829557 3506/ unlim root 500 172.18.2.2
>131073 ESP:3des/shal ec47b6d2 3506/ unlim root 500 172.18.2.2
Question: Do you see IPsec SAs?
Answer: Yes, you should see 1 active tunnel. If you

do not see an SA, please review your IPsec
assistance if needed.
Do not proceed to the next lab part until directed by the instruc:tor to do
so.

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's gateway device. This tunnel will be sourced
from the sto interface and will terminate on the remote team's stO interface. You
will add the GRE interface to your Juniper customer zone. You will then configure the
vpn zone to recognize and allow the GRE traffic coming in from the IPsec VPN.
Step 3.1
Enter configuration mode and navigate to the [edit interfaces gr-0/0/0
unit o] 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
your local stO interface address, and the destination address should be configured
as the remote team's stO interface address. After defining the source and
destination of the tunnel, you need to specify the IP address for the GRE interface,
which is defined on the network diagram for your assigned pod.
lab@srxi\-1> configure
[edit]
lab@srxl\-1# edit interfaces gr-0/0/0.0
[edit interfaces gr-0/0/0 unit OJ

lab@srxl\-1# set tunnel source local-stO-IP-address
[edit interfaces gr-0/0/0 unit O]

lab@srxl,-1# set tunnel destination remote-stO-IP-address

lab@srxl\-1# set family inet address local-GRE-IP-address/30
[edit interfaces gr-0/0/0 unit O]

lab@srxl\-1#
Step 3.2
Navigate to the [edit security zone] hierarchy level, add the GRE interface
to the Juniper customer zone, and allow ping on all interfaces in this zone. You will
need to remove the host-inbound-traffic statement that is currently
configured under the Juniper customer facing interface. Review the configuration
before moving on.

lab@srxA-1# set interfaces gr-0/0/0.0

lab@srxA-1# delete interfaces vlan.local-juniper-vlan host-inbound-traffic

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

lab@srxA-1# up

lab@srxA-1# show security-zone Juniper-local
system-services {
ping;
interfaces
vlan.101;
gr-0/0/0.0;

lab@srxA-1#
Step3.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@srxA-1# set security-zone vpn host-inbound-traffic system-services
any-service

lab@srxA-1# coI11I11it and-quit
commit complete
lab@srxA-1>
Step3.4
Clear the statistics for the IPsec VPN by issuing the clear s ecurity 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 remote GRE interface address 5 times.This task can be
accomplished using the ping remote-GRE-IP-address rapid command.
After pinging the remote GRE interface, review the IPsec statistics to verify the traffic
is traversing the tunnel.
lab@srxA-1> ping remote-GRE-IP-address rapid

PING 11.11.11.2 (11.11.11.2): 56 data bytes
! ! ! ! !


ESP Statistics:
AH Statistics:
Input bytes: O
Output bytes: 0
Input packets: O
Output packets: O
Errors:
ESP authentication failures: 0, ESP decryption failures: O
Question: Did your pings succeed?

time.
Question: Do you see encrypted and decrypted

packets in the IPsec statistics?
Answer: Yes, you should see encrypted and

decrypted packets. The total number will depend on
whether or not the remote team has completed this
step.
so.
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 customer facing interface to you OSPF area. The
Juniper customer 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. You will finally verify that you are able to reach the remote
Juniper customer site using the ping utility.

Step4.1
Enter configuration mode and navigate to the [edit protocols ospf area
o.o.o.o] hierarchy. Add the GRE interface as well as the Juniper customer-facing
VLAN interface. Review your configuration changes before moving on to the next
step.
[edit]
lab@srxA-1# edit protocols ospf area O
[edit protocols ospf area 0.0.0.0]

lab@srxA-1# set interface gr-0/0/0.0

lab@srxA-1# set interface vlan.local-juniper-vlan

lab@srxA-1# show
interface gr-0/0/0.0;
interface vlan.101;

lab@srxA-1#
Step4.2
Navigate to the [edit security zones security-zone
Juniper-local] hierarchy level and configure the Juniper zone to allow OSPF
protocolon all interfaces in the zone.After making the appropriate changes, commit
and exit to operational mode.

lab@srxA-1# set host-inbound-traffic protocols ospf

commit complete
lab@srxA-1>
Before proceeding, ensure that the remote student team in your pod
Step4.3
Begin verifying your configuration by looking at the OSPF neighborships.

lab@srxA-1> show ospf neighbor
11.11.11.2 gr-0/0/0.0 Full 192.168.2.1 128 36
172.20.101.10 vlan.101 Full 192.168.l.2 128 36
Question: How many neighborships do you see?
Answer: You should see two neighbors. You see one

neighborship with the Juniper customer site and
one with the remote site's GRE interface. If you do
not see both neighbors, ensure the remote team
has completed the previous steps. If you are still
having issues, contact your instructor for
assistance.
Step4.4
Review the OSPF routes installed in your routing table.
lab@srxA-1> show route protocol ospf
inet.O: 20 destinations, 21 routes (18 active, O holddown, 2 hidden)

11.11.11.0/30 [OSPF/10] 00:12:44, metric l

> via gr-0/0/0.0
172.20.102.0/24 *[OSPF/10] 00:11:23, metric 2
> via gr-0/0/0.0
192.168.1.2/32 *[OSPF/10] 00:12:44, metric l
> to 172.20.107.10 via vlan.101
192.168.2.2/32 *[OSPF/10] 00:11:23, metric 2
> via gr-0/0/0.0
224.0.0.5/32 *[OSPF/10] 00:12:54, metric l
MultiRecv
Local-VR.inet.O: 3 destinations, 3 routes (3 active, O holddown, O hidden)
Question: Do you see the routes for the remote

networks?
Answer: Yes, you should see the OSPF routes for the
route for the remote team's Juniper customer
network and well as the remote Juniper customer
site's loopback address.

Step 4.5
Verify reachability to the remote Juniper customer's site.You will use the ping utility
to send 5 ICMP requests to the Juniper customer device's IP address. Your local
device will use the route learned through OSPF, which is established over the GRE
tunnel which is signalled over your IPsec VPN.You can accomplish this task by
issuing the ping remote-juniper-IP-address rapid command.
lab@srxA-1> ping remote-juniper-vr-address rapid
PING 172.20.102.10 (172.20.102.10): 56 data bytes
! ! ! ! !
--- 172.20.102.10 ping statistics ---
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.
Note
Please note that you do not need to

configure a GRE tunnel to establish OSPF
over IPsec when both devices are SRX
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.
so.
Part 5: Working with Overlapping Address Space
In this lab part, you configure static NAT on your SRX device to facilitate
communication between your Local-VR device and the remote team's Local-VR
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.

Step 5.1
Enter configuration mode and navigate to the [edit security policies]
hierarchy level and configure your SRX device to allow all communication between
the acquired zone and the vpn zone.
[edit]
lab@srxA-1# edit security policies from-zone acquired to-zone vpn
[edit security policies from-zone acquired to-zone vpn]

[email protected]# set policy allow-traffic match source-address any

[email protected]# set policy allow-traffic match destination-address any

[email protected]# set policy allow-traffic match application any

[email protected]# set policy allow-traffic then permit

lab@srxl\_-1# up 1 edit from-zone vpn to-zone acquired
[edit security policies from-zone vpn to-zone acquired]

lab@srxA-1# set policy allow-traffic match source-address any

[email protected]# set policy allow-traffic match destination-address any

lab@srxA-1# set policy allow-traffic match application any

lab@srxA-1# set policy allow-traffic then permit

lab@srxA-1#
Note

allow all traffic, from the Local-VR device
network to the remote Local-VR device
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 that is
destined for the remote team's external NAT address space. The external NAT
address space can be found on the network diagram.
lab@srxA-1# run show route table inet.0

0.0.0.0/0 * [Static/SJ 11:03:10

> to 172.18.1.1 via ge-0/0/3.0
10.10.10.0/24 *[Direct/OJ oo:30:36
> via stO.O
10.10.10.1/32 *[Local/OJ 00:32:04
Local via stO.O
10.210.35.128/26 *[Direct/OJ 11:03:16
> via ge-0/0/0.0
10.210.35.131/32 * [Local/OJ 11:03:25
11.11.11.0/30 *[Direct/OJ 00:17:49
> via gr-0/0/0.0
[OSPF/10] 00:12:32, metric 1
> via gr-0/0/0.0
11.11.11.1/32 *[Local/OJ 00:17:49
Local via gr-0/0/0.0
172.18.1.0/30 *[Direct/OJ 11:03:10
> via ge-0/0/3.0
172.18.1.2/32 *[Local/OJ 11:03:25
172.20.100.0/24 *[Direct/OJ 00: 56:31
> via ge-0/0/14.0
172.20.100.1/32 *[Local/OJ 00:56:31
172.20.101.0/24 *[Direct/OJ 10:01:10
> via vlan.101
172.20.101.1/32 *[Local/OJ 10:01:12
Local via vlan.101
172.20.102.0/24 *[OSPF/10] 00:12:17, metric 2
> via gr-0/0/0.0
172.20.201.0/24 *[Direct/OJ 10:01:10
> via vlan.201
172.20.201.1/32 *[Local/OJ 10:01:12
Local via vlan.201
192.168.1.1/32 *[Direct/OJ 00:56:31
> via loo.a
192.168.1.2/32 *[OSPF/10] 00:12:22, metric 1
> to 172.20.101.10 via vlan.101
192.168.2.2/32 *[OSPF/10] 00:12:17, metric 2
> via gr-0/0/0.0
224.0.0.5/32 *[OSPF/10] 00:12:37, metric 1
MultiRecv

Question: Which interface will be used for traffic
destined to the remote team's external NAT address
space?
Answer: The route table shows that the traffic

destined to the remote team's external NAT address
space will use the default route (0.0.0.0/0), which
points through the ge-0/0/3 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/3 interface.
lab@srxA-1# top edit security nat static rule-set static-nat
[edit security nat static rule-set static-natl

lab@srxA-1# set from interface ge-0/0/3

lab@srxJ,-1#
Step 5.4
Configure a static NAT rule called overlapping-address that translates traffic
that is destined to your assigned external NAT address space into the
172.20.100.0/24 address space. The external NAT address space that is assigned
to your local device can be found on your Lab 7 network diagram. When you are
finished, commit the configuration.
lab@srxl,-1# edit rule overlapping-address
[edit security nat static rule-set static-nat rule overlapping-address]

lab@srxl<-1# set match destination-address local-external-nat-address-space/24

lab@srxl<-1# set then static-nat prefix 172.20.100/24

lab@srxl<-1# up 2
[edit security nat static]

lab@srxl<-1# show
rule-set static-nat {
from interface ge-0/0/3;
rule overlapping-address
match {
}
then {
static-nat prefix 172.20.100.0/24;

Advanced JunosSecur ity

lab@srxA-1# commit
commit complete

lab@srxA-1#
Step 5.5
Test connectivity by pinging the remote team's Local-VR 5 times by issuing the run
ping 10. 211._K.10 routing-instance Local-VR rapid command,
where Xis 2 if your assigned device is SRX1 and Xis 1 if your assigned device is
SRX2.
lab@srxA-1# run ping 10.211._K.10 routing-instance Local-VR rapid
PING 10.211.2.10 (10.211.2.10): 56 data bytes

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@srxA-1# run show security nat static rule all
Total static-nat rules: 1
Static NAT rule: overlapping-address Rule-set: static-nat

Rule-Id 1
Rule position 1
From interface ge-0/0/3.0
Destination addresses 10.211.1.0
Host addresses 172.20.100.0
Netmask 24
Host routing-instance N/A
Translation hits 5
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.
Lab 7-20 • Implementing Advanced IPsecVPN Solutions(Detailed) www.juniper.net

Question: Is the destination address of the ping
packets being translated?
Answer: As the ping packets traverse the static NAT

rule the destination address is not being changed
on your assigned SRX device.
Step 5.7
To further diagnose the problem, issue the run traceroute 10. 211._¥.10
routing-instance Local-VR command. Where _ris 2 if your assigned device
is SRX1 and Xis 1 if your assigned device is SRX 2.
lab@srxA-1# run traceroute 10.211._¥.10 routing-instance Local-VR
traceroute to 10.211.2.10 (10.211.2.10), 30 hops max, 40 byte packets
1 172.20.100.1 (172.20.100,1) 1.950 ms 2.386 ms 1.654 ms
2 * * *
29 * * *
30 * * *
Question: What does the traceroute reveal?
Answer: The traceroute shows that the first hop,

which is your assigned SRX device, is responding to
the traceroute, 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.2 1 1.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's
device and also adds encryption for the traffic.
However, the encryption is necessary in our current
scenario, and thus a GRE tunnel could be used
instead.
Step 5.8
Configure a static route for the remote team's external NAT address space and use
the stO interface as the next hop for the route. Remember that you can view the
remote team's external NAT address space by examining your Lab 7 network
diagram. When you are finished, commit the configuration.
lab@srxA-1# set static route remote-teams-external-nat-address/24. next-hop stO
lab@srxA-1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 10.211.2.0/24 next-hop stO.O;
lab@srxA-1# commit
commit complete
lab@srxA-1#
Step 5.9
Clear the static NAT statistics by issuing the run clear security nat
statistics static rule all command. Then, test connectivity by pinging
the remote team's Local-VR device 5 times by issuing the run ping
10.211._r.10 routing-instance Local-VR rapid command. Where_ris
.r
2 if your assigned device is SRX1 and is 1 if your assigned device is SRX2.
lab@srxA-1# run clear security nat statistics static rule all
lab@srxA-1# run ping 10.211._!'.10 routing-instance Local-VR rapid

PING 10.211.2.10 (10.211.2.10): 56 data bytes
--- 10.211.2 ping statistics ---

5 packe1:s transmitted, 0 packets received, 100% packet loss
Step 5.10
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@srxA-1# run show security nat static rule all
Total static-nat rules: 1

Rule-Id 1
Rule position 1
From interface ge-0/0/3.0
Netmask 24
Transj_ation hits 0
Question: What is preventing the translation hits

from occurring?
Answer: Recall that in a previous step, you set the

ge-0/0/3 interface as the from criteria. This action
made sense in the previous step because the traffic
was using the default route that uses the ge-0/0/3
interface. However, you added the static route that
uses the stO 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 stO interface in the
static NAT rule set.

Step 5.11
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 IPsec statistics in the following steps.
lab@srxA-1# top deactivate protocols ospf
lab@srxA-1# top edit security nat static

lab@srxA-1# set rule-set static-nat from interface stO

commit complete
lab@srxA-1>
Step 5.12
Clear the current IPsec statistics by issuing the clear security ipsec
statistics command. Then, test connectivity by pinging the remote team's
Local-VR device 5 times by issuing the ping 10. 211._r. 10
routing-instance Local-VR rapid command, where_ris 2 if your
assigned device is SRX1 and Xis 1if your assigned device is SRX2.
lab@srxA-1> ping 10.211._r.10 routing-instance Local-VR rapid

PING 10.211.2.10 (10.211.2.10): 56 data bytes
! ! ! ! !
Step 5.13
Examine the static NAT and IPsec statistics by issuing the show security nat
static rule alland the show security ipsec statistics
commands.

lab@srxA-1> show security nat static rule all
Total static-nat rules: l

Rule-Id 1
Rule position l
From interface stO.O
Netmask 24
Translation hits 10

ESP Statistics:
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
Bad headers: 0, Bad trailers: 0
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. Your output might be different than the
previous output if the remote team has not yet
performed their ping tests.
Step 5.14
Log out of your assigned SRX device to return it to the login prompt.
lab@srxA-1> exit
srxA-1 (ttyuO)
login:

., .,
ge-0/0/0(on allstudentdevices)
--·@/ srxA-1
----�
_......--
R ··· ·········· ·• Serial Console�
sea.�
,
Terminal\�'- Connections srxA-2
Server \ '- Workstations
'\
, '-,
\' .......
\' .......�
\e
\' srxD-2 �
srx A -1 I srxD-1
\ '\
11
srxA-2 I srxD-2
srxB-1 I vr-device
\ vr-device srxB-2 I Server
srxC-1 I Gateway
srxC-2 I Term Server
Server Note: Your instructor will provide address and access informabon.


Advanced IPsec VPN Solutions Lab
..._____ lnterfacege-0/0/4 -·�--

172.20.201.0/24 172 20 202 0/24
(.10) (.10)
vr202
ACME-WF
�J:n1p:r Networit,:, ! n �>JI

- nghts re:seNed JUnlPer
-
Worldwide Education Services Wl'IIW Juniper n el
�==-" ----� _......._�---� -� -

Ecal-VR I
(.10)\
..._____ lnterfacege-0/0/4 ---

172.20.203.Q/24 172.20.104.0/24
(.� (.�
Juniper-SY ACME-WF
...
�::i:t� t:;.o,;;�;��llig?it;�tstlWQ JUnJPff Worldwide Education Services jUn1p�r t �,
�-- � ---� -- -
\'mll."1
'

Pod C Network Diagram: lmple1111enting

Advanced IPsec VPN Solutions lab
172.20 2050/24 172.20106.0/24
(� (�
Juniper-SV ACME-SV -- Virtual Routers --
©:?013 Jt1nlper Network,, �,nc All 111',ht� re�er.ted

-L--..... �------ ��
JUnff?�f Worldwide Education Service
Pod D Network Diagram: lmple1nenting

vr108
....,.,,......,,..,,..- -- Virtual Routers --
Juniper-WF ACME-WF
©'.?o:JJ11:l{l�tNttwor�, lne .�n;tt,1s�•'lrwtJ

---�--�-
JUnlE:5:J Worldwide Education Services 'l'IWi'I JUhl

Lab
Peirforming Security Troubleshooting Techniques (Detailed)
Overvi,ew
In this lab, you will examine log outputs to determine useful troubleshooting information.
You will then configure security flow traceoptions to troubleshoot a failing Telnet session.
When you discover the reason behind the Telnet session failure you will fix the problem.
You will then work as a team to troubleshoot a down IP Security (IPsec) tunnel. Once the
problem with the IPsec tunnel has been discovered, you will fix it and bring the tunnel
back to its operational state.
By completing this lab you will perform the following tasks:
View and examine logs.
Configure security traceoptions.
Troubleshoot a failing Telnet session.
Troubleshoot an IPsec tunnel that is down.
www.juniper.net Performing Security Troubleshooting Techniques (Detailed) • Lab 8-1

Part 1: Examining Log Messages
In this lab part, you examine various logs that will aid in the troubleshooting process.
You will also configure and examine security flow traceoptions to troubleshoot a
failing Telnet session.
Step 1.1


Step 1.2

� Open in a tab
Connect J J Cancel I
Step 1.3
the 1 abB -start . config from the /var/home/lab/ajsec/ directory. Commit the
srxA-1 (ttyuO)
login: lab
Password:
Lab 8-2 • Performing Security Troubleshooting Techniques (Detailed) www.juniper.net

lab@srxl-\.-1> configure
[edit]
lab@srxA-1# load override ajsec/labB-start.config
load complete
[edit]
commit complete
lab@srxi\-1>
Step 1.4
The following output was obtained from a previous IPsec lab. Examine this output
and answer the following question.
lab@srxi\-1> show log kmd I match ike I last 500
May 17 01:27:13 ike_encode_packet: Start, SA= { Oxa6aa156a 570e2c7a - b4beflbl
9735b07c } I 00000000, nego = -1
May 17 01:27:13 ike_send_packet: Start, send SA= { a6aa156a 570e2c7a - b4beflbl
9735b07c}, nego= -1, src= 172.18.1.2:500, dst= 172.18.2.2:500, routing
table id= O
May 17 01:27:13 ike_get_sa: Start, SA= { a6aa156a 570e2c7a - b4beflbl 9735b07c
} I 00000000, remote= 172.18.2.2:500
May 17 01:27:13 ike sa find: Found SA= { a6aa156a 570e2c7a - b4beflbl 9735b07c
}
May 17 01:27:13 ike_decode_packet: Start
May 17 01:27:13 ike_decode_packet: Start, SA= { a6aa156a 570e2c7a - b4beflbl
9735b07c} I 00000000, nego= -1
May 17 01:27:13 ike_st_i_nonce: Start, nonce[O..64] = 5ad36bfc 546ea59b
May 17 01:27:13 ike_st_i_ke: Ke[O..128] = Ola07b91 cad30148 ...
May 17 01:27:13 ike-st-i-er: Start
May 17 01:27:13 ike st i cert: Start
May 17 01:27:13 ike-st_i_private: Start
May 17 01:27:13 ike st 0 id: Start
May 17 01:27:13 ike_st_o_hash: Start
May 17 01:27:13 ike_find_pre_shared_key: Find pre shared key key for
172.1.8.1.2:500, id= ipv4(udp:500, [0..3]=172.18.1.2) -> 172.18.2.2:500, id
No Id
May 17 01:27:13 ike_policy_reply_find_pre_shared_key: Start
May 17 01:27:13 ike_calc_mac: Start, initiator= true, local true
May 17 01:27:13 ike_st_o_status_n: Start
May 17 01:27:13 ike_st_o_private: Start
May 17 01:27:13 ike_policy_reply_private_payload_out: Start
May 17 01:27:13 ike st o encrypt: Marking encryption for packet
May 17 01:27:13 ike_=-en�ode_packet: Start, SA= { Oxa6aa156a 570e2c7a - b4beflbl
9735b07c } I 00000000, nego= -1
May 17 01:27:13 ike_send_packet: Start, send SA= { a6aa156a 570e2c7a - b4beflbl
9735b07c}, nego = -1, src= 172.18.1.2:500, dst= 172.18.2.2:500, routing
table id= O
May 17 01:27:13 ike_get_sa: Start, SA= { a6aa156a 570e2c7a - b4beflbl 9735b07c
} I d9fa307f, remote= 172.18.2.2:500

May 17 01:27:13 ike_sa_find: Found SA = { a6aal56a 570e2c7a - b4beflbl 9735b07c
May 17 01:27:13 ike alloc_negotiation: Start, SA = { a6aal56a 570e2c7a -

b4beflbl 9735b07c}
May 17 01:27:13 ike_decode_packet: Start, SA = { a6aal56a 570e2c7a - b4beflbl
9735b07c} I d9fa307f, nego = O
May 17 01:27:13 ike_st_i_n: Start, doi = 1, protocol = 1, code = Invalid payload
type (1), spi [O..16J = a6aal56a 570e2c7a ..., data [O..125J = 800c0001
800300e8 ...
May 17 01:27:13 ike_st_i_private: Start
May 17 01:27:13 ike_send_notify: Connected, SA = { a6aal56a 570e2c7a - b4beflbl
9735b07c}, nego = O
May 17 01:27:13 ike_delete_negotiation: Start, SA = { a6aal56a 570e2c7a -
b4beflbl 9735b07c}, nego = O
Question: What IPsec troubleshooting information

does the output contain?
Answer: The output displays troubleshooting

information on the status of Internet Key Exchange
(IKE). You might see items such as security
association (SA) negotiation or tunnel endpoint
information.
Step 1.5
Examine the following output and answer the question.
lab@srxA-1> show log kmd I match "initiator/responder" I last 500
May 17 01:23:03 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { 8e0364fc
54639b87 - 53869911 bd032772 [-lJ / OxOOOOOOOO } IP; Reserved 1 not O
May 17 01:23:03 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { 8e0364fc
54639b87 - 53869911 bd032772 [-lJ / OxOOOOOOOO } IP; Error = Payload
malformed (16)
May 17 01:23:13 ike_init_isakmp_sa: Start, remote = 172.18.2.2:500, initiator
1
May 17 01:23:13 ike calc mac: Start, initiator = true, local = true
May 17 01:23:13 172�18.1�2:500 (Responder) <-> 172.18.2.2:500 { 8be54c6d
6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Notification data has
attribute list
May 17 01:23:13 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { 8be54c6d
6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Notify message version
= 1
6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Offending payload type
= 156

6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Offending payload data
offset = O
6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Offending message id
OxOOOOOOOO
6eb863f3 - f05b6749 Obb9795b [OJ I Ox2f8a2la3 } Info; Received notify err
Invalid payload type (1) to isakmp sa, delete it
May 17 01:23:13 172.18.1.2:500 (Initiator) <-> 172.18.2.2:500 { 8be54c6d
6eb863f3 - f05b6749 Obb9795b [-lJ I OxOOOOOOOO } IP; Connection got error
l, calling callback
0
May 17 01:24:02 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { e3d5elaa
00703825 - d798bbda 07alff53 [-lJ / OxOOOOOOOO } IP; Reserved 1 not O
May 17 01:24:02 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { e3d5elaa
00703825 - d798bbda 07alff53 [-lJ / OxOOOOOOOO } IP; Error = Payload
malformed (16)
1
May 17 01:24:13 ike_calc_mac: Start, initiator = true, local = true
May 17 01:24:13 172.18.1.2:500 (Responder) <-> 172.18.2.2:500 { f34lfdef
cf3c6315 - f613dc7f 9e8ad548 [OJ I Ox950e96b0 } Info; Notification data has
attribute list
cf3c6315 - f613dc7f 9e8ad548 [OJ I Ox950e96b0} Info; Notify message version
= 1
cf3c6315 - f613dc7f 9e8ad548 [OJ I Ox950e96b0} Info; Offending payload type
= 116
cf3c6315 - f613dc7f 9e8ad548 [OJ I Ox950e96b0} Info; Offending payload data
offset = 1
cf3c6315 - f613dc7f 9e8ad548 [OJ I Ox950e96b0} Info; Offending message id
OxOOOOOOOO
Question: What IPsec troubleshooting information

does the output contain?
Answer: The output displays troubleshooting

information on the communication between the
tunnel endpoints. You might see items such as
malformed payload notifications or other SA error
information.

Step i6
Enter configuration mode and navigate to the [edit security nat
destination] hierarchy level.
[edit]

lab@srxA-1#
Step i7
Configure the NAT pool dst-nat-pool to contain the address associated with
your local Juniper customer vr-device. Please refer to network diagram for the
correct VLAN ID value.
lab@srxA-1# set pool dst-nat-pool address local-juniper-vr-address

lab@srxA-1# show
pool dst-nat-pool {
address 172.20.101.10/32;
Step i8
Navigate to the [edit security nat destination rule-set
dst-nat-untrust] hierarchy level. Configure the rule set to accept connections
from the untrust zone, and then configure a rule named dst-telnet to match
Telnet traffic on the destination address of the ge-0/0/3 interface address. Next,
configure the rule dst-telnet to use the NAT pool dst-nat-pool fo1·
connections that match this rule's criteria.
lab@srxA-1# edit rule-set dst-nat-untrust
[edit security nat destination rule-set dst-nat-untrust]

lab@srxA-1# set from zone untrust

lab@srxA-1# set rule dst-telnet match destination-address local-ge-0/0/
3-address

lab@srxA-1# set rule dst-telnet match destination-port 23

lab@srxA-1# set rule dst-telnet then destination-nat pool dst-nat-pool

lab@srxA-1# top show security nat
destination {
pool dst-nat-pool {
address 172.20.101.10/32;
rule-set dst-nat-untrust
from zone untrust;
rule dst-telnet {
match {
}
then {
destination-nat pool dst-nat-pool;
Step 1.9
Navigate to the [edit security flow traceoptions] hierarchy level.Store
the traceoptions in the file named dst-nat-telnet. log, and configure the
flag all option.Once you are finished, commit the configuration.
lab@srxA-1# up 3
[edit security]
lab@srxA-1# edit flow traceoptions
[edit security flow traceoptions]

lab@srxA-1# set flag all

lab@srxA-1# set file dst-nat-telnet.log

lab@srxA-1# commit
commit complete

lab@srxl'.-1#
Note

the Internet service provider (ISP) virtual
router (VR) attached to your team's device.

Step 1.10
Open a separate Telnet session to the ISP VR attached to your team's device.
Consult the lab diagram if necessary for the ISP's IP address on the untrust zone
subnet.

0 Open in a tab
j Connect l j Cancel l
1
Step 1.11
Log in to the VR using the login information shown in the following table:

srxA-1 al labl23
srxA-2 a2 labl23
srxB-1 bl labl23
srxB-2 b2 labl23
srxC-1 cl labl23
srxC-2 c2 labl23
srxD-1 dl labl23
srxD-2 d2 labl23
vr-device (ttypO)
login: username
Password:

al@vr-device>
Step 1.1.2
From the Telnet session established with the virtual router, initiate a Telnet
connection to your assigned SRX device's ge-0/0/3 interface address. Source the
telnet connection from the virtual router's ISP routing instance
internet-instance, where instance is the letter of your assigned pod. Refer
to the following table.
Student Device Instance

srxA-1 a
srxA-2 a
srxB-1 b
srxB-2 b
srxC-1 c
srxC-2 c
srxD-1 d
srxD-2 d
al@vr-device> telnet local-ge-0/0/3-address routing-instance internet-instance

Trying 172.18.1.2...

should not be successful.
Step 1.13
Return to the session of your assigned SRX device.
From your assigned SRX device, troubleshoot the issue by examining the recently
configured traceoptions using therun show log dst-nat-telnet.log
command.
lab@srxA-1# run show log dst-nat-telnet.log
May 17 00:48:47 00:48:46.1274154:CID-0:RT: refreshing session
May 17 00:48:47 00:48:46.1274154:CID-O:RT: vector bits OxO vector Ox48965ae8
May 17 00:48:47 00:48:46.1274154:CID-0:RT:mbuf Ox42ld5080, exit nh Oxlef22

May 17 00:48:47 00:48:46.1274154:CID-0:RT: ----- flow_process_pkt re OxO (fp re
0)
May 17 00:48:48 00:48:47.1275461:CID-0:RT:<172.18.l.l/59940->172.18.l.2/179;6>
May 17 00:48:48 00:48:47.1275461:CID-O:RT:packet [48] ipid = 12465, @42lf589c
May 17 00:48:48 00:48:47.1275461:CID-0:RT:--- - flow_process_pkt: (thd 2):

flow_ctxt type 13, common flag OxO, mbuf Ox42lf5700, rtbl idx = O
May 17 00:48:48 00:48:47.1275461:CID-0:RT: flow process pak fast ifl 73 in_ifp

ge-0/0/3.0
May 17 00:48:48 00:48:47.1275461:CID-0:RT: ge-0/0/3.0:172.18.1.1/

59940->172.18.1.2/179, tcp, flag 2 syn
May 17 00:48:48 00:48:47.1275461:CID-0:RT: find flow: table Ox5lab5dl0, hash

2910l(Oxffff), sa 172.18.1.1, da 172.18.1.2, sp 59940, dp 179, proto 6, tok 8
May 17 00:48:48 00:48:47.1275461:CID-0:RT: no session found, start first path.

in_tunnel - 0, from_cp_flag - 0
May 17 00:48:48 00:48:47.1275461:CID-O:RT:self ip check: ip=ac120102,

laddr=acl20102
May 17 00:48:48 00:48:47.1275461:CID-O:RT:check self-traffic on ge-0/0/3.0, i

...TRIMMED...
Question: After viewing the log, are you able to

determine the issue?
Answer: Although the answer is buried in the log file

somewhere, the large amount of information
collected makes it difficult to find. We can make the
issue easier to find by modifying the log.
Step 1.14
Configure the packet filter telnet-sessions in the security flow traceoptions
that will only allow the log file to collect information from sessions using the
destination port number 23. Commit the configuration when you are finished.
lab@srxA-1# set packet-filter telnet-sessions destination-port telnet

lab@srxA-1# commit
commit complete

Step 1.15
Clear the log file by issuing therun clear log dst-nat-telnet.log
command.
lab@srxA-1# run clear loq- dst-nat-telnet.log
Step 1.16i
session again to the ge-0/0/3 interface address.
Trying 172.18.1.2...
Step 1.17
From your assigned SRX device, issue therun show log
dst-nat-telnet.log / last lOOcommand.
lab@srxA-1# run show log dst-nat-telnet.log / last 100
May 17 22:09:47 22:09:47 .

. 408115:CID-0:RT:flow rt lkup: Found route entry
Ox0x573fe330,nh id Ox229, out if Ox46
May 17 22:09:47 22:09:47.408115:CID-0:RT:flow_rt_lkup: nh word Oxl40010
May 17 22:09:47 22:09:47.408115:CID-O:RT:flow_ipv4_rt_lkup success
172.20.101.10, iifl Ox4a, oifl Ox46
May 17 22:09:47 22:09:47.408115:CID-0:RT: routed (x_dst ip 172.20.101.10) from
untrust (ge-0/0/3.0 in 0) to vlan.101, Next-hop: 172.20.101.10
May 17 22:09:47 22:09:47.408115:CID-0:RT: policy search from zone untrust->
zone Juniper-SV (Oxll0,0xd8bd0017,0xl7)
May 17 22:09:47 22:09:47.408115:CID-0:RT: app 10, timeout 1800s, curr ageout
20s
May 17 22:09:47 22:09:47.408115:CID-0:RT: packet dropped, denied by policy
May 17 22:09:47 22:09:47.408115:CID-0:RT:Denied by policy 2, dropping pkt
May 17 22:09:47 22:09:47.408115:CID-0:RT: packet dropped, policy deny.
May 17 22:09:47 22:09:47.408115:CID-0:RT:set_nat invalid: natp:id 37721, flag
55dl2
May 17 22:09:47 22:09:47.408115:CID-0:RT:flow_initiate_first_path: first pak no
session
May 17 22:09:47 22:09:47.408115:CID-0:RT: flow find session returns error.
May 17 22:09:47 22:09:47.408115:CID-0:RT: flow_process_pkt re Ox7 (fp re
-1)
May 17 22:09:48 22:09:47.1032727:CID-0:RT:phasel ageout called for session id
37721, state: 4

Question: Why is the Telnet session failing?
Answer: A policy is denying the Telnet session.
Question: Which policy is denying this traffic?
Answer: The previous output shows a policy search

occurring in the zone untrust- > zone
Juniper-local context, where local is svor
WF depending on your assigned SRX device. The
session is not matching a policy within a context
that has the permit action, and is being dropped.
Question: Why is a different destination address

other than the ge-0/0/3 interface address being
displayed?
Answer: The configured destination NAT is causing

the destination IP address of the Telnet session to
change before the policy evaluation occurs.
Step 1.18
Navigate to the [edit security zones security-zone untrust]
hierarchy level. Configure the untrust zone with the address book entry of
isp-int for the interface address of the ISP virtual router.
lab@srxA-1# up 2
[edit security]
lab@srxA-1# edit address-book untrust
[edit security address-book untrust]

lab@srxA-1# set address isp-int local-ISP-address/32

lab@srxA-1# show
address vrl02 172.20.102.0/24;
address vr202 172.20.202.0/24;
address srxA-2 172.18.2.0/30;
address internet-host 172.31.15.1/32;
address isp-int 172.18.1.1/32;

attach {
zone untrust;

lab@srxA-1#
Step 1.191
Navigate to the [edit security policies from-zone untrust
to-zone Juniper-local] hierarchy level. Configure the policy
untrust-telnet to allow Telnet traffic from the address-book entry isp-int
you created to any destination address. When you are finished, navigate to the top
of the hierarchy level and commit the configuration.
lab@srxA-1# top edit security policies from-zone untrust to-zone Juniper-local
[edit security policies from-zone untrust to-zone Juniper-local]

lab@srxi�-1# set policy untrust-telnet match destination-address any

lab@srxA-1# set policy untrust-telnet match source-address isp-int

lab@srxA-1# set policy untrust-telnet match application junos-telnet

lab@srxA-1# set policy untrust-telnet then permit

lab@srxA-1# show policy untrust-telnet
match {
source-address isp-int;
}
then {
permit;

lab@srxA-1# top
[edit]
lab@srxA-1# commit
commit complete
[edit]
lab@srxA-1#
Step 1.20

session again to the ge-0/0/3 interface address.
Trying 172.18.1.2...
Escape character is 'Al'.
vr-device (ttypl)
login:

should be successful.
Step 1.21
From your assigned SRX device, remove the traceoptions configured under the
[edit security flow] hierarchy level. When you are finished, commit the
configuration.
[edit]
lab@srxA-1# delete security flow traceoptions
[edit]
lab@srxA-1# coilllllit
commit complete
[edit]
lab@srxA-1#
Question: Why is it necessary to remove the

traceoptions configuration?
Answer: Security flow traceoptions can heavily tax

the system resources on the SRX device. We
recommend using them only during troubleshooting
and to remove them when the troubleshooting is
finished.

so.
Part 2: Troubleshooting IPsec Tunnels
In this lab part, you troubleshoot an IPsec tunnel that is down.The team that is
working on srx�-2. where� is the letter of your assigned pod, will load a
configuration that will cause the previously established site-to-site IPsec tunnel to go
down. Both teams will then work together and troubleshoot the tunnel from sr�-1's
perspective.
Step 2.1
Issue the run show security ike security-associations and run
show security ipsec security-associations commands.
[edit]
7999631 UP f847490a6634589a 4f76c4285dfdObed Main 172.18.2.2
[edit]
<131073 ESP:3des/shal 74955979 2899/ unlim root 500 172.18.2.2
>131073 ESP:3des/shal 52c2db54 2899/ unlim root 500 172.18.2.2
Question: What is the status of the site-to-site IPsec

tunnel?
Answer: The site-to-site IPsec tunnel is established

to the other team's router.
Step 2.2
Note
Perform the following lab step only on

srxx-2.
From the session established with srxx-2, load the labB-IPsec_down. config
from the /var/home/lab/ajsec/ directory.Commit the configuration and exit to
operational mode when complete.
[edit]
lab@srxA-2# load override ajsec/lab8-IPsec_down.config
load complete

[edit)
commit complete
lab@srxA-2>
Note
Perform the following lab steps only on

srxK-1. Both lab teams should be working
together on srq-1 to resolve the issue.
Step 2.3
From the Telnet session established with srxx-1, issue the clear security ike
security-associationsand clear security ipsec
security-associationscommands. Then issue the show security ike
security-associationsand show security ipsec security
associationscommands.
[edit)
lab@srxA-1# run clear security ike security-associations
[edit)
lab@srxA-1# run clear security ipsec security-associations
[edit)
[edit)
Total active tunnels: O
Question: Why is it necessary to clear the IKE and

IPsec security associations?
Answer: The security associations must time out for

the problem to become apparent. Clearing the
security associations speeds up this process.
Question: What is the status of the IPsec tunnel?
Answer: The status of the IPsec tunnel is down.

Question: What are some possible issues that
cause an IPsec tunnel to go down?
Answer: Some possible issues are: connectivity

problems, encapsulation mismatches, incorrect
pre-shared keys, encryption mismatches,
authentication mismatches, and protocol
mismatches.
Question: What proposal item mismatch will not

cause an IPsec tunnel to go down, or fail to
establish?
Answer: A lifetime mismatch will not cause a

problem. The IPsec tunnel endpoints will negotiate
to the lower of the two values.
Question: Where is the best place to begin

troubleshooting?
Answer: Begin troubleshooting the lower layers of

the OSI model. If Network Layer connectivity is not
established the IPsec tunnel cannot come up.
Question: What troubleshooting tool can you use to

validate Layers 1 through Layer 3?
Answer: The ping tool validates Layers 1 through 3.
Step 2.4
Ping the remote side of the IPsec tunnel to test connectivity.
[edit]
[email protected]# run ping 172.18.2.2 detail count 2
PING 172.18.2.1 (172.18.2.2): 56 data bytes
64 bytes from 172.18.2.2 via ge-0/0/3.0: icmp_seq=O ttl=64 time=6.842 ms
64 bytes from 172.18.2.2 via ge-0/0/3.0: icmp_seq=l ttl=64 time=7.340 ms

round-trip min/avg/max/stddev ; 6.842/7.091/7.340/0.249 ms
Question: What did the ping test reveal?
Answer: The ping test reveals the problem does not

exist within the first 3 layers of the OSI model.
Question: What are the next areas to examine and

troubleshoot?
Answer: The only other protocols that are involved,

which reside above Layer 3, are IPsec and IKE. You
will examine these areas next.
Step 2.5
Navigate to the [edit security ike] hierarchy level.Configure the
traceoptions to record any IKE related activity.
[edit]
lab@srxA-1# edit security ike
[edit security ike]

lab@srxA-1# set traceoptions flag ike
[edit security ike]

lab@srxA-1#
Step 2.6
Navigate to the [edit security ipsec] hierarchy level.Configure the
traceoptions to record any SA related activity.Commit the configuration when you
are finished.
[edit security ike]
lab@srxA-1# up
[edit security]
lab@srxA-1# edit ipsec

lab@srxA-1# set traceoptions flag security-associations

lab@srxA-1# commit
commit complete

lab@srxA-1#
Question: Where is the Junos operating system

storing the traceoptions?
Answer: The Junos OS is storing the traceoptions in

the kmd log file.
Step 2.7
Clear the kmd log file of old information by issuing the run clear log kmd
command. Examine the kmd log file by issuing the run show log kmd
command.
Note
The kmd log file might take a few minutes

to start filling up. If nothing is seen initially
when you issue the run show log kmd
command, wait a minute and issue the
command again.

lab@srxA-1# run clear log kmd

lab@srxA-1# run show log kmd
May 17 23:46:03 srxA-1 clear-log[8414]: logfile cleared
May 17 23:46:22 ike_get_sa: Start, SA = { d4577a78 Od5c15e0 - 4228ba42 fb2e12b8
} I 00000000, remote = 172.18.2.2:500
May 17 23:46:22 ike sa find: Not found SA = { d4577a78 Od5c15e0 - 4228ba42
fb2el2b8 } - -
May 17 23:46:22 ike sa find half: Found half SA = { d4577a78 Od5c15e0 - 00000000
00000000 } - - -
May 17 23:46:22 ike sa upgrade: Start, SA = { d4577a78 Od5c15e0 - 00000000
00000000 } -> { �- .-- 4228ba42 fb2e12b8 }
May 17 23:46:22 ike_decode_packet: Start, SA { d4577a78 Od5c15e0 - 4228ba42
fb2e12b8} I 00000000, nego = -1
May 17 23:46:22 ike_decode_payload_sa: Start
May 17 23:46:22 ike_decode_payload_t: Start, # trans 1
May 17 23:46:22 ike st i sa value: Start
May 17 23:46:22 ike-st i er: Start
May 17 23:46:22 ike-st-i-cert: Start
May 17 23:46:22 ike-st i vid: VID [O..16] afcad713 68alflc9
May 17 23:46:22 ike-st i vid: VID[O..16] 27bab5dc Olea0760
May 17 23:46:22 ike-st i vid: VID [O..16] 6105c422 e76847e4
May 17 23:46:22 ike-st i vid: VID[O ..16] 4485152d 18b6bbcd
May 17 23:46:22 ike st i vid: VID[O..16] cd604643 35df21f8
May 17 23:46:22 ike-st i vid: VID[O..16] 90cb809l 3ebb696e
May 17 23:46:22 ike st i vid: VID[O ..16] 7d9419a6 5310ca6f
www.juniper.net Performing Security Troubleshooting Techniques (Detailed) . Lab 8-19

May 17 23:46:22 ike st i vid: VID (0..16] 4al3lc81 07035845
May 17 23:46:22 ike st i vid: VID (0 .. 28] 69936922 874lc6d4
May 17 23:46:22 ike st 0 ke: Start
May 17 23:46:22 ike st o nonce: Start
May 17 23:46:22 ike_policy_reply_isakmp_nonce_data_len: Start
May 17 23:46:22 ike_encode_packet: Start, SA = { Oxd4577a78 Od5cl5e0 - 4228ba42
fb2el2b8 } I 00000000, nego = -1
May 17 23:46:22 ike_send_packet: Start, send SA = { d4577a78 Od5cl5e0 - 4228ba42
fb2el2b8}, nego = -1, dst = 172.18.2.2:500, routing table id = O
May 17 23:46:22 ikev2_packet_allocate: Allocated packet bdOcOO from freelist
May 17 23:46:22 ike_sa_find: Found SA = { d4577a78 Od5cl5e0 - 4228ba42 fb2el2b8
}
May 17 23:46:22 ikev2_packet_vl_start: Passing IKE vl.O packet to IKEvl library
May 17 23:46:22 ike_get_sa: Start, SA = { d4577a78 Od5cl5e0 - 4228ba42 fb2el2b8
} I 00000000, remote = 172.18.2.2:500
May 17 23:46:22 ike sa find: Found SA = { d4577a78 Od5cl5e0 - 4228ba42 fb2el2b8
}
Question: From the previous output can you

determine the problem?
Answer: Although the answer lies somewhere in the

output, the overwhelming amount of data makes it
difficult to find.
Question: What are some match conditions that you

can use to filter the output, but still obtain the
necessary information?
Answer: Some match conditions that might help

are: ike, initiator, and responder.
Step 2.8
Filter the kmd logs by issuing the run show log kmd I match ike command.
lab@srxA-1# run show log kmd I match ike
May 17 23:46:22 ike decode packet: Start, SA { d4577a78 Od5cl5e0 - 4228ba42
fb2el2b8} / 00000000, n;go = -1
May 17 23:46:22 ike_decode_payload_sa: Start

May 17 23:46:22 ike_decode_payload_t: Start, # trans 1
May 17 23:46:22 ike_st_i_sa_value: Start
May 17 23:46:22 ike st i er: Start
May 17 23:46:22 ike-st i cert: Start
May 17 23:46:22 ike-st i vid: VID [O..16] afcad713 68alflc9
May 17 23:46:22 ike st i vid: VID [O.. 16] 27bab5dc Olea0760
May 17 23:46:22 ike st i vid: VID [O..16] 6105c422 e76847e4
May 17 23:46:22 ike-st i vid: VID [O..16] 4485152d 18b6bbcd
May 17 23:46:22 ike-st i vid: VID [O..16] cd604643 35df21f8
May 17 23:46:22 ike st i vid: VID [O..16] 90cb8091 3ebb696e
May 17 23:46:22 ike st i vid: VID [O..16] 7d9419a6 5310ca6f
May 17 23:46:22 ike st i vid: VID [O..16] 4a13lc81 07035845
May 17 23:46:22 ike-st i vid: VID [O..28] 69936922 874lc6d4
May 17 23:46:22 ike st o ke: Start
May 17 23:46:22 ike_st_o_nonce: Start
May 17 23:46:22 ike_policy_reply_isakmp_nonce_data_len: Start
May 17 23:46:22 ike_encode_packet: Start, SA = { Oxd4577a78 Od5c15e0 - 4228ba42
fb2e12b8 } I 00000000, nego = -1
May 17 23:46:22 ike_send_packet: Start, send SA = { d4577a78 Od5c15e0 - 4228ba42
fb2e12b8}, nego = -1, dst = 172.18.2.2:500, routing table id = O
May 17 23:46:22 ikev2_packet_allocate: Allocated packet bdOcOO from freelist
May 17 23:46:22 ike_sa_find: Found SA = { d4577a78 Od5c15e0 - 4228ba42 fb2e12b8
May 17 23:46:22 ikev2_packet_vl_start: Passing IKE vl.O packet to IKEvl library

May 17 23:46:22 ike_get_sa: Start, SA = { d4577a78 Od5c15e0 - 4228ba42 fb2e12b8
} I 00000000, remote = 172.18.2.2:500
May 17 23:46:22 ike sa find: Found SA = { d4577a78 Od5c15e0 - 4228ba42 fb2e12b8
}
May 17 23:46:22 ike_decode_packet: Start, SA { d4577a78 Od5c15e0 - 4228ba42
fb2e12b8} / 00000000, nego = -1
Question: Did the addition of the ike match option

help?
Answer: The answer is not forthcoming when

filtering on the ike keyword.
Step 2.9
Filter the kmd logs by issuing the run show log kmd I match
"initiator/ responder" command.
lab@srxA-1# run show log kmd I match "initiator/responder"

1
May 18 00:02:22 172.18.1.2:500 (Initiator) <-> 172.18.2.2:500 { 14912a07
e07a08bd - 00000000 00000000 [-lJ / OxOOOOOOOO } IP; Warning: Number of
proposals != 1 in ISAKMP SA, this is against draft!
May 18 00:02:22 ike calc mac: Start, initiator = true, local = true
May 18 00:02:22 <no�e>:500 (Responder) <-> 172.18.2.2:500 { 14912a07 e07a08bd -
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Notification data has attribute
list
May 18 00:02:22 <none>:500 (Responder) <-> 172.18.2.2:500 { 14912a07 e07a08bd -
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Notify message version = 1
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Offending payload type = 64
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Offending payload data offset = O
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Error text = Incorrect pre-shared
key (Invalid next payload value)
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Offending message id = OxOOOOOOOO
May 18 00:02:22 <none>:500 (Responder) <-> 172.18.2.2:50D { 14912a07 e07a08bd -
e85ff29b e2768e72 [OJ I Ox35647e4a} Info; Received notify err = Invalid
payload type (1) to isakmp sa, delete it
Question: From the previous output can you

determine the problem?
Answer: The output reveals the problem to be a

mismatched pre-shared key.
Note
Although the problem is a pre-shared key

mismatch, deciphering from the previous
output what the exact value of the
pre-shared key might be is impossible. In
the next lab step you will be given the
correct pre-shared key value that will allow
the IPsec tunnel to establish.
Step 2.10
Navigate to the [edit securi tyJ hierarchy.Change the pre-shared key, located
within the policy policy-1, to juniperRocks. Commit the configuration when
complete.
[edit security ipsecJ

[edit security]
lab@srxA-1# set ike policy policy-I pre-shared-key ascii-text juniperRocks
[edit security]
lab@srxA-1# commit
commit complete
[edit security]
lab@srxi'>.-1#
Step2.11
Issue the show security ike security-associations and show
security ipsec security-associations commands.
[edit security]
7999688 UP db463a8d62e4a2ee 0901447ee7eef5c0 Main 172.18. 2.2
[edit security]
<131073 ESP:3des/shal ac88ee70 3572/ unlim root 500 172.18.2.2
>131073 ESP:3des/shal b40c7e65 3572/ unlim root 500 172.18.2.2
Question: Is the IPsec tunnel established?
Answer: Yes. The IPsec tunnel has returned to its

previous functioning state and is established.
Note
Perform the following lab steps only on both

devices in the pod.
Step2.12
Enter configuration mode and load the reset.config file from the /var/home/lab/
ajsec/ directory. Commit the configuration and return to operational mode when
complete. Log out of your assigned device using the exit command.
[edit]
lab@srxA-1# load override ajsec/reset.config
[edit]
commit complete
lab@srxA-1> exit
srxA-1 (ttyuO)
login:

srxA-1 srxD-1
-i
_i
-I
srxA-2 srxD-2
srxB-1 vr.<fevice
srxB-2 Server
\ srxC-1 _ Gateway ii
'E1
-
srxC-2 Term Server ii

Pod A Network Diagram: Performing

Security Troubleshooting Techniques Lab
--- lnterfacege-0/0/4 --
172.20.2010/24 17220 1020/24
(.� (.�
Pod B Network Diagram: Performing

vlan.103
--- lnterfacege-0/0/4 -----�
172.20.2030/24
(.10)

Pod C Network Diagram: Perforn1ing

Security Troubleshooting Techniicwues Lab
vlan.105
172.20.205.0/24 172.20.106.0/24
(.10) (.10)
Juniper-SY ACME-SV ......_ Virtual Routers -- Juniper-WF ACME-WF
Pod D Network Diagram: Perfor11ning

vlan.107
-- lnterfacege-0/0/4 -�----
172 20 2070/24
(.10)

AJSEC 12.b LGD PDF

Uploaded by

Copyright:

Available Formats

AJSEC 12.b LGD PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AJSEC 12.b LGD PDF

Uploaded by

Copyright:

Available Formats

A�dvanced Junos Security

Detailed Lab Guide

Worldwide Education Services

1194 North Mathilda Avenue

Course Number: EDU-JUN-AJSEC

Lab 2: Implementing Layer 2 Security {Detailed) ........................... 2-1

Lab 3: Implementing Junos Virtual Routing {Detailed) ....................... 3-1

Lab 4: Advanced NAT Implementations {Detailed) .......................... 4-1

Lab 5: Hub-and-Spoke IPsec VPNs {Detailed) .............................. 5-1

Lab 6: Configuring Group VPNs {Detailed) ................................ 6-1

Lab 7: Implementing Advanced IPsec VPN Solutions {Detailed) ............... 7-1

Lab 8: Performing Security Troubleshooting Techniques {Detailed) ............ 8-1

www.juniper.net Contents • iii

www.juniper.net Course Overview • v

vi • Course Overview www,juniper.net

www.juniper.net Course Agenda • vii

CU and GUI Text

Style Description Usage Example

Courier New Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Phy sical interface:fx:pO,

Defined and Undefined Syntax Variables

Style Description Usage Example

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

viii • Document Conventions www.juniper.net

Education Services Offerings

Juniper Networks Support

www.juniper.net Additional Information • ix

www.juniper.net Implementing AppSecure (Detailed) • Lab 1-1

Part 1: Verifying Access to the CLI and VMware Client

Question: What is the management address

Answer: The answer varies. In this example, the

Lab 1-2 • lmplementingAppSecure (Detailed) www.juniper.net

O Show quick connect on sla1tup � Save session

--- JUNOS 12.1X44-Dl0.4 built 2013-01-08 05:15:31 UTC

www.junipe·r.net Implementing AppSecure (Detailed) • Lab 1-3

Run VNC Viewer

Lab 1-4 • Implementing AppSecure (Detailed) www.juniper.net

Answer: As shown in the output, you should be able

Question: Do you see icons for FTP and a Web

Answer: As shown in the output, you should see

Part 2: C1onfiguring AppFW and ApplD Features

www.juniper.net Implementing AppSecure (Detailed) • Lab 1-5

[edit security policies]

from-zone Untrust to-zone Trust {

Lab 1-6 • Implementing AppSecure (Detailed) www.juniper.net

Question: Based on the output, which types of

Answer: The SRX device is allowing all traffic from

Question: Will the HTTP policy block non-HTTP

Answer: No. The HTTP policy is only examining the

www.junipe,r.net Implementing AppSecure (Detailed) • Lab 1-7

Lab 1-8 • Implementing AppSecure (Detailed) www,juniper.net

Question: Did the traffic make it through the

Answer: Yes, the traffic made it through.The

Question: Is this behavior a security threat?

Answer: Yes. An attacker could use this information

Question: How can you stop this type of unwanted

Answer: To stop the unwanted traffic, you can