Detail Lab Guide

Advanced 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, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
Advanced Junos Security Detailed Lab Guide, Revision 12.b
Copyright 2013 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.aMarch 2011
Revision 12.aJune 2012
Revision 12.bJune 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.1X44-D10.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 system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.

Contents
Lab 1: Implementing AppSecure (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Part 1: Verifying Access to the CLI and VMware Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring AppFW and AppID 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 Inter-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 ImplementationPort Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Part 3: Configuring NAT ImplementationLocal Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
Part 4: Implementing IPv6 NATNAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
Part 5: Implementing IPv6 NATNAT46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Lab 6: Configuring Group VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Part 2: Configuring the Group Member IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Part 3: Configuring the Security Policies to Use the IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Part 4: Verifying the Group IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Part 3: Configuring the GRE Tunnel over the IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Course Overview
This three-day course, which is designed to build off of the current Junos 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-D10.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 AppID, AppFW, and AppTrack.
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 IPv6 NAT, such as
NAT64, NAT46, and DS-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 Junos 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 troubleshooting
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. Students 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
Day 1
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
Day 2
Chapter 5: Advanced NAT Concepts
Advanced NAT Implementations Lab
Chapter 6: IPsec Implementations
Hub-and-Spoke IPsec VPNs Lab
Day 3
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
CLI and GUI Text

Frequently throughout this course, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style Description Usage Example

Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Console text:

Screen captures
Noncommand-related
syntax
GUI text elements:
Select , and then click
Menu names in the
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.
No distinguishing variant.

View configuration history by clicking
.
Text that you must enter.

Select , and type
in the 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.
Text where variable value is already

assigned.
Click in the dialog.
Text where the variables value is Type .
the users discretion or text where

the variables value as shown in
the lab guide might differ from the Select , and type
value the user must input in the 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 training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.net/techpubs/.
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or
at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
www.juniper.net Additional Information ix

x Additional Information www.juniper.net
Lab
Implementing AppSecure (Detailed)
Overview
In this lab, you will implement features of the AppSecure suite. You will begin by
configuring AppID 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 AppID and AppFW features.
Configure and use custom application signatures.
Configure and monitor AppTrack.

www.juniper.net Implementing AppSecure (Detailed) Lab 11
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 1.1
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 12 Implementing AppSecure (Detailed) www.juniper.net

Step 1.3
Log in as user with the password supplied by your instructor.

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
as the password to connect to the VMware client. Insert a 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.


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
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: Configuring AppFW and AppID Features
In this lab part, you configure an AppFW rule set to block FTP traffic that is being
disguised as Hypertext Transfer Protocol (HTTP) 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
from the directory. Commit
the configuration when 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
hierarchy level and issue the command.


Step 2.3
Examine the application by issuing the
command.

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 policy block non-HTTP

traffic that is using TCP ports 80 or 8080 as the
destination port?
Answer: No. The 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.

Step 2.5
Open an FTP session to the URL and use
port as the destination port. To log in, use the username of and password
of .

Step 2.6
From your assigned SRX device, examine the session table by issuing the
command.

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 AppID database for application
signatures that are suitable for your situation.
Look for HTTP-related application signatures in the AppID database by issuing the

command.

Question: Do you see any suitable application

signatures?
Answer: Although many application signatures exist

with HTTP in their name, the might
be helpful.
Step 2.8
Take a closer look at the application signature by issuing the

command.


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.

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 hierarchy level
and configure a rule set to only permit HTTP traffic and deny all other traffic. Then,
return to the
hierarchy level and apply the AppFW rule set to the security policy.
Also, configure the security policy to log session initialization attempts and
session closures.

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.
Step 2.10
Navigate to the hierarchy level and configure the
file to log messages with the severity and facility levels of
. Then, configure the log file to only match messages that contain the
tag. Commit the configuration when you are finished.

Step 2.11
From the VNC session established with VMware client, disconnect the previous FTP
attempt. Then, attempt the FTP connection using port again.

Step 2.12
From your assigned SRX device, issue the
command.

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.

Step 2.13
Examine the application system cache (ASC) with the
command
to determine whether there is a result for the recent FTP traffic.

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.
Step 2.14
Examine the for the results of the session messages that relate
to the FTP session by issuing the command.

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

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
URL. Once the
Web browser has opened, click the bookmark.
Note
If clicking the AJSEC FILES or the TESTURL
bookmark produces an error, please inform
your instructor immediately.

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 HTTP 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 HTTP as the Layer 7 protocol. Examine the
nested application by issuing the

command.



Question: Does this nested application contain the

necessary characteristics for the custom nested
application?
Answer: Yes. The

application signature is using HTTP as the Layer 7
protocol and has an example of an
context that you can use.
Step 3.4
Copy the nested application by issuing the

command.
Note
If, when copying the
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

operational command to restart the appidd
daemon.


Step 3.5
When copying a built-in application signature, the system copies the application
signature and replaces the keyword with the keyword. For example,
copying the application signature creates the custom
application signature .
Navigate to the
hierarchy level and issue a command to view the recently copied application
signature.

Question: What must you change in the new

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

member to correctly match the new HTTP
header context. Then, you 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 . Then,
navigate to the

hierarchy level.


Step 3.7
Configure member with the pattern match of
.

Step 3.8
Configure the new member with the of , the
of , and the of
.



Step 3.9
Navigate to the
hierarchy level. Then, create the rule
that denies traffic when it matches on the nested application signature
. Configure the with the action of .

Question: Why was the rule not

placed in the rule set?
Answer: The rule and the default

rule in the rule set have the
same action of . If you attempt to place the
rule in the
rule set, you receive an error upon commit.

Step 3.10
Navigate to the
hierarchy level. Then, configure the security policy to
reference the AppFW rule set. Commit the
configuration when you are finished.

Step 3.11
From the VNC session established with VMware client, close the Firefox browser.
Then, open the Firefox browser and click the the bookmark again.

Question: Did the
AppFW rule set restrict the HTTP transaction?
Answer: No. The HTTP transaction completed as if

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

commands.

Step 3.13
Examine the syslog file.


Question: Can you determine why the

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
rule set was implemented, the
rule set was in place. When the
rule set was employed, an ASC entry was recorded
for the server with destination TCP port 80. When
the 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.
Step 3.14
Navigate to the
hierarchy level. Once you are there, disable the recording of nested applications in
the ASC and commit the configuration.

Step 3.15
From the VNC session established with VMware client, close the Firefox browser.
Then, open the Firefox browser and click the the bookmark again.

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
rule set by issuing the
command.
Then, examine the syslog file to find the
logs for the blocked session.


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 AppTrack 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 hierarchy level
and configure a of and a .
Then, configure an action of . Then, apply the policer to the ge-0/0/9
interface as an input policer.



Step 4.2
Navigate to the hierarchy level and configure AppTrack to
generate a message upon session creation.

Step 4.3
Apply application tracking to the zone. Commit the configuration when you
are finished.

Step 4.4
From the VNC session established with VMware client and close the Firefox browser

if necessary. Then, double-click the gFTP client icon.

Step 4.5
Open a connection to the server using the
default FTP port of , username of , and a password of . Then, begin
to download the file named .

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

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
ine the AppTrack counters by issuing the

command.


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.
Step 4.8
Examine the AppTrack log messages for the logs pertaining to the FTP data session
by issuing the
command, where the match condition is the session ID
of the FTP data session that you obtained in step 4.6.

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.

Step 4.9
Configure AppTrack to generate session volume update messages when a session is
active for minutes. Commit the configuration when you are finished.

Step 4.10
From the VNC session established with the VMware client, begin the FTP transfer of
the file again. Overwrite the existing file when you are
prompted to do so.
Step 4.11
command to obtain the FTP data session ID.



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.
Step 4.12
Once the FTP transfer is complete, examine the AppTrack counters by issuing the
command.

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.

Step 4.13
Examine the AppTrack log messages by issuing the
command, where the
match condition is the session ID of the FTP data session that you obtained in
Step 4.12.

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.
Step 4.14
Exit configuration mode and log out of your assigned SRX device.

STOP Tell your instructor that you have completed this lab.




Lab
Implementing Layer 2 Security (Detailed)
Overview
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 21
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.

Lab 22 Implementing Layer 2 Security (Detailed) www.juniper.net
Step 1.3
Log in as user with the password . Enter configuration mode and load
the from the /var/home/lab/ajsec/ directory. Commit the
configuration when complete.

Step 1.4
Check the status of the switched interface you configured using the
command.
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 members SRX device.

Step 1.5
Navigate to the hierarchy. If your assigned device is SRX1,
configure the ge-0/0/2 interface for . If your assigned device is
SRX2, configure the ge-0/0/1 interface for . Also specify the
VLAN ID associated with your pod team members Juniper customer network, and
configure the IP address , where the value of is the VLAN
associated with your pod team members Juniper customer network.
Step 1.6
Add the interface you configured in the previous step to the 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
command to allow inbound ping and ftp traffic on the interface.


Step 1.7
If your assigned device is SRX1, configure the ge-0/0/1.0 interface for
with . If your assigned device is
SRX2, configure the ge-0/0/2.0 interface for
with . Also configure the interface with the VLAN member
, where the value of is the
remainder of the VLAN ID associated with your local Juniper customer network.
Commit the configuration when complete.

Step 1.8
Check the status of the switched interface you configured using the
command.

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

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

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 teams address that was configured in step 1.5, where is
the value of the VLAN associated with your local Juniper customer network. Source
the connection from the virtual routers routing instance associated with your local
Juniper customer network. Refer to the lab network diagram if needed.

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

Step 1.13
Return to the Telnet session established with the virtual router.
From the Telnet session established with the virtual router, initiate the ping test
again.

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 and answer the following
question.
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

configuration does not include a Layer 3 interface.
Step 1.15
In this step, you will configure the interface that will be used to route Layer 3
traffic for the Ethernet switching hosts. Issue the command

, where is the value of the VLAN associated with your local
Juniper customer network.


Step 1.16
Apply the interface you created in the previous step as a Layer 3 interface with
the command
, where is the value of
the VLAN associated with your local Juniper customer network.
Step 1.17
Add the interface you configured in the previous step to your local Juniper customer
network security zone. Configure the command to
allow inbound ping on the interface. When finished commit the configuration.
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
routers routing instance associated with your local Juniper customer network. Refer
to the lab network diagram if needed.

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.
STOP 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 and configuration
hierarchies.

Step 2.2
Delete the and configuration hierarchies.
Then, delete all of the interfaces.

Step 2.3
Navigate to the hierarchy. Configure the ge-0/0/1 interface
for , , and
.

Step 2.4
Configure the ge-0/0/4 interface for ,
, and .

Step 2.5
Navigate to the hierarchy. Create a security zone named
. Apply the ge-0/0/1 interface to the zone.

Step 2.6
Create a security zone named . Apply the ge-0/0/4 interface to the
zone.

Step 2.7
Create a security policy named that permits all traffic from the
zone to the zone.

Step 2.8
In this step, you will configure a routing instance that will forward the Layer 2
transparent mode traffic. Navigate to the
hierarchy. Configure the routing instance with
. Add the ge-0/0/1 and ge-0/0/4 interfaces to the routing
instance.

Step 2.9
Within the routing instance, configure a bridge-domain named with
. Add the VLAN ID , where the
value of is the VLAN ID associated with SRX1s local
Juniper customer network.


Step 2.10
Perform a command on the configuration.

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.
Step 2.11
Commit the configuration, and then reboot the SRX device.

Step 2.12
Log back in as user with the password after the device has finished
rebooting.

Step 2.13
From the Telnet session established with the virtual router, test your transparent
mode configuration by initiating a continuous ping test to the SRX2 teams
address, where is the value of the VLAN associated with your local
Juniper customer network. Source the connection from the virtual routers routing
instance associated with your local Juniper customer network. Refer to the lab
network diagram if needed.

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.
Step 2.14
Return to the session established with your assigned SRX1 device.
From your assigned SRX1 device, issue the command
,, and answer the question that follows.


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 , which is permitting
the traffic.
Step 2.15
From the Telnet session established with the virtual router, press Ctrl + c to
terminate the ping.
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!

Step 3.1
From assigned SRX1 device, navigate to the
hierarchy. Modify the existing security policy to only permit the predefined
application traffic between the and
zones. When finished, commit the configuration.
Step 3.2
From the Telnet session established with the virtual router, initiate an FTP
connection to the SRX2 teams address, where is the value of the
VLAN associated with your local Juniper customer network. Source the connection
from the virtual routers routing instance associated with your local Juniper
customer network.

Question: Is the FTP connection successful?
Answer: The FTP connection should be successful.
Step 3.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.


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
to discard all traffic from interface
ge-0/0/4.0.

Step 3.5
Apply the as a family bridge output filter on the ge-0/0/1.0 interface.
Commit your configuration when complete.

Step 3.6
From the Telnet session established with the virtual router, initiate the FTP
connection again.


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 to exit the FTP connection. Then, the open Telnet session on the
virtual router.

Step 3.8
From your assigned SRX1 device, log out using the command.




Lab
Implementing Junos Virtual Routing (Detailed)
Overview
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 31
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 and . You will then configure
Internet access for these VRs.
Note
assigned device.
Step 1.1


Step 1.2

Lab 32 Implementing Junos Virtual Routing (Detailed) www.juniper.net
Step 1.3
the from the directory.

.
Note
You may have to reboot the SRX device if
the interfaces mode changes from
transparent to route.
Step 1.4
Navigate to the hierarchy level. Configure two
VRs and . The VR should contain the VLAN interface that
directly connects your SRX device with the Juniper device. Then, the VR should
contain the VLAN interface that directly connects your SRX device with the ACME
device. When you are finished, commit your configuration.

Note
The next lab steps require you to log in to

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

Step 1.5
Open a separate Telnet session to the virtual router attached to your teams device.
Step 1.6

Step 1.7
Ping the Internet host by issuing the
command, where 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.

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
and commands.
Note
Even though the routing table names have

capital letters, it is not necessary to
capitalize any part of the previous
commands.


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 and routing instances to use the main routing
instances inet.0 routing table for unknown destinations. When you are finished,
commit the configuration.

Step 1.10
Issue the commands and
.


Question: How are the default static routes in the

VRs resolving the next hop?
Answer: The next hop is resolving through the inet.0

routing table.
Step 1.11
From the Telnet session established with the virtual router, ping the Internet host by
issuing the
command, where 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.

Question: Why is the ping test successful?
Answer: The VRs have a default route that resolves

through the main routing instances inet.0 routing
table.
Step 1.12
command and examine the routing table.


Question: Is there a route in the inet.0 routing table

to accommodate for the return ping traffic?
Answer: No. The inet.0 routing table does not have a

route to either attached device.
Question: How is the return traffic reaching the

attached devices?
Answer: When the session is initially created the

return path is calculated. The return traffic uses the
fast path of the flow services module that bypasses
the routing in the inet.0 routing table.
Part 2: Configuring Inter-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 hierarchy level. Remove the firewall filters
associated with the VLAN interfaces. When you are finished, commit the
configuration.

Step 2.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
command. Please refer to your
lab 3 diagram for the correct VLAN ID value.

Question: What does the Telnet session attempt

reveal?
Answer: The Telnet session attempt reveals no

connectivity between your local Juniper device and
ACME device.
Step 2.3

From your assigned SRX device, issue the commands
and .

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 (lt) interface

can be used to share routes between the VRs.
Step 2.4
Navigating to the hierarchy level. Configure
unit with the IP address of 172.21.1.1/30, and unit with the IP address of
172.21.1.2/30. Configure peering between the two units, and configure both units
with Ethernet encapsulation.


Step 2.5
Associate the lt-0/0/0.1 interface with the VR instance. Associate the
lt-0/0/0.2 interface with the VR instance.


Step 2.6
Configure OSPF in the and VR instances. Place the lt-0/0/0.1 and
the Juniper VLAN interface inside area in the VR instance. Place the
lt-0/0/0.2 and the ACME VLAN interface inside area in the VR instance. Add
the option to both VLAN interfaces inside of OSPF. When you are finished,


Step 2.7
Issue the command.

Question: Why is the OSPF instance not running?
Answer: OSPF is configured under the

and VR instances. The previous command is
displaying OSPF information for the main routing
instance.
Step 2.8
.

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 and VR routing instances by issuing
the command.

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


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.


Step 2.12
Test connectivity between the and VR instances by issuing the
command .

Answer: Yes. The ping test is successful.
Step 2.13
.

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
.
Note
It might take a minute for the OSPF

adjacencies to reach the state.


Question: In what states are the OSPF adjacencies?
Answer: The OSPF adjacencies should reach the

state.
Step 2.15
Examine the and VR instances routing tables.



Question: Are OSPF routes being shared between

the and VRs?
Answer: Yes. OSPF routes are being shared.
Step 2.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
command. Please refer to your
lab 3 diagram for the correct VLAN ID value.

Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.

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

Step 2.18
From your assigned SRX device, find the recently created Telnet session in the
session table.

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

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

Step 3.2
Place the ge-0/0/1 interface in the zone.


Step 3.3
On your device, configure the security policy to permit any
traffic that is going towards the untrust zone.

Step 3.4
Configure a RIB group named that will copy interface routes
located in the inet.0 table to the inet.0 table. Configure the VR to place
its interface routes into the RIB group. When you are finished,

Step 3.5
Issue the command.



Question: Are the interface routes in the

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

inet.0 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.0
routing table to resolve the destination address.
Because the route to the ACME device is located
inside the inet.0 routing table, the main
routing instance does not have a method to send
traffic to the ACME device. Copying routes from the
inet.0 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 . Configure a
default static route that will send all traffic to the remote SRX device over the
ge-0/0/1 interface.


Step 3.7
Configure the firewall filter to send any traffic destined to the remote
ACME device to the routing instance. Configure a counter named
to count any packets that match the filter.

Step 3.8
Apply the 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.

Step 3.9
From the Telnet session established with the virtual router, issue the command

to establish communication between the ACME-SV and ACME-WF customer devices.

Answer: No. The ping test is not successful.
Step 3.10
From your assigned SRX device, issue the command
.

Question: Is the firewall filter being

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

Question: Where is the sending this
traffic?
Answer: The is sending this traffic to

the routing instance.
Step 3.11
Issue the command.

Question: Why is the failing to

forward the traffic?
Answer: The routing instance

does not have any routing information in its inet.0
routing table.
Question: How can you put the necessary routing

information in this routing instance?
Answer: The necessary routing information can be

placed in routing instance through
the use of RIB groups.
Step 3.12
Configure the RIB group to copy interface routes from the inet.0
routing table to the routing table. Configure a policy to
allow only the 172.19.1.0/30 prefix to be copied from the routing table.
When you are finished, commit the configuration and exit to operational mode.



Step 3.13
Issue the command and
examine the routing table.

Question: Why are only two routes in this routing

table?
Answer: You placed the prefix in

the routing table through the RIB
group. The prefix is now resolvable
because the next hop of is
reachable.
STOP Ensure that the remote student team within your pod has finished the
previous step before continuing.
Step 3.14
From the Telnet session established with the virtual router, issue the command

to establish communication between the ACME-SV and ACME-WF devices.

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

check your configuration or your instructor.
Step 3.15
Initiate a Telnet session from the local ACME device to the remote ACME device.
Issue the
command.

Question: Is the Telnet session successful?
Answer: Yes. The Telnet session is successful.
Step 3.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:


Step 3.17
From your assigned SRX device, issue the command
and examine the
session table.

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.
Step 3.18
From the Telnet session established with the virtual router, exit the session.

Step 3.19
From your assigned SRX device, log out using the command.






Lab
Advanced NAT Implementations (Detailed)
Overview
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 41
Part 1: Loading the Baseline Configuration
In this lab part, you load the baseline configuration. You will also work with the
remote student team within your pod, and execute a quick verification that you can
reach the remote teams 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
Step 1.3
configuration and exit to operational mode when complete.

Lab 42 Advanced NAT Implementations (Detailed) www.juniper.net
Step 1.4
Verify that you can reach the remote pod teams SRX interfaces that are connected
to their virtual routers. Use rapid pings to verify connectivity to both of the remote
pod teams SRX interfaces that are connected to the Juniper and ACME virtual
routers.

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.


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.

Note
We use a /24 prefix to emulate real-world

environments where a range of
public-facing IP addresses might exist. NAT
allows you to use public-facing IP
addresses without needing to assign them
to the interface.
SRX1 will own the address
range in this topology. SRX2 will own the
address range.
Step 1.7
Create a new security zone named and add the ge-0/0/2
interface to the zone.

Step 1.8
Create a new security policy named . This policy allows
Telnet traffic originating from the local Juniper customer network to initiate sessions
to external Telnet server through the ge-0/0/2 interface. Use the existing
entry for your policys
match. Use the predefined application for
your policys match.


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 teams ge-0/0/2 interface as the next hop.

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.
The
CLI command can be very helpful
when looking for a particular string within
your configuration. Including
provides context when the matching
text is displayed.
so.
Part 2: Configuring NAT ImplementationPort 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
interface of your assigned SRX device.

Step 2.1
Navigate to the hierarchy. Configure the
destination NAT pool with the virtual router address associated
with your local ACME customer network.
Step 2.2
Configure the NAT with a directional context that will
perform NAT on traffic coming from the zone.
Note
Directional context for destination NAT can

only be established with a statement.
No route-lookup takes place to determine
an egress interface until after destination
NAT has been processed.
Step 2.3
Configure a rule named 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 teams external NAT address. If your assigned device is
SRX1, apply this rule to traffic destined to the address. If your
assigned device is SRX2, apply this rule to traffic destined to the
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.


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

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

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

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 need to be configured

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

one of many in the
address range that is not configured on the
ge-0/0/2 interface. In our topology, the remote
teams SRX device will recognize the destination
IP address is on a local segment and send out an
ARP request. Without , 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 on your assigned SRX device. The SRX device should
respond to any ARP requests for available IP addresses in the address ranges
allocated for your assigned SRX device. SRX1 will use
. SRX2 will use .

Step 2.5
Navigate to the
hierarchy level. Configure entries for the remote student teams
Juniper and ACME customer networks. Place these entries into an
named . Attach the
address-book to the zone.

Step 2.6
Configure a security policy named that will allow
Telnet traffic from the remote teams Juniper and ACME customer networks to your
assigned devices local ACME customer network. Configure the
to match the address-set , and use the existing
entry for your policys match. The
value of is the remainder of the VLAN ID associated with your local ACME
customer network. Next, commit the configuration and exit to operational mode.

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.

Step 2.8
Student Device User Name Password

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
teams external NAT address you configured in step 2.5. If your assigned device is
SRX1, use the address. If your assigned device is SRX2,use the
address. Source the connection from the virtual routers routing
instance associated with your local Juniper customer network. Refer to the lab
network diagram if needed.

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

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.

so.
Part 3: Configuring NAT ImplementationLocal 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 SRX device.
If your assigned device is SRX1, use the address. If your assigned
device is SRX2,use the address. Source the telnet connection from
the virtual routers routing instance associated with your local Juniper customer
network as shown on the lab network diagram.


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.

Question: Can you identify the problem?
Answer: The NAT

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

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 address. If
your assigned device is SRX2,use the address.


does not establish.
Step 3.5
command.


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

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
address-book entry for your policys match, where the
value of is the remainder of the VLAN ID associated with your local Juniper
customer network. Configure the to match the
address-book entry , where the value of is the remainder of the VLAN ID
associated with your local ACME customer network. When you are finished, commit
the configuration.

Step 3.8


is successful.
Step 3.9
command.

Question: Is the Telnet session found in the session

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

session table.
Step 3.10


Step 3.11
From your assigned SRX device, use the
command to confirm that traffic initiated from the ACME
customer zone will be evaluated by the NAT.

Step 3.12
Use the command to confirm that intrazone
traffic is configured for the ACME customer zone.

Step 3.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 address. If your assigned
device is SRX2,use the address. Source the telnet connection from
the virtual routers routing instance associated with your local ACME customer
network.


does not establish.
Step 3.14
From the Telnet session established with your assigned SRX device, issue the
command.
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
. Name the rule . 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.


Step 3.16



is successful.
Step 3.17
command.
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



so.
Part 4: Implementing IPv6 NATNAT64
In this lab part, you configure and verify operations for NAT64.This IPv6 NAT
implementation requires both destination NAT and source NAT for proper operation.
Both pod teams will configure the same IPv6 subnet addressing within the local
Juniper customer network, and will perform NAT64 to properly translate the IPv6
addresses to IPv4 addresses.
The IPv6 NAT implementation will allow an IPv6 host within the Juniper customer
network on the virtual router to telnet to an IPv4 host resource on the remote
student teams ACME customer network through a public-facing IP address
associated with the ge-0/0/2 interface of your assigned SRX device.
Step 4.1
Configure your VLAN interface associated with your local Juniper customers network
with the IPv6 address 2001:db8::1/64.
Step 4.2
Delete the IPv4 address from your VLAN interface associated with your local Juniper
customers network.

Step 4.3
For steps 4.34.5, you will configure destination NAT64 to translate the IPv6
destination traffic to an IPv4 address. Navigate to the
hierarchy. Configure a destination NAT pool named
with the IP address of the remote student teams external NAT
address. If your assigned device is SRX1, use the address. If your
assigned device is SRX2,use the address.


Step 4.4
Configure a destination NAT rule set named with a directional context
that will perform NAT on traffic coming from your local Juniper customer network's
zone.

Step 4.5
Configure a rule within the rule set named to match
traffic destined for the IPv6 address 2001:db8::5/128. Next, specify that the
destination address of the matching traffic will be translated to the pool
.

Step 4.6
For steps 4.64.8, you will configure source NAT64 to translate the IPv6 source
traffic to an IPv4 address. Navigate to the
hierarchy. Configure a source NAT pool named with an
external NAT64 IP address on the zone subnet. If your assigned
device is SRX1, specify the address. If your assigned device is SRX2,
specify the address.

Step 4.7
Configure a source NAT rule set named with a directional context
that will perform NAT on traffic coming from your local Juniper customer network's
zone and destined for the zone.

Step 4.8
Configure a source NAT rule named to match traffic from the source
address 2001:db8::10/128. Specify the rule to match the destination address of
the IP address of the you configured in Step 4.3. If your
assigned device is SRX1, use the address. If your assigned device is
SRX2,use the address. Also specify that the source address of the
matching traffic will be translated to the pool .


Step 4.9
Navigate to the
hierarchy. Configure an
additional matching source address for the remote teams external NAT address that
was configured in step 4.6. If your assigned device is SRX1, specify the
address. If your assigned device is SRX2, specify the
address.

Step 4.10
Within your local Juniper customer network security zone, create an address book
entry named for the IPv6 address 2001:db8::10/128.

Step 4.11
Create another address book entry named under the
security zone for the subnet.

Step 4.12
Configure NDP proxy on your assigned SRX device at the
hierarchy. The SRX device should respond to any NDP requests for the IPv6 address
2001:db8::5/128 on your local interface within your Juniper customer
network.


Step 4.13
Navigate to the hierarchy. Configure a security
policy named from your local Juniper customer zone to the
zone to allow only telnet traffic. Configure the source address to
match the address book entry . Specify the destination address as
.

Step 4.14
Configure another security policy named from the
zone to your local ACME customer zone to allow only telnet traffic
from the remote student team. Configure the to match the
address book entry . Configure the to
match the address-book entry , where the value of is the remainder of the

VLAN ID associated with your local ACME customer network.


Step 4.15
Enable IPv6 flow-based mode on your assigned SRX device at the
hierarchy and then commit the
configuration. The SRX will require a reboot to enable IPv6 flow-based mode. Issue
the command after the commit is complete.


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 IPv6
flow-based mode.
Step 4.16
Log back into the SRX device as user after it has finished rebooting.

STOP Ensure that the remote student team within your pod has finished steps
4.1 to 4.16 before continuing.
Step 4.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 IPv6 Telnet
session to the IPv6 address 2001:db8::5. Source the telnet connection from the
routing instance associated with your local Juniper customer network.


should establish successfully.

Step 4.18
command.

Question: What does the output display?
Answer: The output displays that NAT has modified

both the source and destination of the IPv6 address
as the packet traversed the 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.
Step 4.19
.



Question: Do you see translation hits occurring in

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

modified both the source and destination of the
IPv6 address, and that translation hits have
occurred.
Step 4.20



so.
Part 5: Implementing IPv6 NATNAT46
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 IPv4
addresses to IPv6 addresses.
The IPv6 NAT implementation will allow an IPv4 host within the ACME customer
network on the virtual router to telnet to an IPv6 host resource on the remote
student teams Juniper customer network through a public-facing IP address
associated with the interface.
Step 5.1
For steps 5.15.3, you will configure destination NAT to translate a local IPv4
address within the ACME customer network to a public facing address that will be
used for NAT46. Enter configuration mode and navigate to the
hierarchy. Configure a destination NAT pool named
with a public-facing address that will be used for
NAT46. If your assigned device is SRX1, specify the address . If your
assigned device is SRX2, configure the address .
Step 5.2
Configure a destination NAT rule set named with a
directional context that will perform NAT on traffic coming from your local ACME
customer network's zone.

Step 5.3
Configure a rule within the rule set named to
match traffic destined for , where is your local
ACME customer network. Then specify that the destination address of the matching
traffic will be translated to the pool .

Step 5.4
Configure another destination NAT pool named with
the IPv6 address 2008:db8::10/128. This pool will be used to perform NAT46 on
the traffic from the remote student teams ACME customer network.

Step 5.5
Under the destination NAT rule-set , configure another source NAT
rule named to match Telnet traffic sourced from the
172.20.192.0/19 prefix. Apply this rule to traffic destined to the remote teams
IP address. If your assigned device is SRX1, specify
the address . If your assigned device is SRX2, configure the address
. Specify that the destination address of the matching traffic will be
translated to the pool .
Note
The prefix will

accommodate the local and remote ACME
customer networks.

Step 5.6
For steps 5.65.8, you will configure source NAT46 to translate the source IPv4
address to an IPv6 address. Navigate to the
hierarchy. Configure a source NAT pool named with the
IPv6 address 2001:db8::6/128.

Step 5.7
Configure a NAT rule-set named with a directional context that will
perform source NAT on traffic coming from the zone and
destined for your local Juniper customer network's zone.

Step 5.8
Configure a source NAT rule for the rule-set named
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 .

Step 5.9
Configure NDP proxy on your assigned SRX device at the
hierarchy. The SRX device should respond to any NDP requests for the IPv6 address
2001:db8::6/128 on your local interface within your Juniper customer
network.


Step 5.10
Configure on your local interface within your ACME customer
network for , where is your local ACME
customer network.

Step 5.11
Create another address book entry named under the
zone for the remote student teams source NAT address for
NAT46. If your assigned device is SRX1, use the address . If your
assigned device is SRX2, use the address .

Step 5.12
Navigate to the hierarchy. Configure a security
policy named to allow Telnet traffic from your local ACME
customer zone to the remote student teams source NAT address for NAT46 on the
zone. Configure the to match the
address-book entry , where the value of is the remainder of the VLAN ID
associated with your local ACME customer network. Configure the
to match the address book entry .

Step 5.13
Configure another security policy named to allow Telnet
traffic from the remote student team on the zone to your local
Juniper customer zone. Configure the source address to match the address book
entry . Configure the destination address to match the
address book entry
.. When finished, commit the configuration and

return to operational mode.

STOP 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 , where is your local ACME
customer network. Source the Telnet connection from the virtual routers routing
instance associated with your local ACME customer network as shown on the lab
network diagram.


should establish successfully.

Step 5.15
command.

Question: Does the output display IPv6

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

NAT translations when testing the Telnet connection
from your local pod teams virtual router. However,
the remote student team within your pod should
see IPv6 translations when you test your Telnet
connection, and vice versa.
Step 5.16
terminate the Telnet session, then log out using the command.

Step 5.17
From your assigned SRX device, log out of your assigned device using the
command.

STOP
Tell your instructor that you have completed this lab.






Lab
Hub-and-Spoke IPsec VPNs (Detailed)
Overview
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 51
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 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

Lab 52 Hub-and-Spoke IPsec VPNs (Detailed) www.juniper.net
Step 1.3

Step 1.4
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 routing instance by pinging the address of the Internet interface that
is associated with your assigned SRX device (ge-0/0/3).

time. If they do not complete, contact the instructor
for assistance.
Step 1.5
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.



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
zone and assign the appropriate interfaces. You will then create policies to
allow traffic to use this zone.
Step 2.1
Configure the st0 interface with the IP address and network that is defined in the
following table for your assigned device. Ensure that the st0 interface can facilitate
multiple Internet key exchange (IKE) and IPsec security associations
establishments.
st0 Address Per Device
Assigned st0 Address

Device

Note
The network diagram for Lab 5 also shows
the necessary st0 address for your
assigned device.
Question: Why did you have to configure the st0

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

tunnel is point-to-multipoint from the hubs
perspective. Therefore, you must configure the st0
interface as a multipoint interface.
Step 2.2
Navigate to the hierarchy and add the loopback
interface to the zone. When you add the lo0 interface to this zone, allow
IKE as for this interface.

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 and add the st0 interface. Verify the recent changes to
both zones.

Step 2.4
Navigate to the hierarchy and create two policies.
The first policy should allow traffic from the zone to enter the zone and
should be named . The second policy should allow traffic to
enter the zone from the zone and should be named
. When you are finished, commit the configuration and exit to
operational mode.



Note
For the purposes of this lab, we want to
allow all traffic, from the Local-VR 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 hierarchy.
Begin by defining an IKE policy named . The spokes are configured to
use mode, and they also takes advantage of the predefined
. The spokes are also configured to use a ; the
key is . Configure your IKE policy to match the spokes settings. Review the
policy before continuing.


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 , , and
. 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
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.


Step 3.3
Navigate to the hierarchy. Begin by defining the policy
named . The spokes are configured to use the predefined
. You must configure your local policy to use the same
.

Step 3.4
Configure the VPN parameters. You should name the VPNs
, , and
where is your local SRX devices
host-name, and you must bind the st0.0 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 for
, for , and
for , which you defined in Step 3.3. After
specifying the gateways, indicate that this VPNs should use the IPsec policy named
, which was defined in Step 3.3. The last step for your VPNs is to
configure the 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.


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
hierarchy level and configure static routes for each spokes
hosts that are associated with your assigned SRX device. These host addresses are
defined on your network diagram in the table for your assigned
SRX device. Remember that you must use the interface address of the spokes st0
interface for the next hop of the static route. The addresses of the st0 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.

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.
Step 4.1
Enter configuration mode and begin by verifying that your IKE SAs has been
established by issuing the
command.
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 of the SAs?
Answer: The should be . If the is

displaying something different, please review your
IKE configuration and contact your instructor if
needed.
Step 4.2
Next, take a look at the IPsec SA by issuing the
command.


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.
Step 4.3
Review the current statistics for your IPsec VPN using the
command.
Question: Do you see any values?
Answer: No, the values should all be . If any values

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

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

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.

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 Junos device, the NHTB
route cannot be automatically obtained.
Step 4.7
Issue the command to
view the current next-hop tunnel bindings.
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 hierarchy
level and add a static next hop tunnel binding for spoke 3s st0 interface that is
associated with your assigned SRX device. When you are finished, commit the
configuration and exit to operational mode.

Step 4.9
Issue the to view the current
next hop tunnel bindings.

Question: Is the next-hop tunnel binding present for

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

tunnel binding.
Step 4.10
Examine the routing table for the routes that lead to the spokes host address that
are associated with your assigned SRX device.


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 st0.0 interface.
Step 4.11
Clear the IPsec statistics by issuing the
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.

Question: Did all three ping tests succeed?
Answer: Yes. All three ping tests are successful.
Step 4.12
Issue the command to verify that the
ping packets entered the IPsec tunnels.

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.
Step 4.13
Log out of your assigned SRX device to return it to the login prompt.






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 61
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
Step 1.3

Lab 62 Configuring Group VPNs (Detailed) www.juniper.net
Step 1.4
Navigate to the hierarchy. Change the loopback interface
address to correlate with the loopback address for your assigned device, as defined
in the network diagram.

Step 1.5
Navigate to the
hierarchy and add the loopback interface. After adding the interface, configure the
loopback interface to allow Internet key exchange (IKE) packets.

Step 1.6
Navigate to the hierarchy and create a policy to
allow traffic between the two interfaces configured under the zone. The
name for this policy should be . This policy should allow all
traffic to pass between these interfaces. When finished, navigate to the top of the
configuration hierarchy, and commit the configuration.

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 servers
configuration.
Note
The following configuration is the key
servers IKE policy configuration that
corresponds to your next step.

Step 2.1
Navigate to the hierarchy and
create an IKE policy named . Configure the policy to use mode to
use the predefined IKE proposal. Finally, specify the
to authenticate with the key server. The key is defined as .

Note
The following configuration snippet is one
of the key servers 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.

Step 2.2
Create a gateway named . 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 devices lo0.0
interface address as the local address that will be used to negotiate the IKE SA.

Note
The following configuration represents the
key servers 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.

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.

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
configuration?
Answer: The key server will be using the

unicast-push method to distribute the re-key
messages, because the
has been defined as .
Step 2.3
Navigate to the hierarchy and
create a VPN named . 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 lo0.0 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


Step 2.4
Navigate to the top of the configuration hierarchy, and commit the configuration.

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 hierarchy and create a security
policy named that allows traffic from the Juniper customer zone
to the zone. Use the existing address-book entry for your policys
match. The value of is the remainder of the VLAN ID
associated with your local Juniper customer network. Configure the
to match the address-book entry , where the
value of is the remainder of the VLAN ID associated with your remote team
members Juniper customer network. Indicate that matching traffic should be sent
to the IPsec VPN.


Question: Which policy in the policy chain will be

evaluated first?
Answer: The 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
zone without putting the traffic into the
VPN.
Step 3.2
Re-order the policies under the
hierarchy level using the
command. When finished, navigate to the top of the configuration hierarchy, and



Question: What will happen with traffic destined to

the remote Juniper sites 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.
STOP 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.
Step 4.1
Verify that the IKE SA has been correctly negotiated using the
command.
Question: Do you have an IKE SA?
Answer: Yes, at this point you should see an SA.
Question: What is the of the SA?

IKE configuration and contact your instructor, if
needed.
Step 4.2
Verify that you have a valid IPsec SA using the
command.

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

do not see an SA, please review your IPsec
configuration and contact your instructor for
assistance, if needed.
Step 4.3
Next, verify that you have a valid KEK SA using the
command.
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.
Step 4.4
Use the command to review the
policies being used on your local device that were sent down from the key server.

Step 4.5
Issue the
command to clear the group VPN statistics.

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

Step 4.7

Step 4.8
From the Telnet session established with the virtual router, verify that your local
Juniper customer device can ping the remote teams Juniper customer device. To
confirm reachability, ping the remote virtual routers attached to the remote peer
device. Source the ping from the virtual routers routing instance associated with
your local Juniper customer network. Refer to the lab network diagram if needed.
Ping this destination 5 times.



time. If they do not, review your SAs and contact
your instructor as needed to assist with
troubleshooting.
Step 4.9
Once you have verified that the pings complete, log out of the virtual router and
close out the session.

Step 4.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
command.

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

and 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.
Step 4.11
Exit configuration mode and log out of your assigned device using the
command.





Lab
Implementing Advanced IPsec VPN Solutions (Detailed)
Overview
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 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 (CLI) to load the baseline configuration.
Use the Junos CLI to configure the IPsec VPN parameters.
Use the Junos CLI to configure the GRE tunnel.
Use the Junos CLI to configure the OSPF protocol.
Verify that the expected traffic traverses the VPN using the OSPF route.
Use the Junos CLI to configure static NAT.
Monitor the effects of the configuration from the local device.

www.juniper.net Implementing Advanced IPsec VPN Solutions (Detailed) Lab 71
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
Step 1.3
Lab 72 Implementing Advanced IPsec VPN Solutions (Detailed) www.juniper.net


Step 1.4
Review the routing tables and determine which routes are used to reach the remote
device networks.



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 VPN. 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
zone and assign the appropriate interfaces. You will then create policies to allow
traffic to use the zone.
Step 2.1
Configure the st0 interface with the IP address and network that is defined in the
following table for your assigned device.
st0 Address Per Device
Assigned st0 Address

Device

Note
The network diagram also shows the
necessary st0 address for your assigned
device.
Step 2.2
Navigate to the hierarchy and create a policy called
. Configure the IKE policy to use main mode and take advantage of the
pre-defined . Configure your policy to use a
, the key should be defined as . Review the policy
before moving on.

Step 2.3
Configure the gateway properties that will be used to establish the IPsec VPN to the
remote site. You will define this as . 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 devices
external ge-0/0/3 interface. This IP address is defined under the key
word. Take a quick look at the gateway configuration before moving on.


Step 2.4
Navigate to the hierarchy and create a policy named
. Your IPsec policy should use the pre-defined
.

Step 2.5
Configure the VPN parameters. Navigate to the
hierarchy and bind the st0
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 named , which you defined
in Step 2.2. After specifying the gateway, indicate that this VPN will use the IPsec
policy named , which was defined in Step 2.3. The last step for your
VPN is to configure the 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.


Step 2.6
Navigate to the hierarchy and allow IKE as
for the ge-0/0/3 interface within the zone.

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 and add the st0 interface. Verify the recent changes to
both zones.



Step 2.8
Navigate to the hierarchy and create two policies.
The first policy will allow traffic from the Juniper customer zone to enter the
zone and will be named . The second policy will allow traffic to
enter the Juniper customer zone from the zone and will be named
. Once you have verified your configuration, commit these
changes and exit to operational mode.


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.
Step 2.9
Verify that the IKE SA has been correctly negotiated using the
command.


Question: Do you have an IKE SA?
Answer: Yes, at this point you should see an IKE SA.
Question: What is the of the SA?

IKE configuration and contact your instructor if
needed.
Step 2.10
Next, verify that you have a valid IPsec SA using the
command.

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

do not see an SA, please review your IPsec
assistance if needed.
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 sites gateway device. This tunnel will be sourced
from the interface and will terminate on the remote teams st0 interface. You
will add the GRE interface to your Juniper customer zone. You will then configure the
zone to recognize and allow the GRE traffic coming in from the IPsec VPN.
Step 3.1
Enter configuration mode and navigate to the
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 st0 interface address, and the destination address should be configured
as the remote teams st0 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.

Step 3.2
Navigate to the 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 statement that is currently
configured under the Juniper customer facing interface. Review the configuration
before moving on.


Step 3.3
Enable the zone to allow traffic coming into this zone. After
making your configuration changes, commit and exit configuration mode.

Step 3.4
Clear the statistics for the IPsec VPN by issuing the
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 command.
After pinging the remote GRE interface, review the IPsec statistics to verify the traffic
is traversing the tunnel.



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.

Step 4.1
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.

Step 4.2
Navigate to the
hierarchy level and configure the Juniper zone to allow OSPF
protocol on all interfaces in the zone. After making the appropriate changes, commit
and exit to operational mode.

Step 4.3
Begin verifying your configuration by looking at the OSPF neighborships.


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 sites 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.
Step 4.4
Review the OSPF routes installed in your routing table.

Question: Do you see the routes for the remote

networks?
Answer: Yes, you should see the OSPF routes for the
route for the remote teams Juniper customer
network and well as the remote Juniper customer
sites loopback address.

Step 4.5
Verify reachability to the remote Juniper customers site. You will use the ping utility
to send 5 ICMP requests to the Juniper customer devices 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 command.

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.
STOP
Do not proceed to the next lab part until directed by the instructor to do
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 teams 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
hierarchy level and configure your SRX device to allow all communication between
the zone and the zone.

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 teams external NAT address space. The external NAT
address space can be found on the network diagram.

Question: Which interface will be used for traffic
destined to the remote teams external NAT address
space?
Answer: The route table shows that the traffic

destined to the remote teams 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 hierarchy level. Configure a
rule set that only translates traffic that traverses the ge-0/0/3 interface.

Step 5.4
Configure a static NAT rule called 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.



Step 5.5
Test connectivity by pinging the remote teams Local-VR 5 times by issuing the
command,
where is if your assigned device is SRX1 and is if your assigned device is
SRX2.

Step 5.6
Examine the static NAT statistics in an effort to determine why the ping test failed by

Question: Were the ping packets translated by the

static NAT rule?
Answer: The field is

incrementing, which means the ping packets are
being translated by the static NAT rule.

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
command. Where is if your assigned device
is SRX1 and is if your assigned device is SRX2.

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.211.1.0/24 networks.
Most likely the problem resides with a lack of
routing information for the Internet router for the
previously mentioned networks. This scenario is
common, in that Internet service providers typically
will not route private IP address space.

Question: What can you do to overcome this
problem?
Answer: You can route the traffic through the IPsec

tunnel that is already in place. This method ensures
that the traffic is received by the remote teams
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 teams external NAT address space and use
the st0 interface as the next hop for the route. Remember that you can view the
remote teams external NAT address space by examining your Lab 7 network
diagram. When you are finished, commit the configuration.

Step 5.9
Clear the static NAT statistics by issuing the
command. Then, test connectivity by pinging
the remote teams Local-VR device 5 times by issuing the
command. Where is
if your assigned device is SRX1 and is if your assigned device is SRX2.



Step 5.10
Examine the static NAT statistics in an effort to determine why the ping test failed by

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

criteria to the zone or the st0 interface in the
static NAT rule set.

Step 5.11
Deactivate the OSPF configuration by issuing the
command. Then, change the static NAT rule set to use the st0 interface for the
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.
Step 5.12
Clear the current IPsec statistics by issuing the
command. Then, test connectivity by pinging the remote teams
Local-VR device 5 times by issuing the
command, where is if your
assigned device is SRX1 and is if your assigned device is SRX2.

Step 5.13
Examine the static NAT and IPsec statistics by issuing the
and the
commands.


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
Performing Security Troubleshooting Techniques (Detailed)
Overview
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 81
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
Step 1.3

Lab 82 Performing Security Troubleshooting Techniques (Detailed) www.juniper.net

Step 1.4
The following output was obtained from a previous IPsec lab. Examine this output
and answer the following question.



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.


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 1.6
hierarchy level.

Step 1.7
Configure the 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.

Step 1.8
Navigate to the
hierarchy level. Configure the rule set to accept connections
from the zone, and then configure a rule named to match
Telnet traffic on the destination address of the ge-0/0/3 interface address. Next,
configure the rule to use the NAT pool for
connections that match this rules criteria.


Step 1.9
Navigate to the hierarchy level. Store
the traceoptions in the file named , and configure the
option. Once you are finished, commit the configuration.

Note

the Internet service provider (ISP) virtual
router (VR) attached to your teams device.

Step 1.10
Open a separate Telnet session to the ISP VR attached to your teams device.
Consult the lab diagram if necessary for the ISPs IP address on the zone
subnet.
Step 1.11
Log in to the VR using the login information shown in the following table:


Step 1.12
From the Telnet session established with the virtual router, initiate a Telnet
connection to your assigned SRX devices ge-0/0/3 interface address. Source the
telnet connection from the virtual routers ISP routing instance
, where is the letter of your assigned pod. Refer
to the following table.
Student Device Instance


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 the
command.



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

Step 1.15
Clear the log file by issuing the
command.

Step 1.16
session again to the ge-0/0/3 interface address.

Step 1.17
command.

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
context, where is or
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
hierarchy level. Configure the zone with the address book entry of
for the interface address of the ISP virtual router.


Step 1.19
Navigate to the
hierarchy level. Configure the policy
to allow Telnet traffic from the address-book entry
you created to any destination address. When you are finished, navigate to the top
of the hierarchy level and commit the configuration.

Step 1.20

session again to the ge-0/0/3 interface address.


should be successful.
Step 1.21
From your assigned SRX device, remove the configured under the
hierarchy level. When you are finished, commit the
configuration.
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 srx-1s
perspective.
Step 2.1
Issue the and
commands.
Question: What is the status of the site-to-site IPsec

tunnel?
Answer: The site-to-site IPsec tunnel is established

to the other teams router.
Step 2.2
Note
Perform the following lab step only on

srx-2.
From the session established with srx-2, load the

from the /var/home/lab/ajsec/ directory. Commit the configuration and exit to
operational mode when complete.

Note
Perform the following lab steps only on

srx-1. Both lab teams should be working
together on srx-1 to resolve the issue.
Step 2.3
From the Telnet session established with srx-1, issue the
and
commands. Then issue the
and
commands.
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.


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 hierarchy level. Configure the
traceoptions to record any IKE related activity.
Step 2.6
Navigate to the hierarchy level. Configure the
traceoptions to record any SA related activity. Commit the configuration when you
are finished.


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
command. Examine the kmd log file by issuing the
command.
Note
The kmd log file might take a few minutes

to start filling up. If nothing is seen initially
when you issue the
command, wait a minute and issue the
command again.


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: , , and .
Step 2.8
Filter the kmd logs by issuing the command.



Question: Did the addition of the match option

help?
Answer: The answer is not forthcoming when

filtering on the keyword.
Step 2.9
Filter the kmd logs by issuing the
command.



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 hierarchy. Change the pre-shared key, located
within the policy to . Commit the configuration when
complete.


Step 2.11
Issue the and
commands.

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.
Step 2.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 command.







Detail Lab Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Detail Lab Guide

Caricato da

Copyright:

Formati disponibili

Advanced 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 Course Agenda vii

CLI and GUI Text

Style Description Usage Example

Input Text Versus Output Text

Style Description Usage Example

Text that you must enter.

Defined and Undefined Syntax Variables

Style Description Usage Example

Text where variable value is already

Education Services Offerings

www.juniper.net Additional Information ix

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 12 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: Configuring AppFW and AppID Features

Question: Based on the output, which types of

Answer: The SRX device is allowing all traffic from

Question: Will the policy block non-HTTP

Answer: No. The policy is only examining the

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

Question: Do you see any suitable application

Answer: Although many application signatures exist

Question: Could this application signature be useful

Answer: Yes. From the description and the

Answer: The answer to this question depends on

Answer: The answer depends on what is configured

Question: Is the AppFW rule set denying the FTP

Answer: The output suggests that the FTP session is

Lab 114 Implementing AppSecure (Detailed) www.juniper.net

Question: What information does the output

Answer: The output displays that the FTP session is

Answer: The message of

Part 3: Building Custom Application Signatures

www.juniper.net Implementing AppSecure (Detailed) Lab 117

Question: Does this nested application contain the

Answer: Yes. The

Lab 118 Implementing AppSecure (Detailed) www.juniper.net

Question: What must you change in the new

Answer: You must change the signature pattern in

www.juniper.net Implementing AppSecure (Detailed) Lab 119

Lab 120 Implementing AppSecure (Detailed) www.juniper.net

Question: Why was the rule not

Answer: The rule and the default