Advanced Junos Security

12.b

Student Guide-Volume 1

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 Student Guide. Aevision 12.b
Copyright© 2013 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a-March 2011
Revision 12.a-June 2012
Revision 12.b-June 2013
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.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 Junes 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

Chapter 1: Course Introduction .....................................................1-1

Chapter 2: AppSecure .............................................................2-1

AppSecure Over view ........................................................... 2-3
ApplD ....................................................................... 2-9
AppTrack.................................................................... 2-23
AppFW ....................................•................................ 2-31
AppDoS ..................................................................... 2-41
AppQoS ..................................................................... 2-57
Implementing AppSecure Lab................................................... 2-69

Chapter 3: Junos Layer 2 Packet Handling and Security Features .........................3-1

Transparent Mode Security...................................................... 3-3
Layer 2 Ethernet Switching ...................................................... 3-9
Implementing Layer 2 Security Lab .............................................. 3-18

Chapter 4: Virtualization ...........................................................4-1

Virtualization Overview ......................................................... 4-3
Routing Instances ............................................................. 4-7
Logical Systems .............................................................. 4-20
Filter-Based Forwarding ....................................................... 4-39
Implementing Junos Virtual Routing Lab ..........................................4-58

Chapter 5: Advanced NAT Concepts..................................................5-1

Operational Review ............................................................ 5-3
NAT: Beyond Layer 3 and Layer 4 Headers ........................................ 5-12
DNS Doctoring ............................................................... 5-29
1Pv6 NAT .................................................................... 5-35
Advanced NAT Scenarios ...................................................... 5-44
Advanced NAT Implementations Lab ............................................. 5-62

Chapter 6: IPsec Implementations...................................................6-1

Standard VPN Implementations Review ........................................... 6-3
Public Key Infrastructure ....................................................... 6-14
Hub-and-Spoke VPNs ......................................................... 6-33
Hub-and-Spoke IPsec VPNs Lab ................................................. 6-59

Acronym List .................................................................. ACR-1

www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview

This three-day course, which is designed to build off of the currentJunos Security (JSEC) offering,
delves deeper into Junes 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 Junes Security
course.
Describe the various forms of security supported by the Junes OS.
Implement features of the AppSecure suite, including App ID, AppFW, and App Track.
Configure custom application signatures.
Describe Junos security handling at Layer 2 versus Layer 3.
Implement Layer 2 transparent mode security features.
Demonstrate understanding of Logical Systems (LSYS).
Implement address books with dynamic addressing.
Compose security policies utilizing ALGs, custom applications, and dynamic
addressing for various scenarios.
Use Junos debugging tools to analyze traffic flows and identify traffic processing
patterns and problems.
Describe Junes routing instance types used for virtualization.
Implement virtual routing instances.
Describe and configure route sharing between routing instances using logical tunnel
interfaces.
Describe and implement static, source, destination, and dual NAT in complex LAN
environments.
Describe and implement variations of persistent NAT.
Describe and implement Carrier Grade NAT (CGN) solutions for 1Pv6 NAT, such as
NAT64, NAT46, and 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 Junes 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

Day1
Chapter 1: Course Introduction
Chapter 2: AppSecure
Implementing AppSecure Lab
Chapter 3: Junos Layer 2 Packet Handling and Security Features
Implementing Layer 2 Security Lab
Chapter 4: Virtualization
Implementing Junos Virtual Routing Lab

Day2
Chapter 5: Advanced NAT Concepts
Advanced NAT Implementations Lab
Chapter 6: IPsec Implementations
Hub-and-Spoke IPsec VPNs Lab

Day3
Chapter 7: Enterprise IPsec Technologies: Group and Dynamic VPNs
Configuring Group VPNs Lab
Chapter 8: IPsec VPN Case Studies and Solutions
Implementing Advanced IPsec VPN Solutions Lab
Chapter 9: Troubleshooting Junos Security
Performing Security Troubleshooting Techniques Lab
Appendix A: SRX Series Hardware and Interfaces

www.juniper.net Course Agenda • vii

Document Conventions

CLI and GUI Text

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

Style Description Usage Example

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

Courier New Console text:

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

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxpO,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.

CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config. ini in the Filename field.

Defined and Undefined Syntax Variables

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

Style Description Usage Example

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

assigned.
GUI Variable Click my-peers in the dialog.

CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.

viii • Document Conventions www.juniper.net

Additional Information

Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net;training/education/.

About This Publication

The Advanced Junos Security Student Guide was developed and tested using software Release
12.1X44-D10.4. Previous and later versions of software might behave differently so you should
always consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to [email protected].

Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http:j/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:j /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
JUnlE�f
Advanced Junos Security

Chapter 1: Course Introduction

Advanced Junes Security

Objectives

• After successfully completing this content, you will be

able to:
•Get to know one another
• Identify the objectives. prerequisites, facilities, and
materials used during this course
• Identify additional Education Services courses at
Juniper Networks
• Describe the Juniper Networks Certification Program

We Will Discuss:
Objectives and course content information;
Additional Juniper Networks, Inc. courses; and
The Juniper Networks Certification Program.

Chapter 1-2 • Course Introduction www.juniper.net

Advanced Junos Security

Introductions

• Before we get started ...

• What is your name?
• Where do you work?
• What is your primary role in your
organization?
• What kind of network experience
do you have?
• Are you certified on Juniper Networks?
• What is the most important thing for
you to learn in this training session?

Introductions
The slide asks several questions for you to answer during class introductions.

www.juniper.net Course Introduction • Chapter 1-3

Advanced Junos Security

Course Contents
• Contents:
• Chapter 1: Course Introduction
• Chapter 2: AppSecure
• Chapter 3: Junos Layer 2 Packet Handling and Security
Features
• Chapter 4: Virtualization
• Chapter 5: Advanced NAT Concepts
• Chapter 6: IPsec Implementations
• Chapter 7: Enterprise IPsec Technologies: Group and
Dynamic VPNs
• Chapter 8: IPsec VPN Case Studies and Solutions
• Chapter 9: Troubleshooting Junos Security
• Appendix A: SRX Series Hardware and Interfaces

Course Contents
The slide lists the topics we discuss in this course.

Chapter 1-4 • Course Introduction www.juniper.net

Advanced Junos Security

Prerequisites
• The prerequisites for this course are the following:
• Basic networking knowledge
• Understanding of the Open Systems Interconnection (OSI)
reference model and the TCP/IP protocol suite
• Experience with the Junos operating system, including
device management, routing, security, and policy through:
• Attending the Juniper Security (JSEC). Introduction to the Junos
Operating System ( IJ OS). and Junos Routing EssentiaIs (JR E)
courses. or
• Working with devices running tl1e J unos OS in a networking and
security environment

Prerequisites
The slide lists the prerequisites for this course.

www.juniper.net Course Introduction • Chapter 1-5

Advanced Junos Security

Course Administration

• The basics:
• Sign-in sheet
• Schedule
• Class times
• Breaks
• Lunch
• Break and restroom facilities
• Fire and safety procedures
• Communications
• Telephones and wireless devices
• Internet access

��i!:::f:;::..':'!'��?:':�'\:'1':C ,,}>';Jun11Ser WorldwideEducationServices ,.,... ,,nopernel I 6

�0::� -�� - - �

General Course Administration

The slide documents general aspects of classroom administration.

Chapter 1-6 • Course Introduction www.juniper.net

Advanced Junos Security

Education Materials

• Available materials for classroom-based

and instructor-led online classes:
• Lecture material
• Lab guide
• Lab equipment
• Self-paced online courses also available
• http//www.juniper.net;training/technical_education/

Training and Study Materials

The slide describes Education Services materials that are available for reference both in the
classroom and online.

www.juniper.net Course Introduction • Chapter 1-7

Advanced Junos Security

Additional Resources
• For those who want more:
• Juniper Networks Technical Assistance Center (JTAC)
• http:j /www.juniper.net/supportjrequesting-support.html
• Juniper Networks books
• http:j/www.juniper.net;training/jnbooks/
• Hardware and software technical
documentation
• Online: http:j /www.juniper.net/techpubs/
• Image files for offline viewing:
http:j/www.juniper.net;techpubs/resources/cdrom.html
• Certification resources
• http:j/www.juniper.net;training/certification/resources.htrnl

Additional Resources
The slide provides links to additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.

Chapter 1-8 • Course Introduction www.juniper.net

Advanced Junos Security

Satisfaction Feedback

Class
Feed b a·:::1-

==

• To receive your certificate, you must complete the

survey
• Either you will receive a survey to complete at the end of
class. or we will e-mail it to you within two weeks
• Completed surveys help us serve you better.

Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and
feedback. Depending on the class you are taking, please complete the survey at the end of the class,
or be sure to look for an e-mail about two weeks from class completion that directs you to complete
an online survey form. (Be sure to provide us with your current e-mail address.)

Submitting your feedback entitles you to a certificate of class completion. We thank you in advance
for taking the time to help us improve our educational offerings.

www.juniper.net Course Introduction • Chapter 1-9

Advanced Junos Security

Juniper Networks Education Services

Curriculum

• Formats:
• Classroom-based instructor-led technical courses
• Online instructor-led technical courses
• Hardware installation elearning courses as well as technical
elearning courses
• Courses:
• http:j /www.juniper.neVtraining/technical_education/

-�: J�!P� �orldwideEducationServices 110

" �
wwwiunipernet

Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to
deploy and maintain cost-effective, high-performance networks for both enterprise and service
provider environments. We have expert training staff with deep technical and industry knowledge,
providing you with instructor-led hands-on courses in the classroom and online, as well as
convenient, self-paced elearning courses.

Courses
You can access the latest Education Services offerings covering a wide range of platforms at
http://www.juniper.net;training/technical_education/.

Chapter 1-10 • Course Introduction www.juniper.net

Advanced Junos Security

Juniper Networks Certification Program

• Why earn a Juniper Networks certification?

• Juniper Networks certification makes you stand out
• Unleash your creativity across the entire network
• Set yourself apart from your peers
• Capitalize on the promise of the New Network
• Develop and deploy the services you need CERTIFICATION
PROGRAM
• Lead the way and increase your value
• Unique benefits for certified individuals

- \h/o��ideEducalionServices "'""'Jun,pe,net 1 11

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks
technologies.

www.juniper.net Course Introduction • Chapter 1-11

Advanced Junos Security

Juniper Networks Certification Path

'
' " . ti 1,: ""
, �"' ft.i ,; �·' ,• r,if"';,. �"

Expert E'.evel1(:.ll'fCIEl.
'!..o

,· Cfffflf'IED

� z ' .;- ;"' ' Cf -ec, ',,"';.;:.:·�. �

EX�7

,• .� :-: =
.
,S ,, >s- 'i�:f
k • f Y�- ··,;.1. » <

't 'J. "- :,·�,;.

i,,)('C<, �

· Specialist Level (JNCIS)'". :: "

• "' ' �
' "' , <->

Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of platform-specific, multitiered tracks
that enable participants to demonstrate competence with Juniper Networks technology through a
combination of written proficiency exams and hands-on configuration and troubleshooting exams.
Successful candidates demonstrate a thorough understanding of Internet and security technologies
and Juniper Networks platform configuration and troubleshooting skills.
The JNCP offers the following features:
Multiple tracks;
Multiple certification levels;
Written proficiency exams; and
Hands-on configuration and troubleshooting exams.
Each JNCP track has one to four certification levels-Associate-level, Specialist-level,
Professional-level, and Expert-level. The Associate-level, Specialist-level, and Professional-level
exams are computer-based exams composed of multiple choice questions administered at Prometric
testing centers worldwide.
Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks
testing centers. Please visit the JNCP website at http://www.juniper.neVcertification for detailed
exam information, exam pricing, and exam registration.

Chapter 1-12 • Course Introduction www.juniper.net

Advanced Junos Security

Cert.fication Preparation

• Training and study resources:

• Juniper Networks Certification Program website:
www.juniper.net/certification
• Education Services training classes:
www.juniper.net;training
• Juniper Networks documentation and white papers:
www.juniper.net;techpubs
• Community:
• J-Net:
http://forums.juniper.net/t5/Training-Certification-and/
bd-p/Training_and_Certification
• Twitter: @JuniperCertify
-Q�rJ��-Worl�deEducatlonServices "'""'"' Jun,pernet 113

Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.

www.juniper.net Course Introduction • Chapter 1-13

Advanced Junos Security

Find Us Online

JnetJ http:j/www.juniper.net/jnet

http:j/www.juniper.net/facebook

m;iJ http:j/www.juniper.net/youtube

http:j/www.juniper.net/twitter

Find Us Online
The slide lists some online resources to learn and share information about Juniper Networks.

Chapter 1-14 • Course Introduction www.juniper.net

Advanced Junos Security

Questions

Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice
them now so that your instructor can best address your needs during class.

www.juniper.net Course Introduction • Chapter 1-15

Advanced Junes Security

Chapter 1-16 • Course Introduction www.juniper.net

Advanced Junos Security

Chapter 2: AppSecure
Advanced Junos Security

Objectives
• After successfully completing this content, you will be
able to:
• Describe the functionality of the AppSecure suite
• Understand how the different AppSecure modules function
• Monitor the operation of the different AppSecure modules

-��W�rl�deEducationServices www1un,pernet 1 2

We Will Discuss:
The functionality of the AppSecure suite;
How the different AppSecure modules function; and
How to monitor the operation of the different AppSecure modules.

Chapter 2-2 • AppSecure www.juniper.net

Advanced Junos Security

Agenda:AppSecure
� AppSecure Overview
• ApplD
• AppTrack
• AppFW
• AppDoS
• APPQoS

AppSecure Overview
The slides lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net AppSecure • Chapter 2-3

Advanced Junos Security

What Is AppSecure?

• The AppSecure suite

• Next-generation security capabilities
• Employs advanced application identification to deliver
greater visibility, control, and protection over the network
• Works in conjunction with the SRX IPS
• Provides a deep understanding of application behaviors and
vulnerabilities to prevent application-borne threats

What Is the AppSecure Suite?

As network infrastructure and the threats targeting that infrastructure continue to evolve, so, too,
must the network security solutions adopted to protect organizations. At the same time, the latest
generation of Web-based applications and the proliferation of mobile devices provide an increasingly
challenging task for network administrators to effectively manage traffic flows and access to data
while delivering the right mix of security and network services. In the past, network administrators
would simply buy a new appliance to overcome a security or network issue. However, that approach
leads to greater network complexity, excessive management overhead, and poor overall
performance.
Today's network security solutions must not only have the right architecture to deliver the
appropriate mix of performance and scale in this evolving network environment, but must also
deliver the right security services to give administrators visibility and control over the types of
applications now traversing their networks. Juniper Networks' AppSecure is a suite of
application-aware security services for the Juniper Networks' SRX Series Services Gateways that
classify traffic flows, bringing greater visibility, enforcement , control, and protection to network
security. AppSecure uses a sophisticated classification engine to accurately identify applications
regardless of port or protocol, including nested applications that reside within trusted network
services.

Continued on the next page.

Chapter 2-4 • AppSecure www.juniper.net

Advanced Junos Security
What Is the AppSecure Suite? (contd.)
The result is a powerful tool that helps bring context and clarity to the setting and enforcement of
security policies, provides protection against common evasion techniques, and helps stop modern
malware attacks, all while delivering the industry's highest performance and scale. AppSecure gives
security administrators the context to regain control of their network traffic, set and enforce policies
based on accurate information, and deliver the performance and scale required to address business
needs.

www.juniper.net AppSecure • Chapter 2-5

Advanced Junos Security

The AppSecure Modules

• Application intelligence from user to data center
• Juniper security lab provides over 900 application

--
signatures

Identifies Understands Protects Prioritizes

applications security risks applications from important
bot attacks applications

Used byother Addresses new Allows le@timate Rate-limits

AppSecure user behaviols policies user traffic less important
modules applications

'' .

The AppSecure Modules

The AppSecure suite contains the following five modules, which help SRX devices secure a network:
App/0: Identifies the applications that are present in traffic and passes this information
on to other AppSecure modules and to Intrusion Detection and Prevention (/DP);
App Track: Provides visibility and volumetric reporting of application usage on the
network;
AppFW: Provides enforcement with the ability to block traffic based on specific
applications;
AppDoS: Provides protection for distributed denial of service (DDoS) attacks that target
specific applications; and
AppQoS: Provides control by allowing prioritization, marking, and rate limiting of
application traffic.
Combined with the rich portfolio of security features on the SRX devices, the modules of the
AppSecure suite provides much-needed protection from application-borne threats.

Chapter 2-6 • AppSecure www.juniper.net

Advanced Junos Security

SRX Firewall Flow Processing

AppSecureoccurs
within Services

Ingress
packet

l l
�-tt'irui:ier?.WorldwideEducallonServices
=� . v
www,,n.pe,net I 7

Location of AppSecure in the Flow Module

The slide shows the logical packet flow used by security platforms running the Junos operating
system. As noted on the slide, the modules of the AppSecure suite reside in the Services section.
This location is particularly important when considering how to write security policies. For example, if
the SRX device is performing destination Network Address Translation (NAT) for a backend server,
and you employ AppDoS in an IDP policy to protect that backend server, you must use the translated
destination NAT address if you specify a destination address as match criteria in the IDP policy.
Also, if it is possible to protect the network using a section of the flow module that is located in front
of the Services section, we recommend you do so. An increased amount of processing power is
required for each malicious packet that reaches the Services section. Ultimately, if the malicious
traffic can be discarded as it enters the flow module, or even before that point through the use of
firewall filters, the SRX device has more free resources with which to perform other work. To this end,
we recommend that you protect the network through the combination of security features that the
SRX devices have at their disposal. For example, you can use a firewall filter to discard traffic from
known malicious IP addresses, and then you can employ security screens to block TCP and UDP
flood attacks, and finally you can employ AppDoS, or another AppSecure module, to protect your
network from any malicious traffic that passes through the other security features.

www.juniper.net AppSecure • Chapter 2- 7

Advanced Junes Security

Licensing
• Licensing is required for the AppSecure suite
• ApplD is included in the standalone IDP license
• IDP usesApplD to identify applications in traffic flows
• OtherAppSecure modules require additional licensing
• AppSecure licensing includes IDP license
• 1-year or 3-year licensing available
• One license is required for each node in a chassis cluster

AppSecure Licensing
To use the features in the AppSecure suite, you must install a valid AppSecure license on the
SRX device. AppSecure licenses for branch and high-end SRX devices are available in 1-year and
3-year increments.
When two SRX devices are combined in a chassis cluster, and AppSecure is needed, you must install
a separate license for each member of the cluster. This method ensures that if the chassis cluster is
split, through intentional or unintentional means, the primary node of the cluster is able to continue
to use the AppSecure features.
To the benefit of intrusion prevention system (IPS) administrators, the AppSecure license comes
bundled with the IDP license. This bundling of features is necessary because the AppDoS module
requires the IDP engine to function correctly. However, it is important to keep in mind that the
standalone IDP license does not come with the AppSecure license.

Chapter 2-8 • AppSecure www.juniper.net

Advanced Junos Security

Agenda:AppSecure
• AppSecure Overview
�App ID
• AppTrack
•AppFW
• AppDoS
• AppQoS

ApplD
The slide highlights the topic we discuss next.

www.juniper.net AppSecure • Chapter 2-9

Advanced Junos Security

ApplD Defined
• How does ApplD work?
• Provides application visibility regardless of Transport Layer
protocol and associated ports
• Applies protocol decoding to identify nested applications
• Does not inspect entire session
• Is used by other AppSecure modules and IDP to help identify
applications
• Not explicitly applied in tl1e configuration
• Uses application signatures to identify applications
• Identifies applications within the first few packets of the session
• Uses heuristics to improve the accuracy for detection of
encrypted P2P applications

How Does ApplD Help Secure a Network?

ApplD is a module in the AppSecure suite that is enabled by default and allows the SRX device to
inspect and identify an application no matter which TCP or UDP port is in use. For example, Hypertext
Transfer Protocol (HTIP) typically runs over TCP port 80. However, you can configure end devices to
listen for HTIP on other ports. A user with nefarious intentions might use this knowledge to their
advantage to trick a security device that is only performing stateful firewall inspection on the traffic.
Using nonstandard ports in that manner does not pose a problem for ApplD, because it is able to
look deep into the payload of the packet to determine what the Application Layer contains.
The ApplD engine can also detect applications that are nested inside another Layer 7 application.
For example, it is commonplace today to have an application nested in HTIP. Prime examples of this
trend are nested applications like Facebook, Gmail, and YouTube. Any user can simply use a Web
browser to access any of these services, and classifying all HTIP traffic together and treating it the
same is not helpful to securing, or increasing the productivity, of an enterprise.
The ApplD module is used by the other AppSecure modules and IDP. This allows them to properly
identify the application that a session is using. Once the application is identified, further action can
be taken. To this end, no explicit configuration is necessary to ensure that the other AppSecure
modules use the ApplD module for application identification. When an AppSecure module is
configured, such as AppFW, the Junos OS automatically uses the ApplD module.
Continued on the next page.

Chapter 2-10 • AppSecure www.juniper.net

Advanced Junos Security
How Does ApplD Help Secure a Network? (contd.)
To inspect the Application Layer, ApplD does not need to inspect the entire session, only the first few
packets of the session that contain application data. However, this typically does not occur within the
first few packets of the session. The reason behind this behavior is that the first few packets of a
session typically do not contain any application data. For example, before a user is able to open a
Web page over HTTP, the TCP three-way handshake must occur between end hosts. During the TCP
three-way handshake, information pointing to which application will be used is not present. Packets
with real payload information must be present for the ApplD engine to identify the application.
However, allowing the first few packets through the SRX device might be against an organization's
corporate security policy. So it is important to be aware of this behavior before you employ ApplD, or
any of the modules of the AppSecure suite for that matter, to protect a network.
Peer-to-peer applications, such as Skype, contain encrypted data packets. These encrypted data
packets are not identifiable using the current application signatures of ApplD, which are based on
regular expression patterns. However, the SRX device can use heuristics to detect such traffic and
improve the detection rate of said traffic. To enable the detection of encrypted peer-to-peer
applications, use the set services application-identification
enable-heuristics command. However, even with the help of heuristics to help identify
encrypted peer-to-peer traffic, a situation might occur in which the encrypted traffic is unidentifiable.
To help in situations like this, you can use the application junos :unspecified-encrypted to
classify, and act upon, the unidentifiable encrypted traffic.

www.juniper.net AppSecure • Chapter 2-11

Advanced Junos Security

Applications and Nested Applications

Layer 2: Ethernet
Layer 3: 1Pv4. 1Pv6
Layer 4: TCP, UDP
Layer 7: HTTP
Layer 7 nested application
(e.g., Facebook, Pandora)

Visualizing Nested Applications

When the Internet was in its infancy and a user opened a Web page, the user simply received HTIP
traffic. This is what they expected. There was no need to nest an application inside of another
application. However, as the Internet grew and matured, the use of HTIP, and other applications,
required the use of nested applications. Now, users are accustomed to using a Web browser for
other applications, such as Facebook and Pandora, which in the past might have been an
application that was installed directly on their personal computers.
The slide gives a visual representation of what a nested application is and how it fits into the rest of
the Open Systems Interconnection (OSI) model. As data is transferred from one end host to another,
it is encapsulated from one layer into another. In essence. each layer is nested inside the previous
layer.

Chapter 2-12 • AppSecure www.juniper.net

Advanced Junos Security

ApplD Results

Flow Processing
Ingress

-1jI:Jii1 Pffiw:�dwideEducalionServices wwwjun,pernet I 13

Visualizing the How Other AppSecure Modules Use ApplD

As stated earlier, the ApplD engine detects the application, and nested applications, and pushes
these results to the other AppSecure modules and IDP. Then, each AppSecure module that is
configured acts accordingly. This procedure results in a network that is more secure against
application-borne threats.
When the ApplD results are passed to the individual AppSecure modules, each module can act on
the same traffic flow. For example, AppTrack can track the statistics of a traffic flow, then AppFW can
ensure that the correct application layer traffic is present, then the AppCoS module can rate limit the
traffic, and, finally, the AppDoS can ensure that the traffic is not part of a malicious application DDoS
attack.

www.juniper.net AppSecure • Chapter 2-13

Advanced Junes Security

Application System Cache

• What is the ASC?

• Database of mappings of application type and nested
application type to:
• Destination IP address
• Destination port
• Protocol type
• Service
• Client-to-server and server-to-client signature match must be
present
• Expedites future App ID matching
• ASC only refreshed when TCP or UDP triggers a cache
lookup

Speeding Up the Application Identification Process

It takes time, and processing power, to look deep into a session to determine which application, and
possibly nested application, is present. This process is expedited through the use of the application
system cache (ASC). The ASC is a database that stores mappings between an application type and
the corresponding destination IP address, destination port, protocol type, and service. Once an
application is identified, its information is saved in the ASC so that only one pattern match is
required for an application running on a particular system.
The ASC only saves a mapping if the matched signature contains both client-to-server and
server-to-client patterns. This process helps protect the system from hackers who might send
malicious packets through a legitimate server port so that it is interpreted as a different application.
Refreshing a single entry in the ASC is not necessarily a process-intensive procedure; however,
excessive refreshing of all the ASC entries can cause service degradation. To eliminate this type of
service degradation, entries in the ASC are only refreshed when TCP or UDP traffic triggers a cache
lookup. Without a cache lookup, the entries in the ASC remain unchanged.
At times it might be necessary to disable the ASC for applications or nested applications if caching
these entries is undesirable. You can disable the caching of applications and nested applications by
using the set services application-identification
no-application-system-cache and set services application-identification
nested-application-settings no-application-system-cache commands.

Chapter 2-14 • AppSecure www.juniper.net

Advanced Junos Security

Inspecting the Application System Cache

• Entries in the ASC

user@srx> show services application-identification application-system-cache
Application System Cache Configurations:
application-cache: on Confi gura ble options
nested-application-cache: on
cache-unknown-result: on
cache-entrv-timeout: 3600 seconds
pie: 0/0
!Logical system name: 0 !••����--1 Default logical system
����������
IP address: 8.8.8.8 Port: 53 Protocol: UDP
Application: DNS Encrypted: No

Logical system name: 0

Nested application
IP address: 74.125.224.86 Port: 443 Protocol: TCP
! Application: SSL:GMAIL! Encrypted: Yes

Examining the Contents of the ASC

As depicted on the slide, the first item displayed is the list of ASC configuration parameters. This area
of the output lets you know whether the ASC is storing the results for applications, nested
applications, and unknown applications. Next, the current configured ASC entry timeout is shown,
which defaults to 3600 seconds, or one hour.
After the configuration parameters, the output displays the ASC entries, which are grouped together
by the PIC that the server-to-client communication ingresses. Then, the output displays the name of
the logical system (LSYS) that received the ASC entry. In the output on the slide the LSYS is listed as
0; this value means that the default LSYS collected the ASC entry.
Next, the server information is listed: IP address, port, protocol, and whether the communication is
encrypted. Finally, at the end of each entry, the identified application is listed. Note that if a nested
application is present, it is delimited by a colon. In the example on the slide, Secure Sockets Layer
(SSL) is the application and Gmail is the nested application in use.

www.juniper.net AppSecure • Chapter 2-15

Advanced Junos Security

Preprocessing (1 of 4)

• What is preprocessing?
• The serialization, reordering, and reassembly of application
data
• Why is preprocessing necessary?
• Preprocessing must occur before App ID pattern matching
can happen
• Necessary for other AppSecure modules
• Without preprocessing, certain attacks might go
unrecognized

What Is Preprocessing?
Preprocessing is the method of receiving all the fragments of a packet and putting those packet
fragments in the correct order.

The Necessity of Preprocessing

Preprocessing can be a process-intensive procedure. However, it is absolutely necessary to correctly
employ pattern matching for ApplD and the other AppSecure modules. Without preprocessing,
certain attacks might go unrecognized. We discuss in the next couple of slides how missed pattern
matching can occur if preprocessing is not employed.

Chapter 2-16 • AppSecure www.juniper.net

Advanced Junos Security

Preprocessing (2 of 4)

• Packets can arrive fragmented

• Pattern matching HTTP in a GET request
IP Packet 1 IP Packet 2 IP Packet 3 IP Packet 3

GET /index.html HT TP/1.0

Reassembled Packet

[ \
GET /index.html HTIP/1.0

When Fragmented Packets Arrive

As shown in the slide, a packet might arrive fragmented. In this example, pattern matching is
occurring on HTTP in the GET request. However, the HTTP context is split between packet 3 and
packet 4. To correctly match on the HTTP context, the security device must receive all of the
fragments, reorder them, and reassemble the original packet.
Once the security device re-forms the original packet, it can properly match on the HTTP context. If
this preprocessing does not occur the pattern match might not occur, and an attack could pass
through the security device undetected.

www.juniper.net AppSecure • Chapter 2-17

Advanced Junos Security

Preprocessing (3 of 4)

• Packets can arrive fragmented and out of order

• Pattern matching HTTP in a GET request

IP Packet 2 IP Packet 3 IP Packet 1 IP Packet 3

GJ§ I
1
I
/index.html
\
�P;1.0
1
I
Reassembled Packet

' '
GET /index.html HTTP/1.0

Reordering Packet Fragments

Not only can packets arrive fragmented, but they can arrive out of order. Part of the preprocessing
method is to reorder and reassemble these packet fragments. Once reordering and reassembly of
the packet fragments occurs, the correct pattern matching can occur.
As with the previous slide, if this reordering and reassembly did not occur, the pattern match of the
HTIP context would have been missed. Missing the pattern match in this manner might result in an
attack that could pass through the security device undetected.

Chapter 2-18 • AppSecure www.juniper.net

Advanced Junos Security

Preprocessing (4 of 4)

• What if two fragments or segments are sent with

different payloads?
• Pattern matching HTTP in a GET request
Segment3

Segmentl Segment2 ,cS_, Segment4

.....-------.��
/index.html

Evasion Techniques with Duplicate Packets or Segments

An attacker might attempt to send malicious traffic that contains overlapping, underlapping, or
duplicate packets or segments. To properly detect such attacks, the packet must be received and
re-formed, just like the examples given in the previous slides. Once reordering and reassembly is
complete, the SRX device can determine which packet or segment does not belong.

www.juniper.net AppSecure • Chapter 2-19

Advanced Junos Security

Application Signatures
• Two available sources based on contexts, pattern
matching, and direction:
• Predefined database
• Custom user-defined signatures:
• Configured under the [edit services application­
identi fie ation] hierarchy level
• Can be defined for applications and nested applications

Application Signatures
Currently the ApplD database contains over 900 applications that you can use to help thwart
attempts to compromise your network. These applications contain application signatures that are
based on contexts, pattern matching, and direction.
You can use application signatures for applications and nested applications. Application signatures
for applications are used to match Layer 7 protocols, such as FTP or HTTP, whereas application
signatures for nested applications match nested applications that reside inside of the Layer 7
protocols. These application signatures are based on pattern matching, such as deterministic finite
automation (DFA) and regular expression (regex) matching. Also, the direction of the matching,
client-to-server, server-to-client, or both, as well as other criteria, is important in the application
signature.
Application signatures come from two sources. You can acquire a database of predefined application
signatures from Juniper Networks, which you download and install through the Junos OS CU.
Alternatively, you can create your own custom application signatures for applications and nested
applications. This flexibility allows you to fine-tune application signatures to fit your business needs
no matter what they might be.
When creating custom application signatures, we recommend that you examine the predefined
application signatures. Viewing the predefined application signatures can give you a baseline on how
to configure your custom application signatures.
To examine further information on application signatures, visit the Juniper Networks Security
Intelligence website at http:j/www.juniper.net/us/en/security/.

Chapter 2-20 • AppSecure www.juniper.net

Advanced Junos Security

Examining Application Signatures

• Inspecting an application signature through the CLI

•show services application-identification
application summary
• State. ID. and order
•show services application-identification
application detail
• Application characteristics
• Layer 7 protocol
• Context matching
• Pattern matching
• Direction-client-to-server. server-to-client. or both

Taking a Closer Look at Application Signatures

Whether you need to examine the database of application signatures to help you create your own
custom application signatures, or you want to better understand the inner workings of a predefined
signature, there are commands in the Junos OS CU that can help.
The show services application-identification application sUllllllarycommand
displays the expansive list of applications and nested applications that the App ID database contains.
It also displays which applications are currently disabled.
user@SRX> show services application-identification application SUllllllary
Application(s): 182
Nested Application(s): 749
Applications Disabled ID Order
junos:KIK No 1123 33560
junos:FRING-SSL No 1120 33484
junos:FRING-HTTP No 1119 33483
junos:INTERNET-ARCHIVE-UPLOAD No 1118 33558
junos:ENGAGEMEDIA-STREAM No 1117 33556

Continued on the next page.

www.juniper.net AppSecure • Chapter 2-21

Advanced Junos Security
Taking a Closer Look at Application Signatures (contd.)
Theshow services application-identification application detail command
displays the details of the applications and nested applications that the AppID database contains.
The information that this command lists contains specifics on application characteristics, Layer 7
protocol, context matching, pattern matching, and direction of the traffic flow.
user@SRX> show services application-identification application detail
junos:YOUTUBE-COMMENT
Application Name: junos:YOUTUBE-COMMENT
Application type: YOUTUBE-COMMENT
Description: This signature detects YouTube users posting comments about videos.
Application ID: 833
Disabled: No
Number of Parent Group(s): 1
Application Groups:
junos:multimedia:web-based
Application Tags:
characteristic Loss of Productivity
characteristic Prone to Misuse
characteristic Bandwidth Consumer
characteristic Can Leak Information
risk 4
subcategory Web-Based
category Multimedia
Signature NestedApplication:YOUTUBE-COMMENT
Layer-7 Protocol: HTTP
Chain Order: Yes
Maximum Transactions: 15
Order: 32815
Member(s): 2
Member O
Context: http-header-host
Pattern: (.*\.)?youtube\.com
Direction: CTS
Member 1
Context: http-url-parsed-param-parsed
Pattern: /\[comment servlet\)\?.*
Direction: CTS

Chapter 2-22 • AppSecure www.juniper.net

Advanced Junos Security

Agenda:AppSecure
•AppSecure Overview
•ApplD
�AppTrack
•AppFW
•AppDoS
•AppQoS

AppTrack
The slide highlights the topic we discuss next.

www.juniper.net AppSecure • Chapter 2-23

Advanced Junos Security

AppTrack Defined
• What is AppTrack?
• An application tracking tool to analyze application usages
• Uses the ApplD module to gain insight into applications
• Provides statistics for traffic flows
• Byte. packet. and duration statistics are collected
• Statistics are reported at session close
• Incomplete or half-open connections are not reported
• Statistics can be collected by a syslog server like STRM
• Uses standard syslog messages-syslog or structured syslog
• Support for user names and roles with UAC enforcement
• Support for App Track in LSYS
• Can be used to create better security policies

Understanding AppTrack
AppTrack is an application tracking tool that provides statistics for analyzing bandwidth usage of your
network. When enabled, AppTrack collects byte, packet, and duration statistics for application flows
in the specified zone. By default, when each session closes, App Track generates a message that
provides the byte and packet counts and duration of the session, and sends it to the host device.
AppTrack is essentially a feature that monitors bandwidth and does not report incomplete, or
half-open, connections.
Although the AppTrack logs can be stored locally on the SRX device (locally logging is only supported
on branch devices), the true power of AppTrack is having a syslog server like the Security Threat
Response Manager (STRM) retrieve the information. Using the STRM to retrieve the data provides
flow-based application visibility that can be helpful in understanding the application traffic in your
network.
AppTrack messages are similar to session logs and use syslog or structured syslog formats. The
message also includes an application field for the session. If AppTrack identifies a custom-defined
application and returns an appropriate name, the custom application name is included in the log
message. If the application identification process fails or has not yet completed when an update
message is triggered, the message specifies none in the application field.
You can configure AppTrack inside of any logical system (LSYS), and the values in the AppTrack
configuration of any LSYS will only apply to that LSYS. When sending syslog information to an
external device, such as the STRM, the LSYS-ID is used to identify one LSYS from another.
Continued on the next page.

Chapter 2-24 • AppSecure www.juniper.net

Advanced Junos Security
Understanding AppTrack (contd.)
User identity details, such as username and user role, have been added to the AppTrack session
create, session close, and volume update logs. T hese fields contain the username and role
associated with the policy match. The logging of username and roles is enabled only for security
policies that provide Unified Access Control (UAC) enforcement. For security policies without UAC
enforcement, the username and user role fields are displayed as N/A. The user role field in the log
will also contain N/A if the match criteria and the username field in the log contains unauthenticated
a user or unknown user.
The statistical records that AppTrack reports can help an administrator develop better security
policies. For example, if, after implementing AppTrack, a network administrator discovers that a large
amount of bandwidth in the network is being used by employees watching YouTube videos, the
administrator can adjust the security policies on the SRX device to limit or block that traffic. This
action serves two purposes: first, it allows more available bandwidth in the network. Second, the
employees who have been watching YouTube videos can get back to work.

www.juniper.net AppSecure • Chapter 2-25

Advanced Junos Security

Configuring AppTrack
• Enable AppTrack for the security zone
[edit security zones]
user@SRX# set security-zone trust application-tracking

• Configure the remote syslog device to receive

AppTrack messages
[edit security log] ..-..������....I.--��������--.
user@SRX# set format sd-syslog Configured under
[edit security 1

[edit security log]

user@SRX# set stream stream-data-name host 5.0.0.1

[edit security log]

user@SRX# set source-address 5.0.0.254

-QIPef.
. "'""""��
........... Worldwide
-�- � Education
Services """)Un;pernet I 26

Basic AppTrack Configuration

To simply configure AppTrack, all you must do is enable it under the desired security zone. This
configuration allows the SRX device to collect and log statistics locally. However, to truly leverage the
power of App Track, you should configure the SRX device to send the logging information to a remote
syslog server that supports AppTrack reporting, such as the STRM.

Sending the AppTrack Logs to a Remote Syslog Server

When configuring the remote syslog server, under the [edit security log] hierarchy level, be
sure to use the structured syslog format with the sd- sys log command shown on the slide. This
allows the SRX device to send messages to the remote syslog server in a format that the syslog
server understands. Then, you must configure the remote host address and the local address to be
used by the SRX device as shown on the slide.
On the branch devices, AppTrack can log its information in a local syslog file that is configured under
the [edit systern syslog l hierarchy. However, we recommend that you configure the
SRX branch device to send the AppTrack logs to an external syslog server. Storing the logs on an
external syslog server, such as the STRM, ensures that the logs are in a readable, well-organized
format.
You do not need to enable the session-close or session-ini t options in a security policy to
get AppTrack messages. For better performance when App Track is enabled, we recommend that you
do not enable the session-close or session-init options in security policies.

Chapter 2-26 • AppSecure www.juniper.net

Advanced Ju nos Security

Optional Applrack Parameters

• Optional configuration
• Configure an update interval
[edit security]
user@SRX# set application-tracking session-update-i nterval 4

• Generate a syslog entry when the session starts

[edit security]
user@SRX# set application-tracking first

• Configure a first update interval

[edit security]
user@SRX# set application-tracking first-update-interval 1

f:!\. :i·'·,:.r:
,P20i3 Juniper Netwon:,, Inc.All rights ........d"il
� ·* �
,,{1JtJn1Per
"":,!�')"" � � .�

.�-4,;./vLff..i�-
Worldwide EducaUon Services
=
"""' Jun,pe, n ,, I 27

Optional AppTrack Configuration

Typically, you do not need to configure the options listed on the slide for AppTrack. However, every
organization's needs are different, so you have the option to configure the statements if necessary.
Whenever a packet is received, AppTrack checks the time since the start of the session, or since the
last update of the session, to determine whether these items are greater than the update interval,
which by default is set to 5 minutes. If these values are met, AppTrack updates the counts and sends
an update message to the host. If a short-lived session starts and ends within the update interval,
AppTrack generates a message only at session close. Manually setting the update interval, with the
session-update-interval command, can adjust this behavior for the time you set.
By default, the first message is generated after the first session update interval elapses. To generate
the first message at a different time than this, use the first-update option, which generates the
first message at session start, or the first-update-interval option, which generates the first
message after the specified minutes.
It is important to note that the first-update and the first-update-interval options are
mutually exclusive. If you specify both, the first-update-interval value is ignored.

www.juniper.net AppSecure • Chapter 2-27

Advanced Junos Security

Viewing AppTrack Counters

• Examining the AppTrack counters

usec@SRX> show security application-tracking counters
Application tcacking countecs:

AppTcack countec type value

session cceate messages 40
session close messages 235
Session volume updates 99
Failed messages 0

Viewing the AppTrack Counters

You can view the AppTrack counters with the show security application-tracking
counters command. Every time a session create, session close, or volume update message is
generated, the corresponding value increments. The Failed messages counter only increments
if an AppTrack message is not generated due to memory or session constraints.

Chapter 2-28 • AppSecure www.juniper.net

Advanced Junos Security

AppTrack Logs (1 of 2)

• Session create log

• Only generated when the first-update option is enabled
May 1 10:37:46 SRX RT FLOW: APPTRJl�K SESSION CREATE: AppTcack session
cceated 192 .168 .1.223/ 60212->74.125 .224. 86/ 44 3 junos-https !SSLUGMAIL!
192.168.l.223/60212->74.125.224.86/443 None None 6 allow-tc·st tc'st untcust
965 !NIA!!EZfilN/A

�
Username

• Session close log

• Generated at the close of a session

Session Create Logs

The session create log, which is only generated when the first-update option is enabled,
displays a wealth of information. As shown on the slide, the application and nested applications that
are detected in the session are displayed. Also of note is the username and role fields that display
N/A. Remember that N/A is displayed in these fields for AppTrack logs if no UAC enforcement exists
for the involved security policy.

Session Close Logs

The session close log is always generated by AppTrack when a session closes. As shown on the slide,
this log also contains a wealth of information. First, the reason for the session closure is given-in
this case, a TCP FIN flag was seen. Then, the output displays the packets and bytes recorded for the
client-to-server communication, the packets and bytes recorded for the server-to-client
communication, and the elapsed time of the session.

www.juniper.net AppSecure • Chapter 2-29

Advanced Junos Security

AppTrack Logs (2 of 2)

• Session update log

• Only generated when a session lasts longer than the
session-update-interval option

May 1 10:31:49 SRX RT_FLOW: APPTRACK_SESSION_VOL_UPDATE: AppTrack volume

update: 192.168.1.223/59982->74.125.224.86/443 junos-https SSL GMAIL
192.168.1.223/59982->74.125.224.86/443 None None 6 allow-trust trust untrust
253 !832 (31510) Us33 (10290) 11760 !NIA N/ll. Nill.

Packets and bytes Packets and bytes Elapsed bme

from client from server of session

Session Update Logs

AppTrack only generates session update logs when a session lives longer than what is specified in
the session-update-interval option. If the session-update-interval option is not
configured the system will generate a session update log every five minutes.
This session log provides a wealth of information that is also seen in the session create and session
close logs. Of particular interest for this log are the packets and bytes recorded from the
client-to-server communication, the packets and bytes recorded from the server-to-client
communication, and the elapsed time of the session.

Chapter 2-30 • AppSecure www.juniper.net

Advanced Junos Security

Agenda:AppSecure
• AppSecure Overview
• ApplD
• AppTrack
7AppFW
• AppDoS
• AppQoS

AppFW
The slide highlights the topic we discuss next.

www.juniper.net AppSecure • Chapter 2-31

Advanced Junes Security

What Is Application Firewalling?

• Why is application firewalling needed?
• Many applications·use the same ports to send data
• Traditional stateful firewalling cannot distinguish between these
applications

• Application firewalling is an enhancement that uses the

results of application identification to filter content
• ApplD module identifies applications by application signature
matching instead of TCP or UDP port matching during session
initialization

The Need for Layer 7 Firewalling

Stateful firewalling has been the staple of security in most networks for years. This method worked
well when it came to keeping track of sessions, NAT mappings, protecting against session-based
attacks, attacks against connection-oriented protocols, and many other features. However, the
problem with stateful firewalls is that the inspection of traffic essentially stops at Layer 4. Only
inspecting up to Layer 4 means that the firewall does not inspect the payload of the traffic. This
leaves stateful firewalls in a position in which they filter traffic based on Layer 3 and Layer 4 really
well, but they are left open to allow Application Layer exploits. This situation leads us to the
technology known as application firewalling.
Application firewalling leverages the results of application identification to identify specific
applications, no matter which Layer 4 port they use. This helps stop exploits that might use
well-known Layer 4 ports, such as TCP port 80, but are not the typical application that runs over the
well-known port.
Another place that application firewalling is beneficial is in filtering traffic that might not be
malicious, but is simply unwanted. For example, as an administrator, you might need to block certain
application traffic that is being tunneled through HTIP. To accomplish this task with a stateful
firewall you would have to craft a security policy that blocks a combination of Layer 3 IP addresses
and Layer 4 ports. This approach is not feasible from a scaling perspective because the security
policy would continue to grow and change as websites changed their IP addressing, and as new
unwanted sites are added to the security policy. The AppFW module comes to the rescue by allowing
you to block these nested applications, based on their application signatures, while still allowing
other HTIP traffic to pass through the firewall.

Chapter 2-32 • AppSecure www.juniper.net

Advanced Junos Security

How Does AppfW Work?

17\ 1 t p cket
s a P ass fo r n ow

cD
\:.)-�

Q0
P ass fo r n o w Server replies
<IIE-- _ _ _ _ ,,

0 �--+ttffl�r-0
1 -+
AppFW has a rule to deny this app
2nd p acket

Sess ion Close

0 During First Path processing. if a security policy permits the packet. send the
packet to the ApplD and AppFW modules
0 If no match is found in ASC. ApplD inspects further packets to discover the
application (or nested application)
During Fast Path processing. ApplD detects the application based on the
application signature. Once the application is identified. AppFW decides what
action to take

Inner Workings of Application Firewalling

To understand how the inner workings of application firewalling function, we must examine how the
ApplD engine works with the AppFW module. Also, it is important to note that the other security
components of the SRX device come into play as well. If the firewall security policy does not allow the
packet through the stateful firewall, there is no possible way that the AppFW module will have a
chance to examine the packet.
When traffic for a new session is processed by the First Path algorithm, and it passes through a
security policy that references an application firewall rule set, the App ID module typically is unable to
identify the application. The application identification typically cannot occur within the first few
packets of the session because those packets generally do not contain any payload information (as
previously discussed in the ApplD section of this chapter). Then, the server responds by setting up a
session between itself and the client host. If no matching entry in the ASC exists, the SRX device
must wait for further traffic to allow the ApplD module to properly identify the application. Once
traffic with application data begins to flow, and the Fast Path processing on the SRX device has
begun, the ApplD module can correctly identify the application. Only at this point can the AppFW
module act upon the traffic and deny or accept the session.

www.juniper.net AppSecure • Chapter 2-33

Advanced Junes Security

Configuring AppFW

• When configuring an AppFW rule set you must...

• Decide on a whitelist or blacklist approach
• Whitelist: explicitly specified applications allowed. everything else
is blocked
• Blacklist: explicitly specified applications are blocked. everything
else is allowed
• Each rule can contain more than one application and nested
application
• Reference application signatures
• Applied through a security policy
• One rule set can be applied among multiple security policies
• Logical system support

Configuring Application Firewall

Before you begin to configure AppFW on your SRX device, you must ask yourself if you want to specify
every individual application you would like blocked (a blacklist), or if you want to specify every
individual application you would like to allow (a whitelist). Whichever direction you take depends on
the security policy that your company has in place, and possibly how much extra typing you want to
do.
You must then configure an AppFW rule set, which is accomplished under the [edit security
application-firewall] hierarchy level. In the rule set, you can configure rules that reference
application signatures for applications and nested applications. Then, you must specify an action for
any configured rules and the default rule. Finally, once you configure the AppFW rule set, you must
reference the rule set in a firewall security policy. As noted on the slide, you can apply one AppFW
rule set to multiple different firewall security policies, and you can configure AppFW inside a LSYS.

Chapter 2-34 • AppSecure www.juniper.net

Advanced Junos Security

Case Study: Blocking Application Usage

(1of 5)

• Configuration requirements
• Block the ability to use applications at www.facebook.com
• Allow unhindered access to the rest of the Internet

I
�D �D
I
�D
I
�o I

'.

Blocking Unwanted Traffic

One of the great benefits of AppFW is that not only does it help protect your network from malicious
attacks, but it also allows you to stop unwanted traffic. In the case study noted on the slide, users in
an enterprise have access to the Internet and are allowed to browse the Web. However, Facebook
applications and games are against company policy and must be blocked. It would be extremely
difficult, or impossible, to accomplish this task through only using a stateful firewall filter. The
Facebook application traffic is nested inside of HTTP and would require a stateful firewall filter to
block TCP port 80. That method is not a feasible solution in our case study.
Thankfully, we have the use of AppFW, which allows us to look deep into the payload of the HTTP
traffic for the nested Facebook application. This ability means that we can simply block the use of
Facebook applications and allow other HTTP traffic, including other Facebook traffic.

www.juniper.net AppSecure • Chapter 2-35

Advanced Junos Security

Case Study: Blocking Application Usage

(2 of 5)
• Configuring the rule set
• Whitelist or blacklist?
[edit security application-firewall]
user@SRX# show
Multiple application signatures can be specified
rule-sets block-FE {
rule block-FB-apps
m atch {
dynamic-application junos:FACEBOOK-APP;

then {
deny;

Blacklist rule sets typically contain a permit default rule

default-rule
permit;

The First Step

The first step of configuring any AppFW rule set is determining whether a whitelist- or blacklist-style
rule set is necessary. In our case study example, we want to block just one nested application,
Facebook applications. If we took the whitelist approach, we would need to configure every possible
application that might need to be allowed through the firewall. This task is time-consuming and
prone to error. However, because we must only block one application, it is best to take the blacklist
approach in our rule set.
As you can see in the slide, the junos: FACEBOOK-APP nested application is referenced under the
dynamic-application option. If you need to add other applications to be blocked in the future,
you can simple add to the dynamic application list; it is not necessary to create another rule or rule
set. Then, you must define a default rule. The default rule can only have the option of deny or
permit; we recommend that you use a different action than what is specified by the other rules in
the rule set.
The example on the slide shows a deny action in the block-FB-apps rule and a permit action
in the default rule; this is a classic example of a blacklist rule set.

Chapter 2-36 • AppSecure www.juniper.net

Advanced Junos Security

Case Study: Blocking Application Usage

(3 of 5)

• Apply the rule set within a security policy

[edit se curity policies fr-om-zone trust to-zone untrust]
user@SRX# shOW'
p olicy allow-trust
match {
sou rce-address any;

I
des tination-address any; Only one AppFW rule set
can be defined per security policy
app lication any;

then {
permit {
application-services {
application-firewall {

rule-set block-FB;

session-init must be used

to view denied sessions
I log
session-init;

Referencing the Rule Set

The final step in configuring our AppFW service for our case study is to reference the AppFW rule set
in a firewall security policy. As the slide notes, you can only apply one AppFW rule set to a firewall
security policy. Keep this restriction in mind as you develop your AppFW rule sets.
Then, as an optional step, you can log the traffic by enabling the log option under the firewall
security policy. As the slide notes, to view the denied sessions you must use the session- init
option. Using the session-close option displays a log for when the denied session closes, but
does not record the RT_FLOW_SESSION_DENY log.

www.juniper.net AppSecure • Chapter 2-37

Advanced Junos Security

Case Study: Blocking Application Usage

(4 of 5)

• Examine the AppFW rule set

usec@SRX> show security application-firewall rule-set all
Rule-set: block-FE
Rule: block-FB-apps Number of sessions that matched
Dynamic Applications: junos:FACEBOOK-APP the rule and thus were denied.

Action:deny
Numbec of sessions matched: 20
ktion of the default rule and the
Default cule:pecmit number of matching sessions
Numbec of sessions matched: 190
Numbec of sessions with appid pending: 5 ,,______, Number of half-completed sessions
ing the ApplD processing

-��·;v,lf ;'1.Jt.Jfi'll�� �orl,®tide Education Services w-..w ,unlper net 1 38

Examining the Application Firewall Statistics

Once you configure an application rule set, you can examine the statistics for every rule set using the
show security application- firewall rule-set all command, or you can specify
individual rule sets by leaving off the all option and specifying the requested rule set.
In the output on the slide, you can see the number of sessions that have been denied by our
block-FB-apps rule, the number of sessions that matched the default rule, and the number of
half-completed sessions that have not finished the application identification process. These pending
sessions are more than likely the result of broadcast traffic traversing the firewall.

Chapter 2-38 • AppSecure www.juniper.net

Advanced Junos Security

Case Study: Blocking Application Usage

(5 of 5)
• Examine the security policy
user@SRX> show security policies
Default policy: deny-all
From zone: trust, To zone: untrust
Policy: allow-trust, State: enabled, Index: 4, scope Policy: O, sequence
number: 1
Source addresses: any
Destination addresses: any
Applications: any Policy actions and
Action: permit, application services, log AppFW rule set
Application firewall:block-FB

• Examine the logs

May 1 07:55:36 SRX RT FLOW: RT FLOW SESSION DENY: session denied
192.168.1.223/50224->69.171.228. 72/80 Jjunos-http!� allow-trnst trnst
untrnst IHTTPUFACEBOOK-APP!N/A(N/.ll.) l-o; 0/ O. O No
¥

Examining the Firewall Security Policy

When examining the firewall security policy, you should notice the additional information that is not
present in firewall security policies that are not using the AppFW module. Of note is the application
services in the Action field and the AppFW rule set in the Application firewall field.

Application Firewall Logs

Remember that when we configured the firewall security policy, we set the policy to log session
initialization attempts. This action allows us to view the RT_ FLOW_SESSION_DENY log. This log
contains a wealth of information, such as the service name, protocol number, application, and
nested application. If necessary, you can use this information to help you create better AppFW rule
sets in the future.
Continued on the next page.

www.juniper.net AppSecure • Chapter 2-39

Advanced Junos Security
Application Firewall Logs (contd.)
The other AppFW Jogs also contain similar information, such as the RT_FLOW_SESSION_CREATE
Jog and the RT_FLOW_SESSION_CLOSE Jog, which are generated by using the session-init
and session-close options under the log statement in a firewall security policy, respecti vely.
The following are examples of each log type:
user@SRX> show log app-£w I match CREATE
May 5 03:21:53 srx2 RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.1.223/
52044->8.8.8.8/53 junos-dns-udp 192.168.1.223/52044->8.8.8.8/53 None None 17
allow-trust trust untrust 6530 N/A(N/A) ge-0/0/0.0

user@SRX> show log app-£w I match CLOSE

May 5 03:19:51 srx2 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN:
192.168.l.223/63044->65.197.244.218/80 junos-http 192.168.1.223/
63044->65.197.244.218/80 None None 6 allow-trust trust untrust 6269 9(759)
12(12729) 117 HTTP FACEBOOK-ACCESS N/A(N/A) ge-0/0/0.0 No
It is also important to mention the syslog configuration that is used to record these Jogs. The facility
and s everity of any any are used, and the match condition of RT_FLOW is used to match of the
necessary logs.
[edit system syslog]
user@SRX# show

file app-fw {
any any;
match RT_FLOW;

Chapter 2-40 • AppSecure www.juniper.net

Advanced Junos Security

Agenda:AppSecure
II
AppSecure Overview
•ApplD
•AppTrack
•AppFW
�AppDoS
• AppQoS

AppDoS
The slide highlights the topic we discuss next.

www.juniper.net AppSecure • Chapter 2-41

Advanced Junos Security

Malicious Attack Overview

• Malicious attacks have evolved

• Early attacks involved anomalous and invalid traffic
• Incorrect headers and values-junk traffic
• Effectively protected against with screens
• Attacks evolved to target application vulnerabilities
• Protected against with IDP functionality
• Attacks evolved to use botnets to blend attacks with normal
traffic
• Small amounts of traffic from each host overwl1elm targeted victim
• Application Layer attacks from multiple hosts
• AppDoS can protect an organization against Application Layer
botnet attacks

©2013 lun!perNetwnrle, lnCAU ri£hb r;�,��;;�:=� �- JUFl1Per�

; ;::,
<' ,,,
-;.;.,,:;;�:,,.
Worldwide Education Services li'JW!f4 Juniper net I 42

The Evolution of Malicious Attacks

When the first malicious attacks began to cause problems for networks, they were simple in nature
in that they would attempt to send junk or anomalous traffic to a protected network. Some of these
attacks included session table attacks, spoofed IP addresses, bad headers, and other TCP-based,
User Datagram Protocol (UDP)-. and Internet Control Message Protocol (ICMP)-based attacks. The
screens implementation of the SRX devices effectively handles these types of attacks.
Attacks then evolved to target application vulnerabilities by using worms and trojans that allow an
attacker to exploit the operating system or service of the target. The IDP implementation of the
SRX devices effectively protects against these types of attacks.
The next step in the malicious traffic arms race is the deployment of botnets. Botnets are large-scale
infections of computers with Internet connections-possibly hundreds of thousands of computers­
that are controlled by a single person or group of people. Then. on command, all of the computers in
a botnet can attack a single destination or service. This attack is better known as a distributed denial
of service (DDoS) attack. In the past. these types of attacks were more akin to SYN flood attacks,
where junk traffic ended up overwhelming a destination. However, the sophistication of these
attacks has increased in that they now have begun to go undetected by performing uninteresting
actions. Examples of these uninteresting actions can be as simple as submitting a form or
downloading a file from a website. These actions by themselves look like normal user behavior.
However, when a botnet is employed to perform these actions, the target host can easily be
overwhelmed with an application DDoS attack. To mitigate these application DDoS attacks, the
AppDoS module can detect, classify, and filter this type of traffic. Once the malicious traffic has been
filtered out, the legitimate user traffic can access the intended destination.

Chapter 2-42 • AppSecure www.juniper.net

Advanced Junos Security

Application DDoS Attack-Without AppDoS

Application DDoS Attack in Action

The slide visually depicts an application DDoS attack in action. As legitimate users attempt to
download a file from the data center, a legion of botnet-controlled computers launch an application
DDoS attack, which appears to be vary similar to the legitimate user requests. However, unlike the
legitimate user requests, the botnet-controlled computers repeat the download request over and
over. At this point, the data center's servers become overwhelmed with requests, and the legitimate
user traffic does not get processed.

www.juniper.net AppSecure • Chapter 2-43

Advanced Junos Security

Application DDoS Attack-With AppDoS

HTTP GET requests

Employing Application DDoS Protection

The slide visually depicts what happens when an application DDoS attack occurs and the AppDoS
module is employed to protect the data center. Again, the botnet of controlled computers begin their
attack and the legitimate Web user begins access to the data center's servers. However, the results
of this attack are much different: the AppDoS module is able to stop the application DDoS attack
and allows the data center's servers to process legitimate traffic.

Chapter 2-44 • AppSecure www.juniper.net

Advanced Junes Security

AppDoS and IDP Packet Processing

• AppDoS is a part of the IDP module

Firewall
Policy
Marked
for IDP AppDoS
Packet
Stateful Flow Module Attack
Fragmentation Serialization Protocol IDPActions
Firewall SSL Signature
Processing and TCP Decoding IP Actions
Processing Decryption Matching
Reassembly

AppDoS and IDP

The AppDoS module is a part of IDP and it leverages the strengths of the IDP module in its
functionality. For the SRX device to process traffic in the AppDoS module, a firewall security policy
must first be marked for IDP processing, just as with the normal IDP feature. Once the firewall
security policy match has occurred, each packet must be reordered and reassembled. Duplicate,
oversized, undersized, overlapping, and other invalid fragments are discarded. Then, the IDP session
table is examined to determine whether a previous session is present. Next, if no current IDP session
table entry is present, the IP actions table is consulted for existing entries, and if no IP actions exist
for the current session in process, the session is created. Also, at this time, if the destination is
marked for SSL decryption, a copy of the HTIPS traffic is sent to the decryption engine; the original
packet will be the queue until inspection is complete.
Once the SRX device creates the session, it must reorder and reassemble the packets into a
complete application message. Once the packet reordering and reassembly is complete, the ApplD
module performs pattern matching to determine which application is present in the traffic. It is
important to note that sometimes an application is not identifiable, as we discussed in the ApplD
section, but in these instances, application DDoS protection can still occur.
After the application identification step, the protocol parsing and decoding can start. The messages
in the session are deconstructed into application contexts, which help identify components of the
messages. Once the context of the messages are visible, AppDoS can begin classifying the traffic.
Also, if protocol anomaly detection is configured, it is performed alongside of AppDoS. Then, if full
IPS is being used, signature matches are detected through DFA matching. Finally, if any IDP or IP
actions are being taken on the traffic, AppDoS implements them at this point.

www.juniper.net AppSecure • Chapter 2-45

Advanced Junos Security

AppDoS Defined

• The AppDoS module can differentiate between

malicious botnet traffic and legitimate user traffic
• Frequency and pattern of application protocol contexts to
trigger application DDoS protection
• Rate limits can be set that apply to individual source
IP addresses
• Malicious hosts typically make frequent connections and repeat
the same activity over and over
• Legitimate users typically perform low-volume actions and request
unique activity
• Connections from malicious hosts are dropped
• Additional IP actions can prevent future connections from
occurring

���·F.,�.Jli.c,.' JUn1Per
._�......-----��"''
W�rldwideEducationSel'\lices WWWJun;pernet I 46

What Is AppDoS?
The AppDoS module, which is a subset of the IDP module, uses a technology that detects the
presence of malicious traffic that might not be doing anything improper, such as requesting a file to
download or filling up a shopping cart. This seemingly innocent, but malicious, traffic must be
separated from legitimate user traffic. Once AppDoS detects the malicious traffic, it can rate limit the
attacks to the point that they do not become a threat to the target. These detection and rate-limiting
processes are accomplished through a three-phase approach that we discuss in detail later in this
section.
To detect these malicious bot clients, AppDoS monitors the frequency and pattern of application
protocol contexts. AppDoS can also match these contexts in the initial packets, byte streams, and
other unclassified transactions. The following example includes contexts in a HTIP header. The IDP
contexts are marked in bold.
GET /index.html Httpl.l : http-get-url
Host: www.company.com : http-header-host
Accept: image/git, image/x-xbitmap, image/jpeg, image/pjpeg : http-header-accept
Accept-Language: en : http-header-accept-language
Accept-Encoding: gzip, deflate : http-header-content-encoding
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
http-header-user-agent
Additionally, future connections from malicious hosts can be acted upon by IP actions to block or rate
limit those connections.

Chapter 2-46 • AppSecure www.juniper.net

Advanced Ju nos Security

Three-Stage Processing of AppDoS

Stage 1: Server Monitoring Stage 2: Protocol Profiling Stage 3: BotClieritClassification

How the Three-Stage Process Works

In stage 1, the connection rates, which are counted in connections per second (cps), are parsed
against preconfigured thresholds associated with the server, or servers, being protected. When a
connection rate threshold is reached, the algorithm shifts to the next stage where protocol-specific
contexts are monitored.
In stage 2, AppDoS monitors the rate at which predefined contexts, such as http-header-host, are
requested, as well as the actual value of the context, such as www.juniper.net. If the context rate or
the context value rate exceeds the configured thresholds, the process can move on to stage 3.
However, stage 3 is optional: if stage 3 is not configured, then a simple rate threshold across the
entire SRX device will occur. This stage 2 rate limiting is very similar to screens rate limiting.
However, if stage 3 is enabled, by configuring a time binding, AppDoS tracks the rate of the contexts
being matched for individual clients to prevent them from individually surpassing the defined limits
within the time period. Then, if the configured time-binding values are surpassed, the appropriate
IDP or IP action can take place.
It is important to note that IDP uses hysteresis for state transitions to avoid thrashing between the
states. A default of a 20 percent lower limit will be used from the configured connection and context
thresholds for falling behind in state. For example. if you configure a context value rate of 10,000,
IDP transitions from protocol analysis to bot client classification after 10,000 hits in 60 seconds for
identical context values, and falls behind in state only when such hits are smaller than 8000 in
60 seconds.

www.juniper.net AppSecure • Chapter 2-4 7

Advanced Junes Security

Configuring AppDoS (1 of 3)

• Configure the firewall security policy

[edit security]
user@SRX# show policies
from-zone untrust to-zone trust {
policy �.ll-Permit {
match {
source-address any;
destination-address any;
application any;
Enables AppDoS for traffic
that matches security policy
then {
permit
.-����������--.
application-services
idp;

Configuring AppDoS Protection

When you configure AppDoS, there are three main areas of configuration to consider. The first area
of configuration is depicted on the slide. You must reference the IDP services in the firewall security
policy. This referencing allows AppDoS, and IDP, to process the the traffic that matches the security
policy.
The other two areas of configuration are covered in the following slides.

Chapter 2-48 • AppSecure www.juniper.net

Advanced Junos Security

Configuring AppDoS (2 of 3)
• Configure DDoS rulebase and activate the IDP policy
[ edit security]
use r@SRX# sho,., idp
idp-policy AppDoS-Webserver
rulebase-ddos
rule 1 {
match
destination-address User-defined
application-ddos application DDoS profile
Webserver;

then SRX sends a reset

ction message to the server
close-server;
Future connections from
offending source IP addresses
ip-action { are blocked for 1 minute
ip-block;
timeout 60;

active-policy AppDoS-Webserver;

, ,:
ti)2013luniperNetfl!l)rl!$,:lnc .tJ,n��l'eSfJrv;d§;� � �,��u�[l�,[
0 &&'''"'"

�-
,.._�,. »�
Worldwide Education Services
=�
WW\1\1 Jlln1pernet I 49

Configuring the AppDoS Rulebase

Remember that when configuring an IDP policy there are two possible rulebases: the IDP and exempt
rulebases. With the implementation of AppDoS, a third rulebase has been defined, the DDoS
rulebase. The DDoS rulebase allows you to configure an IDP policy that is similar to the IDP policies
configured under the IDP and exempt rulebases. The major difference is the presence of the match
option application-ddos, which allows you to reference a user-defined application DDoS
profile. We discuss how to configure the application DDoS profile in the next slide. Also, remember
that with the IDP rulebase, if traffic matches more than one rule, the rule with the most severe action
applies unless the terminal option is defined. However, with an application DDoS rulebase, the
rules are always terminaL Because of this action, you should configure a different rule for each
protected server, or protected groups of servers.
Also, remember to apply the newly defined IDP policy as the active policy, as depicted on the slide.

www.juniper.net AppSecure • Chapter 2-49

Advanced Junes Security

Configuring AppDoS (3 of 3)

• Configure the application DDoS profile

[edit security]
user@SRX# show idp

application-ddos Webserver {

!....---- �
service http; �
!
connection-rate-threshold 1000;
context http-get-url {
hit-rate-threshold 60000; Stage 2 criteria

value-hit-rate-threshold 30000;
time-binding-count 10;
time-binding-period 25;

Configuring the Application DDoS Profile

The application DDoS profile is where you define the parameters to identify malicious bot clients and
trigger the application DDoS protection. To enable stage 1 processing, server monitoring, you must
define a connection-rate-threshold and a service to monitor. The slide shows that the HTIP
service is being monitored and the connection rate threshold must exceed 1000 connections per
second. Once the connection rate exceeds the connection rate threshold, stage 2 processing is
employed.
Once stage 2 processing, protocol profiling, has been employed, the application DDoS attacks can
be classified into either heavy hitters or random hitters. Heavy hitters perform identical application
transactions in a fast and repeated fashion-for example, querying a nonexisting domain name
repeatedly. Random hitters perform random application transactions-for example, querying a
random domain name, one per each request. You can configure context
value-hit-rate-threshold to detect heavy hitters and context hit-rate-threshold to
detect random hitters. In the example on the slide, we have configured a hit-rate-threshold
of 60,000 and a value-rate-threshold of 30,000. With this configuration, you must have the
http-get-url context in 60,000 identical application transactions in 60 seconds, or 30,000
random application transactions in 60 seconds, to trigger stage 3 processing.
Continued on the next page.

Chapter 2-50 • AppSecure www.juniper.net

Advanced Junes Security
Configuring the Application DDoS Profile (contd.)
Once stage 3 processing, bot client classification, has begun, the SRX device examines the
connections on a host-by-host basis. With the configuration example on the slide, a single host would
need to request the http-get-url context 10 times in a 25-second period to be classified as a
malicious bot client. Once the SRX device classifies a host as a malicious bot client, the actions that
are specified in the application DDoS rulebase are applied.

www.juniper.net AppSecure • Chapter 2-51

Advanced Junos Security

Monitoring AppDoS Operation (1 of 2)

• Examining AppDoS application status

user@SRX> show security idp application-ddos application

nodeO:

zone Server Application Conn/sec Context Contexts/tick

trust 172.l.Ll web-server 2648/sec http-header-user-agent 35746/60sec

user@SRX> show security idp application-ddos application detail

nodeO:

Zone: trust Server: 172.1.1.1 Application: web-server Connections/sec: 2615/sec

Context: http-url contexts/tick: 148196/60sec
Value: 2f 6e 65 74 73 63 72 65 65 6e 2e 68 746d 6c /netscreen.htm
Context va lues/tick : 26809/60sec

�- .. -:-w,· .
©20i3JunlperN•t-,,orle, Inc Ali rict,O .....,,,..:
" ""
,q; ,,
f. ", Ul:.l.[i)IPer:
• ""�*��.-
. Worldwide Education Services """" Jun;per net I 52

Viewing the AppDoS Application Status

The show security idp application-ddos application command is best used to
ascertain if a particular AppDoS configuration is working, because it displays the basic statistics for
the servers being protected. The following bullets display the meaning of each field in the output.
Zone: Security zone where the protected server resides;
Server: IP address of the protected server;
Application: Name of the DDoS application profile.
Conn/sec: Number of client connections to the protected server per second;
Context: Protocol context that is being monitored; and
Contexts/tick: Number of protocol context hits measured per tick. (One tick equals 60
seconds by default.)
Additional options can be added to this command to filter the output, such as the zone, application
name, and server.

Chapter 2-52 • AppSecure www.juniper.net

Advanced Junos Security

MonitoringAppDoS Operation (2 of 2)

• Examining AppDoS counters

user@SRX> show security idp counters application-ddos
no deO:

IDP counters:

IDP counter type Value

App-DDOS in spected flows 4345
App-DDOS fa iled flows 0
App-DDOS ignored flows 972
App-DDOS first path fa iled 0
App-DDOS first path succeeded 5317
App-DDOS d ropped packets 0
App-DDOS processed packets 20002
App-DDOS conn ection table proc ess succeeded 5012
App-DDOS connection table process failed 0
}i..pp-DDOS context pi:-ocess succeeded 4260
App-DDOS context process failed 0
App-DDOS igno r e context 0
App-DOOS context values excluded 0
App-DDOS conteKt value process succeeded 4260

Viewing the AppDoS Counters

The show security idp counters application-ddos command displays all the AppDoS
statistics for all the application DDoS rules on the local SRX device. You can view an explanation of
each of the fields in the CU Reference Guide in the Juniper Networks techpubs website,
www.juniper.net;techpubs.

www.juniper.net AppSecure • Chapter 2-53

Advanced Junos Security

AppDoS Logs (1 of 3)
• State transition logs
(IDP_APPDDOS_APP_STATE_EVENT)
• Generated when a state change occurs
• Enabled implicitly

2011-10-23T02:06:26.544 SRX3400-1 RT IDP - IDP APPDDOS APP STATE EVENT

[[email protected] timestamp = "1319367986" ddos-application­
name= "Webserver" destination-zone-name= "untrust" destination-interface­
name= "reth0.0" destination-address="172.27.14.203" destination-port="80"
protocol-name="TCP" service-name= "HTTP" rule-name="l" rulebase-name="DDOS"
olic -name="A DoS-Webserver" re eat-count=" 0"
message= "Connection rate exceeded limit 60" context-value = "N/A"l

Reason for
state change

Examining the State Transition Logs

Whenever AppDoS changes from connection monitoring to protocol analysis, the SRX device
generates a state transition log. This Jog carries information about the event that triggered the log
and contents of the traffic at the time the log is generated. This log goes through a suppression
mechanism to avoid sending multiple logs to indicate the same event within the suppression interval
(default five seconds). The repeat count indicates the number of suppressed logs, which also
indicates that log suppression is occurring. Note that when this log is generated to indicate state
transition from connection-monitoring to protocol analysis, all the context-related fields in the Jog are
listed as N/A because the contexts are not yet being monitored. The Junes OS enables this log event
by default; no configuration is necessary, and an administrator cannot disable it.

Chapter 2-54 • AppSecure www.juniper.net

Advanced Junos Security

AppDoS Logs (2 of 3)
• IDP Attack Event Logs (IDP_ATTACK_LOG_EVENT)
• Generated when a specified IDP session action is performed
• ip-actions must be configured
Action performed

2011-10-23T14:57:25.824 SRX IDP ATTACK LOG EVENT

[[email protected] t;;mestamp= "1319414245" message-type ="TRAFFIC" source-
address="192.168.14.21� source-port="35250" destination­
address="172.27.14.20 " destination-port="80" protocol-name ="TCP" service­
name =" SERVICE NONE" pplica tion-name="NONE" rule-name ="1" rulebase-
name ="DDOS" polic ame="AppDoS-Webserver" repeat-count= "O"
action="TRAFFIC_IPACTION_DROP" threat-severity="INFO" attack-name ="-"nat-
source-a ress= nat-source-port ="34765" nat-destination-
address=" O.O.O. O" nat-destination-port= "O" elapsed-time="O" inbound­
bytes="O" outbound-bytes= "O" inbound-packets= "O" outbound-packets= "O"
source-zone-name="trust" source-interface-name ="rethl.0" destination-zone­
name="untrust"destination-interface-name= "r-ethO.O"pktlog_id="O" message="-"]

Viewing an IDP Attack Log

The IDP_ATIACK_LOG_EVENT tag indicates an ip-action filter has been installed as a result of
the policy action. This log type also goes through the log suppression mechanism.

www.juniper.net AppSecure • Chapter 2-55

Advanced Junos Security

AppDoS Logs (3 of 3)
• Attack Event Logs
(IDP_APPDDOS_APP _ATIACK_EVENT)
• Generated when notification log-attacks is enabled

2011-10-23Tl6:28:31.696 SRX3400-l RT IDP - IDP APPDDOS APP ATTACK EVENT

[ junos@2636 .1.1.1.2.35 time stamp= "1319419711" ddos-application­
name="Webse['Ve['" SOU['Ce-zone-name ="t['ust" SOU['Ce-inte['face-name ="['ethl.O"
sou['ce-add['ess= "l92.168.14.214" SOU['Ce-po['t="50825" destination-zone­
name="unt['ust" destination-inte['face-name="['ethO.O" destination­
add['ess="172.27.14.203" destination-po['t="80" p['otocol-name="TCP" se['vice­
name="HTTP" ['Ule-name="l" ['Ulebase-name ="DDOS" policy-name="AppDoS­
Webse['Ve['" ['epeat-count="O" action="NONE" th['eat-seve['ity ="INFO" connection­
hit-['ate= "30" context-name= "http-get-u['l" context-hit-['ate="123" context­
value-hit-['ate= "O" time-scope="PEER" time-count="3" time-pe['iod ="60"
context-value="N/A" l

Examining an Application DDoS Attack Log

The IDP_APP_ATTACK_EVENT log tag indicates that an attack occurred when the number of client
transactions exceeded the user-configured connection rate, context rate, and time-binding
thresholds. This log is generated only if you configure the notification log-attacks in a rule
in the application DDoS rulebase. This log carries a wealth of information about the specifics of the
attacker, the action taken on the traffic, and the destination of the attack. As with the previous logs
mentioned, this log goes through a log suppression mechanism.

Chapter 2-56 • AppSecure www.juniper.net

Advanced Junes Security

Agenda: AppSecure

•AppSecure Overview
•ApplD
•AppTrack
•AppFW
•AppDoS
�AppQoS

©2013JunlporNet,.,•rl:s, ln•)•lfllbl!�;•.,,.4·� ,.,:·;r ·. ..JIJnlPef

Jflj)".l;'Z�rf.,.:V1, cH,<" "'W

.;.;;t;�:,:,c.;
,-.-,..-,'>

=�-----� Worldwide Education Services ""'"' Jun,pe, net I 57

AppQoS
The slide highlights the topic we discuss next

www.juniper.net AppSecu re • Chapter 2-5 7

Advanced Junos Security

AppQoS Defined

• What is AppQoS?
• Allows for application-based classification
• Rate limiting
• DSCP remarking
• Forwarding class assignment
• Loss priorities
• No bandwidth guarantee
• Works with other Cos functionality
• Can be used to guarantee bandwidth
• Other CoS functionality might take remarking precedence

What Does AppQoS Do?

The AppQoS module provides a measure of Application Layer quality of service (QoS). AppQoS
provides a process that allows you to rate-limit traffic in either direction, client-to-server or
server-to-client, rewrite the DSCP values, and assign forwarding class and loss priority values for
traffic that uses a specific application. However, it is important to note that AppQoS does not provide
a mechanism to guarantee bandwidth. If you require bandwidth reservation for the traffic to which
you are applying AppQoS, you must use the other, built-in, class-of-service (CoS) features. However,
you must keep in mind that if you use the other CoS features of the Junos OS, you must take into
account the remarking precedence of those other CoS features. Know that IDP remarking has
precedence over application remarking, which has precedence over interface-based remarking. For
example, if a packet triggers IDP remarking, application remarking, and interface remarking, only the
IDP remarking values are honored.

Chapter 2-58 • AppSecure www.juniper.net

Advanced Junos Security

How AppQoS Works

• AppQoS in the box

• Application traffic enters the SRX
• Matches AppQoS profile
• Traffic can be reclassified or rate limited
• Rate limiting can be client to server. or server to client

How Does AppQoS Work?

Once AppQoS is configured on the SRX device, traffic must match the AppQoS profile. Once this
profile match occurs, the traffic can be rate-limited or reclassified. This rate limiting can happen in
the client-to-server or server-to-client direction, which can help restrict the amount of data a user
uploads or downloads.

www.juniper.net AppSecure • Chapter 2-59

Advanced Junos Security

Configuring AppQoS (1 of 3)

• Configuring the rate limiters

[edit class-of-ser-vice]
user@SRX# shot,l"
for-war ding-classes {
class ftp-AppQoS queue-num 2;

'value in Kbps
application-traffic-control {
rate-limitern ftp-C2S (
!bandwidth-limit 100;
!burst-size-limit 13000;
I� .---,
rate-limiters ftp-S2C(
�
bandwidth-limit 200;
burst-size-l imit 26000;

First Steps of Configuring AppQoS

When congestion occurs, AppQoS implements rate limiting on all egress PJCs on the device. If
packets exceed the assigned limitations, they are dropped. Rate limiters maintain a consistent level
of throughput and packet loss sensitivity for different classes of traffic.
A rate-limiter profile is a unique combination of bandwidth-limit and burst-size-limit
specifications. The bandwidth-limit defines the maximum number of kilobits per second (Kbps)
that can traverse the port. The burst- size-limit defines the maximum number of bytes that
can traverse the port in a single burst. The burst-size-limit reduces starvation of lower
priority traffic by ensuring a finite size for each burst.

When defining the burst -size-limit value you must specify a value that is large enough, but
not too large. If you specify a value that is too small there will not be enough of a
burst-size-1 imit for the token bucket algorithm, and traffic might be Jost. If you specify a value
that is too large, the entire transfer might fit into the burst. We recommend that you set a
burst-size-limit that is at least eight times the bandwidth-limit value, but no larger than
6400 times the bandwidth-limit value.
Also, a custom forwarding class is depicted on the slide. This step is optional because you can use
one of the built-in forwarding classes if necessary.

Chapter 2-60 • AppSecure www.juniper.net

Advanced Junos Security

Configuring AppQoS (2 of 3)

• Configuring the rule set

[edit class-of-ser-vice]
user@SRX# show application-traffic-control
Configurable options:
application
rule-sets ftp-App-QoS { application-any
rule ftp-traffic { application-group
match { application-known
I application junos: FTP; application-unknown

then
forwarding-class ftp-AppQoS; All options
a re optiona I
dscp-code-point 000000;
loss-priority high;
rate-limit {
client-to-server- ftp-C2S;
server-t o-client ftp-S2C;

log;

<$12013 JunlperNetP.orl<i, lnt.AIJ�t, ....1\1.d � "''

'lf•
;;:)l:Jr;JIPer
"'''! .�-. v
·:'.
'' �.± � 1�
•
Worfdwide Education Services
-" ,.,,i"-ili-i=«
""'" jun,pe, "' I 61

Configuring the AppQoS Rule Set

As you configure an AppQoS rule set, you must specify an application on which to match. You can
choose just one application, an application group, known and unknown applications, or all
applications with the any-application option. Then, you must specify the actions to be taken on
the traffic. All the actions are optional, but you must at least specify one option or the configuration
check will fail.

www.juniper.net AppSecure • Chapter 2-61

Advanced Junes Security

Configuring AppQoS (3 of 3)
• Configure the firewall security policy
[edit security]
user@SRX# show policies
from-zone untrust to-zone trust {
policy All-Permit {
match {
source-address any;
destination-address any;
application any;
Enables the AppQoS rule set for
traffic that matches security policy
then {
permit
application-traffic-control
rule-set ftp-App-QoS;

Referencing the AppQoS Rule Set

The last step in configuring AppQoS is referencing the AppQoS rule set in a firewall security policy.
Once you have referenced the rule set, any traffic that passes through the security policy is subject to
AppQoS control.

Chapter 2-62 • AppSecure www.juniper.net

Advanced Junos Security

Monitoring AppQoS Operations (1 of 4)

• Examining the traffic session

user@SRX> show security flow session extensive

Session ID: 3729, status: Normal, state: Active
Flag: Ox40
Policy name: All-Permit
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: ftp-App-QoS, Rule: ftp-traffic
Maximum timeout: 300, current timeout: 276
session state: Valid

The Security Flow Output

Sessions that match the AppQoS rule set now contain an extra field in the show security flow
session extensive output. These sessions display the current AppQoS rule set and rule that is
being applied to them.

www.juniper.net AppSecure • Chapter 2-63

Advanced Junos Security

Monitoring AppQoS Operations (2 of 4)

• Verify AppQoS session statistics

usec@SRX> show class-of-service application-traffic-control counter

pie: 2/1
Countee type Value
sessions pcocessed 300
sessions macked 200
sessions honoced 0
sessions cate limited 100
Client-to-secvec flows cate limited 100
Secvec-to-client flows cate limited 100

;Jun1P
-�-- ef
. "'""""'
-
WorldwideEducationServices
-
....... ,un,pe'"ol i 64

Examining AppQoS Session Statistics

The output on the slide displays the AppQoS DSCP marking and honoring statistics. The output
shows that the AppQoS module has processed 300 sessions, of which 200 were re-marked based
on application-aware DiffServ code point (DSCP) markings.
The output also shows that 100 of those sessions have been rate-limited, which equates to 100
client-to-server communications and 100 server-to-client communications.

Chapter 2-64 • AppSecure www.juniper.net

Advanced Junes Security

Monitoring AppQoS Operations (3 of 4)

• Verify rate limiters

user@SRX> show class-of-service application-traffic-control statistics rate­
limiter
pie: 2/1
Rules et Application Client-to-server Rate (bps) Server-to-client Rate (bps)
http-App-QoS HTTP ftp-C2S 200 ftp-C2S 200
http-App-QoS HTTP ftp-C2S 200 ftp-C2S 200
ftp-App-QoS FTP ftp-C2S 100 ftp-C2S 100

Examining the Current Rate-Limited Sessions

The output on the slide displays the rate limiting of current and recent sessions. The output shows
that two sessions are being rate-limited by the http-App-QoS rule set, and one session is being
rate-limited by the ftp-App-QoS rule set.

www.juniper.net AppSecure • Chapter 2-65

Advanced Junos Security

Monitoring AppQoS Operations (4 of 4)

• Examine the statistics per rule

user@SRX> show class-of-service application-traff ic-control statistics rule

pie: 2/0
Ruleset Rule Hits
ftp-App-QoS ftp-rule 100
http-App-QoS http-rule 100
other-App-QoS telnet-rule 300
other-App-QoS smtp-rule 300

,i�'""t "'�, '•

©2013 JunlperN;tw�, ,;._·Al: riitit; .:;..,,,...
' ·"�<�"''. �--"'-""'-�-
' .
• Junm Worldwide Education Services
,.,_� -� �
""� 1un,pe, net I 66

Examining the Hits Per Rule

The output on the slide shows how many times traffic matched each rule, the corresponding rule set,
and the Physical Interface Card (PIC) where the rule is applied.

Chapter 2-66 • AppSecure www.juniper.net

Advanced Junos Security

Summary
• In this content, we:
• Described the functionality of the AppSecure suite
• Explained how the different AppSecure modules function
• Monitored the operation of the differentAppSecure modules

We Discussed:
The functionality of the AppSecure suite;
How the different AppSecure modules function; and
How to monitor the operation of the different AppSecure modules.

www.juniper.net AppSecure • Chapter 2-67

Advanced Junos Security

Review Questions

1. Which AppSecure module is used by all other

AppSecure modules?
2. How do nested applications relate to applications?
3. What is the purpose of the application system
cache?
4. How could you stop users from commenting in the
comments section of a YouTube video?
5. How do you guarantee bandwidth if AppQoS is
employed?

Review Questions
1.

2.

3.

4.

5.

Chapter 2-68 • AppSecure www.juniper.net

Advanced Junos Security

Implementing AppSecure Lab

• Configure and monitor ApplD and AppFW features.

• Configure and use custom application signatures.
• Configure and monitor AppTrack.

Implementing AppSecure Lab

The slide provides the objectives for this lab.

www.juniper.net AppSecure • Chapter 2-69

Advanced Junes Security

Answers to Review Questions

1.
The AppID module is used by all other AppSecure modules. The AppID module allows the other AppSecure
modules to correctly identify the application of a session.

2.
Nested applications are found within applications. Some examples of nested applications are Gmail,
T
Facebook, and YouTube, which are nested inside of HT P.
3.
The application system cache allows tl1e ApplD module to store entries of applications, and nested
applications, that have passed through the SRX device. This process frees up system resources and allows for
quicker application identification times.
4.
To stop users from commenting on YouTube videos, you could configure an AppFW rule that denies access
to the YouTube comments section with the dynamic application junos :YOUTUBE-COMMENT.
5.
You cannot guarantee bandwidth with AppQoS. However, you can use the other built-in CoS functionality in
the Junos OS to guarantee the necessary bandwidth.

Chapter 2- 70 • AppSecure www.juniper.net

Advanced Junos Security

Chapter 3: Junos Layer 2 Packet Handling and

Security Features
Advanced Junos Security

Objectives
• After successfully completing this content, you will be
able to:
• Explain transparent mode security operations
• Configure Layer 2 Ethernet switching
• Implement Junos Layer 2 security features

We Will Discuss:
Transparent mode security operations;
Layer 2 Ethernet Switching; and
Junos Layer 2 security features.

Chapter 3-2 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Agenda: Junos Layer 2 Packet Handling and

Security Features

� Transparent Mode Security

• Layer 2 Ethernet Switching

Transparent Mode Security

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-3
Advanced Junos Security

Layer 2 Transparent Mode

• Transparent mode overview

• Provides Layer 2 bridging of internal network segments

I· .. .

Transparent Mode Overview

Transparent mode provides Layer 2 bridging of internal network segments. The internal network
segments can be operating at Layer 2 or Layer 3. With transparent mode, the Junos OS can apply
security zones and security policies to Layer 2 traffic. Transparent mode does not interrupt any
routing or forwarding of the internal network, unless the traffic is denied by the security configuration
on the SRX device.
On the SRX, you can configure one or more bridge domains to perform Layer 2 bridging. A bridge
domain is a set of logical interfaces that share the same flooding or broadcast characteristics.

Transparent mode provides the ability to join internal Layer 2 networks, and to provide security for
these networks. Transparent mode is simple to configure and allows for a quick implementation in
any network, because it does not interrupt any Layer 3 routing. The SRX device will bridge traffic
between interfaces and zones, rather than routing the traffic. This type of deployment is ideal for a
data center environment, where additional security is needed without having to reconfigure the
network.

Chapter 3-4 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Securing Transparent Mode

• Transparent mode security

• Layer 2 zones are configured with security policies and
screens for protection
• Requirements and restrictions
• All interfaces in the zone must be Layer 2 interfaces (family
bridge)
• The SRX device does not support a mix of Layer 2 and Layer 3
zones at the same time
• The SRX requires a reboot after configuring transparent mode

Transparent Mode Security

All interfaces involved in transparent mode are configured with the protocol family bridge. Each
interface essentially then becomes its own bridge domain. After the interfaces have been
configured, they are then added to a Layer 2 zone, which then combines multiple bridge domains.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-5
Advanced Junos Security

Transparent Mode Configuration (1 of 2)

• Configure the Layer 2 interfaces

[edit]
user@srx# show interfaces
ge-0/0/0 {
unit O {
family �4,--------,.i Protocol Family bridge required for Layer 2 interfaces
interface-mode
v lan-id 20;

)
ge-0/0/1
unit O {
family (bridgei {
interface-mode access;
vlan-id 20;
Layer 2 Zone: L2

�
10.1.1.4/24 10115/24
VLAN 20 VLAN 20

���J.I!:���llrillhlff•••
�
k' <> '" •
f·, _ �
'"
, '.��n�
•
WorldwideEducationServices ww•
• iunipernet Is

Configure the Layer 2 Interfaces

The slide demonstrates the basic configuration steps for transparent mode operation. The first step
is to specify family bridge on an interface. This setting puts the interface in Layer 2 forwarding
mode. The interface mode can be specified as either access or trunk mode. Access mode allows
for a single VLAN, whereas trunk mode allows for multiple VLANs by creating a vlan-id-list. To
configure the list of VLAN IDs to be accepted by the trunk port, include the vlan-id-list
statement and specify the list of VLAN IDs. You can specify individual VLAN IDs with a space
separating the ID numbers, specify a range of VLAN IDs with a dash separating the ID numbers, or
specify a combination of individual VLAN IDs and a range of VLAN IDs.
On the slide, we have configured interface-mode access, which allows for a single VLAN. We
have then configured a vlan-id of 20.

Chapter 3-6 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Transparent Mode Configuration (2 of 2)

• Configure the Layer 2 zones and security policies

[edit]
usec@scx# show security zones
secucity-zone L2 {
intecfaces {
ge-0/0/0.0;
ge-0/0/ 1. 0;

l
[edit]
usec@scx# show security policies from-zone L2 to-zone L2
policy allow {
match {
soucce-addcess any;
destination-addcess any;

£r�<-FT_P >�
application junos-ftp;
l
then { Layer 2 Zone: L2
pecmit;

10114/24 10115/24
VLAN 20 VLAN 20
""',,.,,0�, :''r
"1" � "'r� Ii\4li ,:'.,:* ,,. ,:, r>;,*::·"'"".
S'Ju•lR•r1'let<-;,•oo, lno,J\11 ��1,,.�e.,,ell.• · 11:v'.;tJl,'.�� Worldwide Education Services www ;, ..,., net 1 7
..

""'��.,.>�= -� «� "'

Configure the Layer 2 Zones and Security Policies

After the interfaces are created, each interface is then assigned to a security zone. In this case, we
have named the zone L2 and added interface ge-0/0/0 to the zone. Next, the security policy is
configured. The security policy for a Layer 2 zone is configured similar to security policy for Layer 3
zone, with the from- zone and to- zone statements. Because the Layer 2 traffic is passing
between interfaces in the same zone, this example represents an intrazone policy, and both the
from- zone and to- zone contexts are the L2 zone. In this case, we are going to allow traffic from
any source or destination address, but only FTP traffic. All other traffic passing through this security
zone will be blocked. Remember, the Junos OS does not implicitly allow unspecified intrazone traffic.
It is blocked by default.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-7
Advanced Junos Security

Managing Transparent Mode

• Transparent mode device management

• Out-of-band management on fxpO interface
• High-end SRX only
• In-band management on IRB interface
• Branch SRX or high-end SRX IRB interface
10.1.1.50/24
[edit]
user@srx# show interfaces irb VLAN 20
unit O (
family inet (
address 10.1.1.50/24;
}
[edit] Layer 2 Zone: L2
user@srx# show bridge-domains
IRB {
domain-type bridge;
vlan-id 20;
routing-interface irb.0; -::]El
�hctj
-�

10114/24 10115/24
VLAN 20 VLAN 20

Transparent Mode Management

For high end SRX devices, the out-of-band fxpO interface can continue to be used for management
while the SRX device is in transparent mode. You can also configure an in-band integrated routing
and bridging (!RB) interface that can be used for management. The SRX device does not route any
traffic over the management interface. It is strictly used for handling connections to manage the SRX
device. The slide shows a configuration example for configuring an in-band IRB management
interface.

Chapter 3-8 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Agenda: Junos Layer 2 Packet Handling and

Security Features
II
Transparent Mode Security
� Layer 2 Ethernet Switching

Layer 2 Ethernet Switching

The slide highlights the topic we discuss next.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-9
Advanced Junos Security

Layer 2 Ethernet Switching (Branch SRX

Devices)

• Ethernet switching overview

• Individual ports can be configured for routing or switching

Layer 2 Ethernet Switching

The branch SRX series SRX100, SRX210, SRX220 and SRX240 devices have the capability to
configure each individual onboard Gigabit Ethernet or Fast Ethernet port for either switching or
routing mode. The xPIM Multiport Gigabit Ethernet ports on the SRX650 can also be configured for
either routing or switching.
Continued on the next page.

Chapter 3-10 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security
Layer 2 Ethernet Switching (contd.)

Supported Switched Ports

Device Ports

SRX100 Onboard Fast Ethernet Ports (fe-0/0/0 through fe-0/0/7)

SRX110 Onboard Fast Ethernet Ports (fe-0/0/0 through fe-0/0/7)

SRX210 Onboard Gigabit Ethernet Ports (ge-0/0/0 and ge-0/0/1)

Onboard Fast Ethernet Ports (fe-0/0/2 through fe-0/0/7)

SRX220 Onboard Gigabit Ethernet Ports (ge-0/0/0 through ge-0/0/7)

SRX240 Onboard Gigabit Ethernet Ports (ge-0/0/0 through ge-0/0/15)

SRX550 Onboard Gigabit Ethernet Ports (ge-0/0/0 through ge-0/0/5)

Gigabit Ethernet GPIM Modules
SRX650 Gigabit Ethernet GPIM Modules

When family ethernet- switching is configured on an interface, the interface will operate in
Layer 2 switching mode. A Layer 2 interface can operate in either of two modes-access mode or
trunk mode.
An interface in access mode connects directly to an end device, such as a user's workstation, a
server, a printer, or an IP phone. The interface itself belongs to a single VLAN. Any frames sent over
the access interface are normal, untagged Ethernet frames.
Trunk mode, on the other hand, combines traffic for multiple VLANs over the same physical
connection. Trunk interfaces are often used to interconnect switches to each other.
A major benefit that Ethernet switching provides to the branch office environment is that it
eliminates any unneeded or extra hardware, such as additional Layer 2 switches on the network, as
long as the SRX Series device has enough available ports to support all users.

Branch SRX devices also support routed VLAN interfaces by specifying an IP address for a VLAN
interface and designating the interface as a Layer 3 interface.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-11
Advanced Junos Security

Ethernet Switching Configuration

[edit]
user@srx# show interfaces
ge-0/0/0 {
unit O
family ethernet-switching
port-mode trunk;
vlan �{������
� �
!members Group1;!------lnterface belongs to VI.AN Groupl

Layer 3 IP address configtired to

vlan { allow the VI.AN interface to provide
unit o { / routing for the Groupl VI.AN
fami l· y�i_n_e_t�{�����
� .._ ........
�ddress 10.10.10.1/24;!

[edit]
user@srx# show vlans
Groupl {
vlan-id 20;
Associate the 13-interface-----• !13-interface vlan.O; I

-::: J\V·\·)Un� WorldwideEducationServicas .,,,..,1un1pern,t J 12

.�--=--�·- ·-
Ethernet Switching Configuration
The slide illustrates a basic configuration for enabling Ethernet switching on an interface. The three
main components are the physical interface, the Layer 3 VLAN interface, and the VLAN group. Note
the Layer 3 interface is optional.
The first step is to specify familyethernet-switching on interfaces to be used for switching. In
this case, we are using physical interface ge-0/0/0. The protocol family is defined under the logical
unit. Port-modetrunk is specified, which allows this interface to participate in multiple VLANs. The
vlans statement under the unit configuration specifies to which VLAN this interface belongs. Once
committed, the status of the interface changes toeth-switch when running the following
command:
user@srx> show interfaces terse
ge-0/0/0.0 up up eth-switch

Next, the optional Layer 3 VLAN interface is defined. This interface will be referenced in the VLAN
configuration. The IP address is specified under the VLAN interface, which will provide routing for
Layer 3 traffic. This interface also belongs to a zone, which will allow for zone and security policy
configuration to secure traffic. The SRX device can be managed through the VLAN interface, if the
host-inbound-traffic command is configured.
Continued on the next page.

Chapter 3-12 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security
Ethernet Switching Configuration (contd.)

Lastly, specify the VLAN ID under the [edit vlans] configuration hierarchy. When configuring a
Layer 3 interface, you must also associate the VLAN interface as an 13- interface.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-13
Advanced Junos Security

Ethernet Switching Security (1 of 2)

• Layer 3 VLAN interface security
• Traffic is secured with zones an,d security policies
[edit]
user@srx# show security zones
security-zone switch {
interfaces {
vlan.O {

[edit]
user@srx# show security policies
from-zone Switch to-zone Switch
policy switch {
match {
source-address any;
destination-address any;
application any;

then {
permit;

VLAN Interface Security

In a pure switched environment, attached devices may communicate without security policy.
However, any Layer 3 VLAN interfaces, such as vlan. o on the slide, need to follow the security
configuration guidelines for the Junos OS, requiring zone assignment, policies for transit traffic and
inbound host traffic definitions.
The first configuration snippet on the slide shows interface vlan. o configured in the security-zone
Switch. The slide also shows a security policy allowing transit intrazone traffic flow for all traffic.

Chapter 3-14 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Ethernet Switching Security (2 of 2)

• Layer 2 Ethernet port security

• 802.ix port-based network authentication
• MAC RADIUS access control
• Monitoring Ethernet switching
usec@scx> show ethernet-switching interfaces
Intecface state VLAN membecs Tag Tagging Blocking
ge-0/0/0.0 up Gcoupl 20 tagged unblocked
ge-0/0/1.0 up Gcoupl 20 tagged unblocked

usec@scx> show ethernet-switching table

Ethecnet-switching table: 5 entries, 1 leacned
VLAN MAC addcess Type Age Intecfaces
Gcoupl * Flood - Al l-membecs
Gcoupl 0 0:22:83:9c:21:81 Leacn o ge-0/0/0 .o
Gcoupl b0:c6:9a:70:11:90 static - Routec
Gcoupl * Flood - Al l-membecs
Gcoupl b0:c6:9a:70:11:90 static -· Routec

� > � �\."',""" %ii!$&,:¥eoe 00,,,;,4"

�l1�Ju•flfarN :i,,t:;',10�.J\i!rf!!h,t,,..,.,.. (1 @ij1 WO:i-fowldeEducatlonServices
�iy�.. �� _Thllit_
ww.iJun,pernet 1 1s

Ethernet Port Security

The branch SRX device does not support the configuration of Layer 2 stateless firewall filters. However. it
does support some Layer 2 Ethernet port security. 802.ix is an Institute of Electrical and Electronics
Engineers (IEEE) standard that can be used to provide media access control (MAC) authentication on a
port. The 802.lx standard provides MAC RADIUS access control. To use this authentication, a RADIUS
server must be configured at the access hierarchy level in the command line interface. The RADIUS
server will contain a profile of which MAC hosts are allowed on an Ethernet port. The branch SRX device
is then able to send requests to the RADIUS server to verify authentication for a MAC host.

Monitoring Ethernet Switching

Some valuable commands to monitor the status of Ethernet switching are show
ethernet- switching interfaces and show ethernet- switching table. The first
command provides a view of which VLAN members are configured under which interface, as well as
the state of the interface (up or down). The forwarding state of the interface will show as either
blocked or unblocked.
The command show ethernet-switching table is useful to show which MAC addresses are
associated with a VLAN on an interface. The different type of MAC address conditions are static,
flood, and learn. The condition of static means the MAC address was manually configured. The
condition of learn means the MAC address was learned dynamically from a frame's source MAC
address. A condition of flood indicates that the MAC address is unknown, and is flooded to all
members.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-15
Advanced Junos Security

Summary
• In this content, we:
• Explained transparent mode security operations
• Configured Layer 2 Ethernet switching
• Implemented Ju nos Layer 2 security features

We Discussed:
Transparent mode security operations;
Layer 2 Ethernet switching; and
Junos Layer 2 security features.

Chapter 3-16 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Review Questions

1. What protocol family is required on an interface for

transparent mode?
2. What is the difference between the two interface
modes used in transparent mode?
3. What are some advantages of Ethernet switching?

©2013JunlperNetworl<S, tno.Alftl£bl> ....l\l.d . ···j: ��cijur:iTPefii Worldwide Education Services

'!2��= �-
'"'" Jun,pe, n,t I 17

Review Questions
1.

2.

3.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-17
Advanced Junos Security

Implementing Layer 2 Security Lab

• Configure and verify Ethernet switching behavior.
• Configure and verify transparent mode.
• Secure Layer 2 transparent mode traffic.

���?!l7�P�1filltt'�'
�;:,{ �l.:JD!P�
... Worldwide Education Services .,w., 1un,pe,net 1 18

Implementing Layer 2 Security Lab

The slide provides the objectives for this lab.

Chapter 3-18 • Ju nos Layer 2 Packet Handling and Security Features www.juniper.net
Advanced Junos Security

Answers to Review Questions

1.
The protocol family bridge is required on an interface for transparent mode.
2.
The two interface modes used in transparent mode are access mode and trunk mode. The difference between
them is that access mode allows for a single VLAN, whereas trunk mode allows for multiple VLANs.
3.
Ethernet switching allows individual ports on the SR.,'{ device to be configured for either routing or switching
mode. This approach offers greater flexibility to meet tbe needs of tbe network, as well as eliminates any
unneeded additional hardware, such as an external switch.

www.juniper.net Junos Layer 2 Packet Handling and Security Features • Chapter 3-19
Advanced Junos Security

Chapter 3-20 • Junos Layer 2 Packet Handling and Security Features www.juniper.net
JUntf2v�[
Advanced Junos Security

Chapter 4: Virtualization
Advanced Junos Security

Objectives

• After successfully completing this content, you will be

able to:
• Describe virtualization provided by Junos security devices
• Configure routing instances and share routes between
instances
• Configure logical systems and understand how to route
between logical systems
• Implement filter-based forwarding

We Will Discuss:
The benefits of virtualization with Junos security devices;
Configuring and sharing routes between routing instances; and
Filter-based forwarding (FBF).

Chapter 4-2 • Virtualization www.juniper.net

Advanced Junos Security

Agenda: VlrtuaUzation

�Virtualization Overview
• Routing Instances
• Logical Systems
• Filter-Based Forwarding

Virtualization Overview
The slides lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Virtualization • Chapter 4-3

Advanced Junos Security

Security Virtualization Overview

• Benefits of virtualization
• Lowers cost
• Lowers the requirement of physica I devices
• Groups applications for lower administrative overhead
• Common management interface
• Offers a more green solution
• Faster deployment
• Security can be virtualized too
• Consolidate firewalls using virtual routers

Why Virtualize?
In the early days of network computing, networks were mostly centralized. Those administrators
were ahead of their time. After an era of distributed computing, network administrators and
designers are once again centralizing resources, often in a data center type of environment. Along
with this trend has come the realization of virtualization. Beginning with server virtualization,
network devices are now becoming virtualized as well. Virtualization has many benefits, most of
which are associated with lower costs. Virtualization allows for a lower number of physical devices.
Fewer devices result in lower operational and administrative overhead. These multiple devices can
also often be administered with a single common management interface. Fewer devices require
deployment, making overall deployment faster and lowering the energy requirements.

Virtualized Junos Security

SRX devices, as well as other Junos network devices, allow virtualization in the form of separate
routing instances. We discuss routing instances in detail in this chapter, but essentially, they allow
you to provision separate logical entities within one device.

Chapter 4-4 • Virtualization www.juniper.net

Advanced Junos Security

Data Center Virtualization

Virtualization of the Data Center

The slide illustrates a sample data center design with security in the form of numerous individual
firewalls. By virtualizing the firewalls in the data center using routing instances, you can eliminate the
need for excessive firewall devices.

www.juniper.net Virtualization • Chapter 4-5

Advanced Junos Security

Multi-Tenant Design

SRX Series Clus1er

------0
Custl.
£ia
a:a
.-

,,a,1 � ,,,U_N_T_R_U_S_T....

'.ij
ZONE

Cust211············ it·�C........
:
inet.0

/
vlan3
Cust3 ·
�
·

Multi-Tenant Design
The slide shows an example of connecting multiple customers or remote office locations to a single
SRX Series chassis cluster through an aggregation switch. This design is often known as a
multi-tenant design, meaning multiple tenants (or customers) reside on the SRX device.
Note that the different customers are separated using virtual LANs (VLANs) in this example and that
each spoke site connects to its own virtual router (VR) by using routing instances. Also, note that for
scalability, we recommend that the multiple customers share the same zone and default routing
instance to connect to the Internet.
In this chapter, we discuss how to implement components that contribute to this multi-tenant design.

Chapter 4-6 • Virtualization www.juniper.net

Advanced Junos Security

Agenda: Virtualization

• Virtualization Overview
7 Routing Instances
• Logical Systems
• Filter-Based Forwarding

Routing Instances
The slide highlights the topic we discuss next.

www.juniper.net Virtualization • Chapter 4- 7

Advanced Junes Security

Routing Instance Review

• A routing instance is a unique collection of routing

tables, interfaces, and routing protocol parameters

Device Running the Junos OS

--Routmglnstance(master)
- ------- -- "' - - ---- - --, �-�----�
'Routinglnstance(cust-A) Routmglnstance(cust-B)
- --�--
inet.O cust-A.inet.O cust-B.inet.O
inet6.0 cust-A.inet6.0 cust-B.inet6.0
ge-0/0/00 ge-0/0/30 ge-1/0/0.0
ge-0/0/10 ge-0/0/40 ge-1/0/1.0
loO.O lo0.1 lo0.2
Default Route Default Route Default Route
OSPF OSPF OSPF

A Review of Routing Instances

The Junos operating system logically groups routing tables, interfaces, and routing protocol
parameters to form unique routing instances. The software logically keeps the routing information in
one routing instance apart from all other routing instances. The use of routing instances introduces
great flexibility, because a single device can effectively imitate multiple devices.

Chapter 4-8 • Virtualization www.juniper.net

Advanced Junos Security

Routing Instances, Zones, and Interfaces

• A strict hierarchical linkage:
• You assign logical interfaces to a zone
• You cannot assign a logical interface to multiple zones
• You can also assign logical interfaces to a routing instance
• You cannot assign a logical interface to multiple routing
instances
• All zone logical interfaces must belong to the same routing
instance

I nterface

�5 :t®J{& ��,;
1)2013Junlp&rNe1wori�, ln°'Allrlghbm•111•d �ur.iim�wo�dwide Education Services WWW jun,p" net I 9
'> "=�"""'- -

Routing Instances, Zones, and Interfaces

You can assign one or more logical interfaces to a zone. You can also assign one or more logical
interfaces to a routing instance. You cannot assign a logical interface to multiple zones or multiple
routing instances. You must also ensure that all of a zone's logical interfaces are in a single routing
instance. Violating any of these restrictions results in a configuration error as shown in the following
examples:
[edit]
user@srx# commit check
[edit security zones security-zone trust]
'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 already assigned to another zone
error: configuration check-out failed
Continued on the next page.

www.juniper.net Virtualization • Chapter 4-9

Advanced Junos Security

Routing Instances, Zones, and Interfaces (contd.)

[edit]
user@srx# conunit check
[edit routing-instances A interface]
•ge-0/0/0.0'
RT Instance: Interface ge-0/0/0.0 already configured under instance B
[edit routing-instances Bl
'interface'
Interface ge-0/0/0.0 is in more than one routing instance (latest A)
error: dcd_config_read fails to set parsing options
error: configuration check-out failed

[edit]
user@srx# conunit check
[edit security zones security-zone untrust]
'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 must be in the same routing instance as other interfaces in
the zone
error: configuration check-out failed

Chapter 4-10 • Virtualization www.juniper.net

Advanced Junos Security

Default Routing Instance

• Master routing instance includes inet. 0 route table

• Might include other route tables, such as inet6. O

user@srx> show route instance

Instance Type
Primary RIB Active/holddown/hidden
I master I forwarding
jinet.ol 3/0/1
� 4/0/0
Participating route tables; the presence of
Routing instance name
inet6. 0 table indicates 1Pv6 is in use.

Master Routing Instance

The Ju nos OS creates a default unicast routing instance named the master routing instance. By
default, the master routing instance includes the inet. o routing table, which the device uses for
IP version 4 (1Pv4) unicast routing. The software creates other routing tables, such as inet6.o,
adds them to their respective routing instance, and displays them when required by the
configuration. The Junos OS also creates private routing instances, which the device uses for internal
communications between hardware components.You can safely ignore these instances and their
related information when planning your network. The following sample output shows all default
routing instances:
user@srx> show route instance
Instance Type
Primary RIB Active/holddown/hidden
_juniper_privatel_ forwarding
_juniper_privatel_.inet.O 2/0/2
_juniper_privatel_.inet6.0 1/0/0

_juniper_private2_ forwarding
_juniper_private2_.inet.O 0/0/1

- master.anon- forwarding

master forwarding
inet.O 7/0/0

www.juniper.net Virtualization • Chapter 4-11

Advanced Junos Security

User-Defined Routing Instances

• You configure user-defined routing instances at the

[edit routing-instances] hierarchy level
• Typically used for filter-based forwarding, VPN services, and
system virtualization
• Routing instance types include:
[edit routing-instances instance-name)
user@srx# set instance-type ?
Possible completions:
forwarding Forwarding instance
12vpn Layer 2 VPN routing instance
mpls-internet-multicast Internet Multicast over MPLS routing instance
no-forwarding Nonforwarding instance
virtual-router Virtual routing instance
vpls VPLS routing instance
vrf Virtual routing forwarding instance

Note: Actual routinginstance types vary between platforms:

check product documentation for support information.

User-Defined Routing Instances

For added flexibility, the Junos OS allows you to configure additional routing instances under the
[edit routing- instances] hierarchy. You can use user-defined routing instances for a variety
of different situations, which provides you a great amount of flexibility.
Some typical uses of user-defined routing instances include FBF, which is sometimes referred to as
policy-based routing, Layer 2 and Layer 3 virtual private network (VPN) services, and system
virtualization. The following are some of the common routing instance types:
forwarding: Used to implement FBF for common Access Layer applications;
12vpn: Used in Layer 2 VPN implementations;
no-forwarding: Used to separate large networks into smaller administrative
entities;
virtual-router: Used for non-VPN-related applications such as system
virtualization;
vpls: Used for point-to-multipoint LAN implementations between a set of sites in a
VPN;and
vrf: Used in Layer 3 VPN implementations.
Note that the actual routing instance types vary between platforms running the Junos OS. Be sure to
check the technical documentation for your specific product.

Chapter 4-12 • Virtualization www.juniper.net

Advanced Junos Security

Configuration Example
• Routing instance configuration example:
[edit r:outing-instances lnew-instancelJ
user:@sr:x# show
---i
Routing instance name is user-defined

instance-type '"f?-i-r:t_u_a1- --r:--o -u... rj; •

t-e-,
l:,----------1 I Routing instance type
"" ..,.

inter:face ge-0/0/0.0; ::==::=::=::=::=::=::=::=::=::=::=::=::=:::::

inter:face ge-0/ 0/ l. O; Define interfaces under the
inter:face loO.1; [edit interfaces J hierarchy and
r:outing-options { reference them under their respective
static { routing instance.
r:oute 0.0.0.0/0 next-hop 172.26.25.1;

pr:otocols {
ospf {
ar:ea 0.0.0.0 {
inter:face ge-0/0/0.0;
inter:face ge-0/0/1.0;
inter:face loO.1;

-WniPer, WorldwideEducationServices '"''"')on,pecnet J 13

...u� �

Configuration Example: Routing Instances

The slide illustrates a basic routing instance configuration example.

www_juniper.net Virtualization • Chapter 4-13

Advanced Junos Security

Working with Routing Instances

• When working with routing instances, always

reference the instance name
user@srx> show interfaces terse routing-instance new-instance
Interface Admin Link Proto Local Remote
ge-0/0/ o. o up up inet 172.26.25.5/24
ge-0/0/ l.0 up up inet 172.25.182.5/24
loO.l up up inet 192.168.100.52 --> 0/0

user@srx> ping 172.26.25.1 rapid count 25 routing-instance new-instance

PING 172.26.25.1 (172.26.25.1): 56 data bytes
!!!! ! !! !!! !!! !!!!!!!!!!!!
--- 172.26.25.1 ping statistics
25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max /stddev = l.014/1.875/2.073/0.285 ms
Software automatically
user@srx> show route table new-instance.inet.0 creates IP unicast table

new-instance.inet.0: 7 destinations, routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * Both

0.0.0.0/0 *[Static/SJ 02: 06: 18

> to 172.26.25.1 via ge-0/0/0.0

Working with Routing Instances

Once you configure a routing instance and the device learns routing information within the instance,
the Junos OS automatically generates a routing table. If you use 1Pv4 routing, the software creates
an 1Pv4 unicast routing table. The name of the routing table uses the format
instance-name. inet. 0, where instance-name is the name of the routing instance within
the configuration. Likewise, if you use 1Pv6 within the instance, the software creates an IP version 6
(1Pv6) unicast routing table and it follows the format instance-name. inet6. o.
You can filter many of the common outputs generated through the command-line interface (CU)
show commands by referencing the name of a given routing instance. The first example on the slide
shows a practical way of viewing interfaces that belong to a specific routing instance.
You can also source traffic from a specific routing instance by referencing the name of the desired
routing instance. The next example on the slide shows this option in action with the ping utility.
To view a routing table associated with a specific routing instance, you simply use the show route
table table-name CU command, as shown in the last example on the slide. To view all routing
instances on your Junos device, you can issue the show route instance command.

Chapter 4-14 • Virtualization www.juniper.net

Advanced Junos Security

RIB Groups

• Use RIB groups to share routes between routing

tables
• Helpful in deployments such as:
• Virtual private networks
• Multicast networks
• Filter-based forwarding

G•Routes•B

Sharing Routes Between Routing Tables

The Junos OS provides a simple method for placing routing information in multiple tables
simultaneously. This method uses a Routing Information Base (RIB) group. Once defined within the
[edit routing-options] portion of the configuration hierarchy, you can apply a RIB group in
other sections of the configuration.

Some deployment scenarios require networking devices, such as a router, to know multiple routing
topologies. Example scenarios include VPNs, multicast networks, and FBF. In a VPN network,
multiple customer network topologies use a common infrastructure. These separate topologies
require the networking devices to maintain multiple different routing tables. In a multicast
environment, you might want unicast and multicast traffic to use different network links. These
separate forwarding topologies require separate routing tables. Finally, the Junos OS feature of FBF
allows for the forwarding of packets based on criteria other than the destination IP address within
the packet. The forwarding address might be different than the current active route in the routing
table. Again, a separate routing table is necessary.
Other options for sharing routes between routing instances exist. You can use the
instance- import, instance- export and auto-export configuration options to share
routes between multiple routing instances and eliminate the configuration of separate routing table
(or RIB) groups for each instance.

www.juniper.net Virtualization • Chapter 4-15

Advanced Junos Security

Defining and Applying RIB Groups

• Defined under the routing-options hierarchy
level
[edit routing-options]
user@srx# show The export-rib indicates table from
rib-groups { �---; where routes should be retrieved.
<rib-group-name>
export-rib <routing-table-name>;
The import-rib indicates tables in
import-ri b <routing-table-names>; ----1
which routes should be placed
import- policy <policy-name>;

----1 routes are installed in the routing table group.

The import-policy is used to control which

• Applied to routing protocols, interface routes, or both

[edit protocols ospf]
user@srx# set rib-group?
Possible completions:
<rib-group> Routing table group for importing OSPF routes

Defining a RIB Group

The Junos OS uses RIB groups to place route information into multiple tables on a Junos device. You
assign the name of the RIB group within the [edit routing-options] configuration hierarchy.
Within the rib-group configuration, two main configuration options exist. The import-rib
statement can list multiple routing tables, and informs the software where to place incoming route
information. The export-rib statement can list only a single routing table, and informs the
software where to extract route information. The import-rib statement must list the primary
routing table first within the configuration. The primary routing table is considered the routing table
where the routing information would ordinarily be placed without the presence of a RIB group.
Because you can list only a single routing table within the export-rib statement, and that single
routing table must be the primary RIB, the export-rib statement is frequently omitted from the
configuration.
Continued on the next page.

Chapter 4-16 • Virtualization www.juniper.net

Advanced Junos Security
RIB Group Application
Once you create a RIB group, you can apply it to other sections of the configuration. Potential
applications of a RIB group include interface routes, static routes, OSPF, IS-IS, RIP, BGP, P rotocol
I ndependent Multicast (PIM), and Multicast Source Discovery P rotocol (MSDP ).
A sample configuration that shares OSPF routes between the inet. o and test.inet. o routing
tables is shown in the following sample output:
[edit routing-options]
user@srx# show
rib-groups {
test {
import-rib [ inet.O test.inet.O l;

[edit protocols ospf]

user@srx# show
rib-group test;
area 0.0.0.0 {
interface ge-0/0/1.0;
interface loO.O;

We can verify that the OSPF routes were shared (from inet.O to test.inet.O) using the show route
table commands as shown in the following sample output:
user@srx> show route table inet.O protocol ospf

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

+ = Active Route, - = Last Active, * = Both

172.20.101.0/24 *[OSPF/150] 00:00:30, metric 0, tag O

> to 172.20.77.2 via ge-0/0/1.0
172.20.201.0/24 *[OSPF/150] 00:00:30, metric O, tag O
> to 172.20.77.2 via ge-0/0/1.0
192.168. 2.1/32 *[OSPF/10] 00:00:30, metric 1
> to 172.20.77.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 2wld 02:37:55, metric 1
MultiRecv

user@srx> show route table test.inet.0 protocol ospf

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

+ = Active Route, - = Last Active, * = Both

172.20.101.0/24 *[OSPF/150] 00:00:27, metric O, tag O

> to 172.20.77.2 via ge-0/0/1.0
172.20.201.0/24 *[OSPF/150] 00:00:27, metric O, tag O
> to 172.20.77.2 via ge-0/0/1.0
192.168.2.1/32 *[OSPF/10] 00:00:27, metric 1
> to 172.20.77.2 via ge-0/0/1.0
224.0.0.5/32 *[OSPF/10] 00:00:27, metric 1
MultiRecv

ww w.juniper.net Virtualization • Chapter 4-17

Advanced Junos Security

Routing Between Instances

• You can use a logical tunnel interface or a physical

interface to route between instances

Device Running the Junos OS

----------
Routing lnsrance(master)
inet.O custAinet.
- O
inet6.0 cust-Ainet6.0
----=-..,_ge-0/0/0O ge-l/O/O.O
LogJcal Connection
lt-0/0/00 1•-llii-------1 lt-O/O/O1
loO.O lo0.1
Default Route Default Route
OSPF OSPF

Physical Connection
>� � K ��sC 7f'"'11,1�
'! . ; (JU@I� �orldwideEducationServices ww.. 1un;p,rnel I 18
1' "' .,;.Jt;,S;;L,

Routing Between Instances

In addition to sharing routes between instances, you can also form logical or physical connections
between instances on the same Ju nos device and route between the connected instances.
To connect two routing instances with a logical connection, you configure a logical tunnel interface
for each instance. Then you configure a peer relationship between the logical tunnel interfaces, thus
creating a point-to-point connection. To configure a point-to-point connection between two routing
instances, you configure the logical tunnel interface using the 1 t-!EE_/PiE_/port format. A
sample logical tunnel interface configuration with two units-one for each instance-follows:
[edit interfaces lt-0/0/0]
user@Rl# show
unit O {
encapsulation ethernet;
peer-unit l;
family inet {
}
unit 1
encapsulation ethernet;
peer-unit O;
family inet;

Continued on the next page.

Chapter 4-18 • Virtualization www.juniper.net

Advanced Junos Security
Routing Between Instances (contd.)
When configuring logical tunnel interfaces, note the following:
You can configure each logical tunnel interface with one of the following encapsulation
types: Ethernet, Ethernet circuit cross-connect (CCC), Ethernet virtual private LAN
service (VPLS), Frame Relay, Frame Relay CCC, virtual LAN (VLAN), VLAN CCC, or VLAN
VPLS.
You can configure the IP, 1Pv6, International Organization for Standardization (ISO), or
MPLS protocol family.
You can configure only one peer unit for each logical interface.For example, unit O
cannot peer with both unit 1 and unit 2.
To enable the logical tunnel interface, you must configure at least one physical interface
statement.
In addition to logical tunnel interfaces, you can also use physical interfaces to connect and route
between routing instances. This implementation method typically requires two physical ports-one
for each instance.You define the physical interfaces as you normally would and simply associate
each interface with its respective routing instance under the [edit routing-instance
instance-name] hierarchy.
If you were utilizing physical cables to connect instances, you would expect the session table to show
two sessions (and it does).However, the same virtualization occurs with logical tunnels. In the
following example, a single Telnet session is established between hosts, which transits an
SRX device with a logical tunnel:
user@srx> show security flow session application telnet
Session ID: 57866, Policy name: intrazone-Juniper-SV/4, Timeout: 3394, Valid
In: 172.20.107.10/56290 --> 172.20.207.10/23;tcp, If: vlan.107, Pkts: 27, Bytes:
1568
Out: 172.20.207.10/23 --> 172.20.107.10/56290;tcp, If: lt-0/0/0.1, Pkts: 21,
Bytes: 1543

Session ID: 57867, Policy name: intrazone-ACME-SV/5, Timeout: 3394, Valid

In: 172.20.107.10/56290 --> 172.20.207.10/23,tcp, If: lt-0/0/0.2, Pkts: 27,
Bytes: 1568
Out: 172.20.207.10/23 --> 172.20.107.10/56290;tcp, If: vlan.207, Pkts: 21,
Bytes: 1543
Total sessions: 2

One more method exists to route between routing instances, using the next-table option of a
static route.This option has specific unidirectional applications and is not a generally preferred
method due to the possibility of looping traffic between routing instances on Junos stateless devices.
However, this method becomes more useful with Junos security devices because bidirectional flow is
enabled once the session is established.Recall that routing (and its reverse path) is set up in the
first packet path flow.

www.juniper.
net Virtualization • Chapter 4-19
Advanced Junos Security

Agenda: Virtualization
• Virtualization Overview
• Routing Instances
7 Logical Systems
• Filter-Based Forwarding

Logical Systems
The slide highlights the topic we discuss next.

Chapter 4-20 • Virtualization www.juniper.net

Advanced Junos Security

Logical Systems Overview

• Logical systems divide the SRX device into a

multi-tenant system

-Routing Instance NetworkConfig . NetworkCdnfig

security config Routing ln�nce , ROl!!lng config

T.iniPer
-�-�·""-'
""'"""" WorlclwideEduca1ionServ
-
ices WWWJun•pe<net I 21

An Overview of Logical Systems

Logical systems (LSYSs) essentially allow you to divide an SRX device into many secure device
contexts. Each LSYS has its own discrete administrative domain, logical interfaces, routing
instances, security policies, and other routing and security features. By turning a single SRX device
into a multi-tenant system, you can give various business entities private administration and use of
the resources of a particular LSYS.
As depicted on the slide, each SRX device that employs LSYSs has a master LSYS, which contains
the default configuration, and any user-configured LSYSs. Each of these user LSYSs has a subset of
resources, such as security configuration and routing configuration, that can be used.
Employing LSYSs into your environment can have many benefits. LSYSs can help curtail operational
costs by allowing you to reduce the number of physical devices that your company requires. This
consolidation of devices reduces your hardware costs and power expenditure. Then, LSYSs allow an
administrator to quickly provision resources and services. These services, which are typically spread
out across multiple network devices, are now converged on to one device. This convergence of
services allows you to configure a single device rather than many different discrete devices.

www.juniper.net Virtualization • Chapter 4-21

Advanced Junos Security

Logical System Licensing

• Logical systems are I icense-based features

• Available in increments of 1, 5, and 25
• 1 is available by default
• Reserved for the master LSYS at the root level
• Interconnect LSYS used for inter-LSYS communication
requires a license
• All members of a chassis cluster must have separate
licenses
• More LSYSs can be configured than installed licenses
• Additional LSYSs will not be usable

Logical Systems Are a Licensed Feature

Before you can implement LSYSs on your SRX device, you must first acquire the licenses to do so.
These LSYS licenses are available in increments of 1, 5, and 25, with a maximum of 32 licenses that
can be present on the system. Note that you can configure more LSYSs than licenses that are
present on the system. However, you cannot use them because they exceed the number of LSYSs
covered by the license.
By default, one LSYS license is installed on the SRX device, which allows the master LSYS to
function. This license and LSYS are reserved and count against the maximum number of licenses
and the maximum number of LSYSs, both of which are 32. The interconnect LSYS, which you must
use to facilitate inter-LSYS communication, also uses up one license and counts toward the
maximum LSYSs available. The interconnect LSYS and inter-LSYS communication are discussed in
more detail in later slides.
As it is with other licensed features in the Junos OS, you must have separate licenses for each
SRX device in a chassis cluster. For example, if you want to configure 25 LSYSs in a chassis cluster,
you must acquire 25 LSYS licenses for each node.
Continued on the next page.

Chapter 4-22 • Virtualization www.juniper.net

Advanced Junos Security
LSYSs Are a Licensed Feature (contd.)
To view the status for each LSYS, and its corresponding LSYS licenses, issue the show system
license status logical-system all command as a master administrator. LSYSs that are
functional display enabled in the license status field.
user@SRX> show system license status logical-system all
Logical system license status:

logical system name license status

root-logical-system enabled
User-LSYS-1 enabled
User-LSYS-2 enabled
interconnect-LSYS enabled

www.juniper.net Virtualization • Chapter 4-23

Advanced Junos Security

Administrative Roles (1 of 2)

• Master administrator role

• Created at the root level
• Configured witt1 super-user class permissions
• Manages master LSYS
• Rolling back a commit can only be done by master administrator
• Creates user LSYSs
• Configured at the [edit logical-systems] hierarchy level
• Creates login accounts for user LSYSs
• Creates interconnect LSYS if inter-LSYS communication is needed
• Creates and assigns logical interfaces to user LSYSs
• Configures IDP. AppTrack. AppFW. and ApplD features that can be
used inside of user LSYSs

G · Ul!JfJ�
-r""!c'1"�{'''.. "'<
!/OtldwideEducationServicu ..,,._., 1uniper n,t 1 �4
""= ==�"'

Two Types of Administrative Roles

Two types of administrators exist in regard to configuring LSYSs: master and user administrators. The
master administrator is responsible for the root LSYS and manages any user LSYSs. Any login
account that has permissions to configure the root LSYS can be a master administrator; usually this
login account is configured with super-user class permissions. A master administrator can issue
the rollback � command, where� is any whole number value, to go back to previously
committed configurations. A user administrator cannot perform this action because they do not have
the ability to change the configuration of LSYSs that they do not have access to, and rolling back a
previous configuration could have this effect.
It is a master administrator's job to create any user LSYSs, which are configured under the
[edit logical- systems] hierarchy level. Once you, as a master administrator, create a user
LSYS, you must assign appropriate resources through security profiles. (Security profiles will be
discussed in detail in the upcoming slides.) Then, you must configure other features, such as logical
interfaces, login accounts, Intrusion Detection and Prevention (IDP), AppTrack, AppFW, and ApplD.
The master administrator must also decide if an interconnect LSYS, which switches traffic between
the LSYSs, is necessary; the interconnect LSYS will be covered in detail in the upcoming slides.
It is also important to note that if syslogging or Simple Network Management Protocol (SNMP) is
required for a user LSYS, it must be configured at the root LSYS level.
Continued on the next page.

Chapter 4-24 • Virtualization www.juniper.net

Advanced Junos Security

Two Types of Administrative Roles (contd.)

The following output contains the configuration for the master administrator, master-admin, and
the user administrator, LSYSl. It is important to note that a user administrator is tied to an LSYS
through their assigned class. In the assigned class, the logical-system option specifies to which
LSYS a particular user administrator has access.
[edit system login]
user@SRX# show
class User-LSYS-1-class
logical-system User-LSYS-1;
permissions all;
}
user LSYSl {
uid 2006;
class User-LSYS-1-class;
authentication {
encrypted-password "$1$D3mtcSiX$eqg5jlNKly8BsidDaq/jo/"; ## SECRET-DATA

user master-admin
uid 2000;
class super-user;
authentication {
encrypted-password "$1$aWkXLed2$1PaJnA3iUlUKdXsnacQlLO"; ## SECRET-DATA

www.juniper.net Virtualization • Chapter 4-25

Advanced Junos Security

Administrative Roles (2 of 2)

• User administrator role

• Configures local user LSYS attributes
• CLI prompt displays username@hostname: logical-system­
name
• Configure previously allocated resources
• Routing protocols specific to user LSYS
• AppFW and AppTrack
• Logical interface attributes
• Many otl1er security and routing features
• Operational commands specific to user LSYS
• User administrators cannot view outputs from another user LSYS

The User Administrator Role

Once the master administrator has configured all the necessary components of a user LSYS , a user
administrator can log in to the SRX device. When a user administrator logs in, they only have access
to the configuration that is specific to their assigned LSYS. This is notable by the CLI prompt that
follows the format of username@hostname: logical-system-name, as shown in the following
example.
SRX(ttypO)

login: LSYSl
Password:

--- JUNOS 12.lRl.9 built 2012-03-24 12:52:33 UTC

LSYSl@SRX:User-LSYS-1>
In this example, it is plain to see that the LSYS1 user has access to the User-LSYS-1 LSYS.
Continued on the next page.

Chapter 4-26 • Virtualization www.juniper.net

Advanced Junos Security

The User Administrator Role (contd.)

Then, a user administrator can configure their LSYS within the constraints that a master
administrator has previously defined. However, it is important to keep in mind that there are a few
caveats of which you should be aware. First, a user administrator only has access to their LSYS
configuration and the outputs that pertain to that LSYS. However, they cannot add interfaces, or
logical units of an interface, that have not been previously assigned by a master administrator. Also,
if a logical tunnel interface is in use to facilitate inter-LSYS communication, the unit number cannot
be changed and the IP address must fall within the specified subnet that is already in place.
However, a user administrator can change the IP address to whatever is required on their local,
nonlogical tunnel, interfaces that are assigned to their user LSYS.

www.juniper.net Virtualization • Chapter 4-27

Advanced Junos Security

Security Profiles (1 of 2)

• What are LSYS security profiles?

• Defined by the master administrator
• Configured under the [edit system security-profile J
hierarchy level
• Up to 32 security profiles can be configured
• Multiple LSYSs can be applied to one security profile
• Limits system resources assigned to user LSYSs
• Flow sessions. CPU utilization. security policies. zones. address
books. NAT. and other system properties
• reserved-guarantees system resources
• maximum-allows the user LSYS to compete for free system
resources
• System defaults to the maximum allowed for a resource if the
maximum level for a articular resource is not set

Logical System Security Profiles

To assign resources to an LSYS, a master administrator must define a security profile, which is
configured under the [edit system security-profile] hierarchy level. In fact, if you do not
associate an LSYS with a security profile, you cannot commit the configuration. This caveat holds
true if you are configuring an interconnect LSYS in which you must define a blank security profile for
it to use. Also, you can only define a total of 32 security profiles per SRX device; however, you can
apply each security profile to multiple LSYSs.
When deciding which resources to define in a security profile, you must be aware of the reserved
and maximum options. Most resources have these options and they allow you to specify how much
of the system's resources are guaranteed, and for how much of the systems resources the LSYS can
compete. You must be aware of the default values for these options. If you do not specify anything for
a resource, the particular LSYS in question will not have any reserved resources, but it is allowed to
compete for resources up to the maximum value that is available for the entire system.
One item of special note is the CPU utilization resource that allows you to specify the upper limit of
CPU utilization for the entire system during normal operation, and the reserved CPU utilization for
each LSYS. Limiting this resource can be helpful in ensuring that one LSYS does not starve the other
LSYSs of CPU cycles if it is particularly busy.
Continued on the next page.

Chapter 4-28 • Virtualization www.juniper.net

Advanced Junos Security

Logical System Security Profile (contd.)

The following output displays the security profile configuration. Take special note of the blank profile
that is configured for the interconnect LSYS.
[edit system security-profile]
user@SRX# show
resources {
cpu-control;
cpu-control-target 85;
}
User-LSYS {
appfw-rule-set
maximum 5;
reserved l·
}
appfw-rule {
maximum 40;
reserved 5·
}
zone {
maximum 30;
reserved 100;

flow-session
maximum 30000;
reserved 2000;

cpu
reserved 5;
}
flow-gate {
maximum 1000;
reserved 50;

logical-system [ User-LSYS-1 User-LSYS-2 J;

interconnect-profile
logical-system interconnect-LSYS;

www.juniper.net Virtualization • Chapter 4-29

Advanced Junos Security

Security Profiles (2 of 2)

• Examining resource usage

•show system security-profile resource
• Specify resource or use the all-resources option
• Displays the used. reserved. and maximum resource values for
local LSYS
• Master administrator can add the logical-system option to
view resource usage of user LSYSs

user@SRX> show system security-profile flow-session logical-system User-LSYS-1

logical system name security profile name usage reserved maximum

User-LSYS-1 User-LSYS 0 0 20000000

Examining the Usage of Resources

To view which resources are in use, and by which LSYS if you are a master administrator, issue the
show system security-profile resource command. The output, as shown on the slide,
displays the current usage, reserved value, and maximum value of the flow session resource.

Chapter 4-30 • Virtualization www.juniper.net

Advanced Junos Security

Logical System Communication (1 of 3)

• lntra-LSYS communication
• Communication is contained within local user LSYS
• External device. or looped cable. can be used to route traffic
between LSYSs

Root-LSYS

User-LSYS-2

Intra-Logical System Communication

Configuring communication between hosts that connect to the same LSYS is simple: you configure
the LSYS as if it is a self-contained device. In the example on the slide, users that connect to
User-LSYS-1 can only communicate with other users that are connected to User-LSYS-1; these users
cannot communicate with users connected to User-LSYS-2.
To provide communication between the LSYSs, you can use an external device to provide the
inter-LSYS routing. You can also link the LSYSs by connecting two physical ports together and placing
each interface in the corresponding LSYS on the SRX device. Alternatively, you can configure an
interconnect LSYS as an internal switch to connect these LSYSs. We cover using an interconnect
LSYS to route traffic between LSYSs in the next couple of slides.

www.juniper.net Virtualization • Chapter 4-31

Advanced Junos Security

Logical System Communication (2 of 3)

• lnter-LSYS communication
• Requires the use of an interconnect LSYS
• VPLS is used to switch inter-LSYS traffic
• Interconnect LSYS uses one LSYS license
• Uses lt-0/0/0 interface to connect the root and user LSYSs
to the interconnect LSYS
• Use encapsulation ethernet on the lt-0/0/0 units for the
master and user LSYSs configuration
• Use encapsulation ethernet-vpls on the lt-0/0/0 units
used in the interconnect LSYS
• Only one lt-0/0/0 unit can be used per master or user LSYS
• Multiple lt-0/0/0 units can be used in the interconnectLSYS

-'--·JLJt1iPer
... -
,crd"�:ai,, "
WorldwldeEducationServices "'""Jun,pernet I 32

Using an Interconnect Logical System

As was alluded to earlier in this section, you can use an interconnect LSYS to allow inter-logical
communication between LSYSs without the communication leaving the SRX device. However, before
you begin configuring the interconnect LSYS, you must be aware of a few items. You can only
configure one interconnect LSYS, which uses an LSYS license. The other LSYSs (the root LSYS and
the user LSYS) connect to the interconnect LSYS using a logical tunnel interface. The interconnect
LSYS must then use a VPLS instance to switch the traffic between the LSYSs.
Also of note is how to configure the logical tunnel interfaces and some of the caveats involved in that
process. You can only apply one logical tunnel interface to the root LSYS and all other user LSYSs.
Next, you must configure these logical tunnel interface units with the encapsulation ethernet
statement, and the peer unit must match the corresponding logical tunnel interface unit in the
interconnect LSYS. In the interconnect LSYS, you must configure the logical tunnel interface units
with the encapsulation ethernet-vpls statement, and the peer units must match the
corresponding logical tunnel interface units that are present in the root or user LSYSs. Then, the
interconnect LSYS must have all the logical tunnel interfaces in a VPLS routing instance. Finally, you
must make sure that proper IP addresses are applied to the logical tunnel interfaces, and that the
proper routing is in place to ensure that communication can flow between the LSYSs.

Chapter 4-32 • Virtualization www.juniper.net

Advanced Junos Security

Logical System Communication (3 of 3)

Root-LSYS

I nterco nnect-L.SYS
lt-0/0/02 lt-0/0/0.4

User-L.SYS-1 User-L.SYS-2

192.168.0.2 �:;iD �:;J 8 192.168.1.2 8 192.168.5.2

� �ur:1 ·-1:--
er:'j Worldwide Education Services ..,.,.., Jun,p" aet 1 33
'- ·, -� ,h��

Visualizing the Inter-Logical System Communication

The slide depicts how the LSYSs use the logical tunnel interfaces to connect to the interconnect
LSYS. The following output displays the parts of the configuration that allow this communication to
occur.
user@SRX> show configuration

logical-systems {
User-LSYS-1 {
interfaces
ge-0/0/0
unit O
family inet
address 192.168.0.1/24;

lt-0/0/0 {
unit 3
encapsulation ethernet;
peer-unit 2;
family inet {
Continued on the next page.

www.juniper.net Virtualization • Chapter 4-33

Advanced Junos Security

Visualizing the Inter-Logical System Communication (contd.)

address 10.0.1.2/24;

}
ge-0/0/1
unit O
family inet
address 192.168.1.1/24;

routing-instances
VR-1 {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;

}
VR-2 {
instance-type virtual-router;
interface ge-0/0/1.0;
routing-options {
static {
route 0.0.0.0/0 next-table inet.O;

routing-options
static {
route 0.0.0.0/0 next-hop 10.0.1.1;
route 192.168.5.0/24 next-hop 10.0.1.3;

rib-groups {
VR-1-routes
import-rib [ VR-1.inet.0 inet.O];

VR-2-routes {
import-rib [ VR-2.inet.0 inet.0];

security
policies
default-policy
permit-all;

zones
security-zone User-LSYS-1 {

Continued on the next page.

Chapter 4-34 • Virtualization www.juniper.net

Advanced Junos Security
Visualizing the Inter-Logical System Communication (contd.)
}
User-LSYS-2 {
interfaces
lt-0/0/0
unit 5
encapsulation ethernet;
peer-unit 4;
family inet {
address 10.0.1.3/24;

ge-0/0/2
unit O
family inet
address 192.168.5.1/24;

routing-options
static {
route 0.0.0.0/0 next-hop 10.0.1.1;
route 192.168.0.0/24 next-hop 10.0.1.2;
route 192.168.1.0/24 next-hop 10.0.1.2;

security
policies

zones

interconnect-LSYS
interfaces {
lt-0/0/0 {
unit O
encapsulation ethernet-vpls;
peer-unit l;
}
unit 2 {
encapsulation ethernet-vpls;
peer-unit 3;
}
unit 4 {
encapsulation ethernet-vpls;
peer-unit 5;

routing-instances
vr-ic {
instance-type vpls;
interface lt-0/0/0.0;
Continued on the next page.

www.juniper.net Virtualization • Chapter 4-35

Advanced Junos Security
Visualizing the Inter-Logical System Communication (contd.)
interface lt-0/0/0.2;
interface lt-0/0/0.4;

interfaces
lt-0/0/0
unit 1
encapsulation ethernet;
peer-unit O;
family inet {
address 10.0.1.1/24;

}
ge-0/0/6
description "To the Internet";
unit O {
family inet
address 10.252.4.1/30;

security
policies

zones

routing-instances
VR-root {
instance-type virtual-router;
interface ge-0/0/6.0;
interface lt-0/0/0.1;
routing-options {
static (
route 0.0.0.0/0 next-hop 10.252.4.254;
route 192.168.0.0/24 next-hop 10.0.1.2;
route 192.168.1.0/24 next-hop 10.0.1.2;
route 192.168.5.0/24 next-hop 10.0.1.3;

Chapter 4-36 • Virtualization www.juniper.net

Advanced Junos Security

Logical System Route Instances

• Each LSYS has its own routing tables

user@SRX> show route instance
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.O 4/0/0
VR-root virtual-router
VR-root.inet.O 6/0/0

user@SRX> show route instance logical-system User-LSYS-1

Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.O 4/0/0
VR-1 virtual-router
VR-1.inet. O 2/0/0
VR-2 virtual-router
VR-2.inet.O 2/0/0

Logical System Routing Tables

Each LSYS has its own routing tables, such as the main routing instance table and any other routing
instance tables. Keep this fact in mind as you configure routing instances inside of an LSYS, because
RIB group configuration might be required.
As each user administrator logs in to their respective LSYSs, they can only see output specific to their
LSYSs, as mentioned on previous slides. However, a master administrator can use the
logical- system option to view routing instance information, as well as other operational
information, for each user LSYS.

www.juniper.net Virtualization • Chapter 4-37

Advanced Junes Security

Working with Logical Systems

• When working with LSYSs, always reference the

LSYS name
user@SRX> show route logical-system User-LSYS-2 table inet. 0

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

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/SJ 00:35:24

> to 10.0.1.1 via lt-0/0/0.5
10. 0.1.0/24 *[Direct/OJ 01:37:15
> via lt-0/0/0.5

user@SRX> ping lO. 0.1.1 rapid count 25 logical-system User-LSYS-1

PING 10.0.1.1 (10.0.1.1): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!
--- 10.0.1.1 ping statistics ---
25 packets transmitted, 25 packets r eceived, 0% packet loss
round-trip min/avg/max/stddev = l.866/2.499/3.128/0.440 ms

Working with Logical Systems

As mentioned in the previous slide, a master administrator can use the logical- system option,
followed by the LSYS name, to view outputs from user LSYSs. As the slide suggests, you can use the
logical- system option on many operational commands, such as the show route and ping
commands.

Chapter 4-38 • Virtualization www.juniper.net

Advanced Junos Security

Agenda: Virtualization
II
Virtualization Overview
• Routing Instances
• Logical Systems
7 Filter-Based Forwarding

��1i1riipe0
�=�-- - WorldwideEducationServices <,WWJUn>pe,net I 39

Filter-Based Forwarding
The slide highlights the topic we discuss next.

www.juniper.net Virtualization • Chapter 4-39

Advanced Junos Security

A Look at Traditional Routing

• Routing devices typically look only at the destination

address of a packet when determining the forwarding
next hop

172.25.0.0/24

172.25.1.0/24

Traditional Routing
In a typical routing scenario, a routing device looks only at the incoming packet's destination address
when determining the forwarding next hop. Although this approach works, it does not provide much
flexibility. We discuss FBF on the next slide, which provides you with flexibility for determining distinct
forwarding paths for traffic based on a wide variety of options.

Chapter 4-40 • Virtualization www.juniper.net

Advanced Junos Security

Introducing Filter-Based Forwarding

• FBF allows routing devices to forward traffic based on

additional criteria, such as a packet's source address

,------
L 1!._2:..25..:_ 03/'!;:
· � ....., .__...

L�!�:��:�..���.i • · · • · ·111>
172.19.25.1/32
\ ISPB )

Must be in
same zonel

Filter-Based Forwarding
FBF allows a routing device to make forwarding decisions based on criteria other than the
destination prefix. A match filter is created and applied to the interface on which traffic is received.
The Junos OS uses the filter to classify packets and determine their forwarding path within the router.
FBF is supported for 1Pv4 and 1Pv6.
As shown on the slide, you can use FBF for service-provider selection when you have Internet
connectivity provided by different Internet service providers (ISPs).
Note that unless you have enabled selective packe t b - ased filtering, the rules of first path session
creation apply. In the example on the slide, no guarantee exists that return traffic will use the same
interface as the initiating traffic. If the return traffic were to arrive at an interface assigned to a
separate security zone, the Junos OS would drop the traffic due to a zone mismatch. To avoid this
scenario, we recommend that both egress interfaces reside in the same security zone.
We illustrate the configuration and verification steps for FBF over the next several slides.

www.juniper.net Virtualization • Chapter 4-41

Advanced Junos Security

Configuring Filter-Based Forwarding

• FBF includes the following configuration tasks:

Defined under [edit firewall] hierarchy.

Matches traffic with respective routinginstance.

Defined under [edit routing-instances J

hierarchy. Creates unique routingtables to forward
traffic toward destination alongassociated path.
Defined under [edit routing-options J
hierarchy. Shares interface routes between instances
so directly connected next hops can be resolved.

Configuring Filter-Based Forwarding

The slide illustrates the three primary configuration tasks when implementing FBF. The subsequent
slides provide configuration examples for these stated configuration tasks.
If you are planning to implement FBF, you should know that source-class usage filter matching and
unicast reverse path forwarding (RPF) checks are not supported on interfaces configured for FBF. We
do not cover source-class usage or unicast RPF in this course. For more details on these topics, refer
to http://www.juniper.net.

Chapter 4-42 • Virtualization www.juniper.net

Advanced Junos Security

Step 1: Create and Apply a Match Filter

Note: The number of terms varies depending on the implementation.

[edit]
user@srx# show firewall
family inet {
filter fiiter-name
term term-name The filter matches on desired criteria

I -----!
from { with an action of routing-instance
ti......-
"'@""a"'t'"'c'"'b,..--c'""o""n'""d"".1....,,. o--,
ns instance-name.

then {
routing-instance gnstance-namel
I

,, ' ,:::0'-'�"'* r>;r'

�t.!Qi!l<llinlptrN!:tw;,de; 111 .. All ifgh .,.••,..4. •• Ytlf:lJ.ielf�Worldwide Educallon Services """' jun,pec net I 43
�:'\,�™"' "'�>M�

Step 1: Create and Apply a Match Filter

The slide shows a sample match filter configuration. Match filters are stateless firewall filters used to
classify traffic based on a desired match criteria, such as source IP address. You use an action of
routing-instance along with the name of the desired routing instance to which you want the
traffic forwarded. We define the routing instance in the next step, and we provide a sample
configuration on the next slide.
Although not explicitly shown on the slide, you must apply the match filter as an input filter on the
ingress interface where the traffic will be received. We provide a full configuration example, which
includes the definition and application of a match filter, in the case study later in this section.
Remember that the default action for traffic not specifically permitted through a firewall filter is
discard. Because of this default action, you should ensure that all traffic is accounted for in the
defined firewall filter. We highlight this point on a subsequent slide.

www.juniper.net Virtualization • Chapter 4-43

Advanced Junes Security

Step 2: Create the Routing Instance

INote: The number of routinginstances varies dependingon the implementation-!

[edit]
user@srx# show routing-instances
instance-name { The instance type used for filter-based
-----1
instance-type ,orwardingj forwardingis always forwarding.
routing-options {
static {
route 0.0.0.0/0 next-hop ip-address;

The instance includes routinginformation

(typically a default static route) that is
stored in the correspondingroute table.

Step 2: Create the Routing Instances

Once a packet meets the criteria defined within the match filter, that packet is evaluated against the
routing table associated with the routing instance specified in the match filter's action statement.
The software then forwards the packet to the next hop that corresponds to the destination address
entry in the routing table associated with the routing instance. You can include a default static route,
as shown in the example on the slide, or you can include less specific static routes. These static
routes typically use a forwarding next hop IP address, but can also direct traffic to a different routing
instance using the next-table option, as shown in the following capture:
routing-instances {
instance-name {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;

As illustrated on the slide, you create routing instances that specify the routing tables and the
destination to which a packet is forwarded at the [edit routing-instances] hierarchy level.
The instance type used for FBF is forwarding. The number of routing instances you define
depends on the number of next-hop forwarding paths you will use.

Chapter 4-44 • Virtualization www.juniper.net

Advanced Junos Security

Step 3: Create a RIB Group

[edit]
user@srx# show routing-options You must reference the correspondingtable
interface-routes {
rib-group inet group-name; for each of the participating instances.

rib-groups {
group-name
import-rib [ inet.O instance-name.inet.O ];

The sample configuration shares interface routes

between referenced instances. This requirement
can resolve directly connected next hops.

ge·0/0/1

Step 3: Create a RIB Group

In this step you create a routing table group that adds interface routes to the forwarding routing
instances used in FBF, as well as to the default routing instance inet.0. This part of the configuration
resolves the routes installed in the routing instances to directly connected next hops on that
interface. You create routing table groups at the [edit routing-options] hierarchy level.

The configuration example on the slide installs interface routes into the default routing instance
inet. o. as well as the instance-name. inet. o routing tables. You must specify inet. o as
one of the routing instances into which the interface routes are imported. If inet. o is not specified,
interface routes are not imported into the default routing instance.

www.juniper.net Virtualization • Chapter 4-45

Advanced Junos Security

Case Study: Topology and Objective

• Use FBF to balance Internet-bound traffic based on

source address on the R 1 device
• Traffic sourced from 172.25.0.0/24 should use ISP A
• Traffic sourced from 172.25.1.0/24 should use ISP B

Network A
1------
L 1_?:2_:._ �:°�l_:4�
2
"""' ........ R1 g,e-01012 __,__,..-:-;:;�
.1 2 0. 17 .2 0.0/30
----;� .1
NetworkB ge-0/0/1 0 ·

t -�! �--��:�;���-)
-,....172.20 1 0V3o
ge-o. · �-...,..,..;,..;.,
V0/3 -�
•• ••••...

Case Study: Topology and Objective

The slide provides you with the topology and objective for the case study.

Chapter 4-46 • Virtualization www.juniper.net

Advanced Junos Security

Case Study: Configure the Match Filter

[edit fir:ewall]
user:@Rl# show family inet filter ll!Y-match-fi1tex
ter:m match-subnet-A {
from {
sour:ce-addr:ess {
172.25.0.0/24;

then {
r:outing-instance ISP-A; ## 'ISP-A' is not defined

ter:m match-subnet-B
fr:om {
sour:ce-addr:ess Routing instances will be defined
172.25.1.0/24; in a subsequent step.

then {
r:outing-instance ISP-B; ## 'ISP-B' is not defined

.
'1)2013JuniperNe1P.orl��,ne.Allrtghtsreserved
-�s<·
.i,�4[�
' 1
11LJn1Per
""
WorfdwideEduca1ionServices
=; ,, ��=..i�c...<-�
l'
...Wl"']Un1pernet I 47

Case Study: Configure the Match Filter

The slide displays the sample match filter configuration for the case study.

www.juniper.net Virtualization • Chapter 4-47

Advanced Junos Security

Case Study: Apply the Match Filter

[edit intecfaces ge-0/0/1]
usec@Rl# show
unit O {
family inet The match filter is applied as an input
filtec {
filter on the ge-0/0/1.0 interface.
Im put my-match- tJ.ltec�
addcess 172.25.0.1/24;
addcess 172.25.1.1/24;

Case Study: Apply the Match Filter

The slide shows the application of the match filter defined on the previous slide.

Chapter 4-48 • Virtualization www.juniper.net

Advanced Junos Security

Case Study: Configure the Routing Instances

[edit routing-instances]
user@Rl# show
ISP-A {
instance-type EorwardingJ Instances use the fo rwa rdi ng instance type.
routing-options {
static {
route 0.0.0.0/0 next-hop 172.20.0.2;

ISP-B Instances include required

instance-type forwarding; routing information.
routing-options {
static {
route 0.0.0.0/0 next-hop 172.20.1.2;

Study: Configure the Routing Instances

The slide shows the sample configuration of the routing instances that will be used to establish
distinct forwarding paths within R1.

www.juniper.net Virtualization • Chapter 4-49

Advanced Junos Security

Case Study: Configure the RIB Group

[edit routing-options]
user@Rl# show
interface-routes {
rib-group inet my-rib-group;

rib-groups {
my-rib-group
import-rib inet.O ISP-A.inet.O ISP-B.inet.O ];

Reference the correspondingtable for each of the

participatinginstances to share interface routes.

ISP-A.inet.O
inet. 0 ge·0/0/1
ISP-B.inet.O

Case Study: Configure the RIB Group

The slide shows a sample RIB group, which is used to share interface routes. You must share
interface routes for next-hop resolution when forwarding traffic between routing instances.

Chapter 4-50 • Virtualization www.juniper.net

Advanced Junos Security

Case Study: Verify the Results (1 of 2)

• Verify that the required routing entries are installed:
user@Rl> show route table ISe-A.inet.O

ISP-A.inet.0: 9 destinations, 9 routes (9 active, O holddown, O hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/SJ 00:13:49

> to 172.20.0.2 via ge-0/0/2.0
172.20.0.0/30 *[Direct/0J 00:13:49
> via ge-0/0/2.0
172.20.0.1/32 *[Local/OJ 00:00:15
Local via ge-0/0/2 .0 Note: All interface routes exist in
172.20.1.0/30 *[Direct/OJ 00:13:49
the route table associated with
> via ge-0/0/3.0
172.20.1.1/32 *[Local/DJ 00:00:17 the ISP-Aroutinginstance. The
Local via ge-0/0/3.0 ISP-B. inet. o table has the
172.25 . 0.0/24 *[Direct/OJ 00:13:49 same routingentries.
> via ge-0/0/1.0
172.25.0.1/32 *[Local/OJ 00:00:17
Local via ge-0/0/1.0
172 .25 .1.0/24 *[Direct/OJ 00:13:49
> via ge-0/0/1.0
172 .25 .1.1/32 *[Local/OJ 00:00:17
Local via ge-0/0/1.0

Case Study: Verify the Results-Part 1

Once the configuration shown on the previous slides is committed, you can verify the entries in the
relevant routing tables using the show route table table-namecommand.The slide shows
the contents of the ISP-A. ine t. o routing table, which includes all interface routes for inet. o,
ISP-A. inet. o, and ISP-B. inet. o, along with the default static route defined for the routing
instance.
Continued on the next page.

www.juniper.net Virtualization • Chapter 4-51

Advanced Junes Security

case Study: Verify the Results-Part 1 (contd.)

The contents of the ISP-B. inet. o routing table are identical those for ISP-A.inet. o on the
slide and are shown in the following output:

user@Rl> show route table ISP-B.inet.O

ISP-B.inet.O: 9 destinations, 9 routes (9 active, O holddown, O hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/SJ 03:32:41

> to 172.20.1.2 via ge-0/0/3.0
172.20.0.0/30 * [Direct/OJ 03: 32:41
> via ge-0/0/2.0
172.20.0.1/32 *[Local/OJ 03:19:07
Local via ge-0/0/2.0
172.20.1.0/30 *[Direct/OJ 03:32:41
> via ge-0/0/3.0
172.20.1.1/32 *[Local/OJ 03:19:09
Local via ge-0/0/3.0
172.25.0.0/24 *[Direct/OJ 03:32:41
> via ge-0/0/1.0
172.25.0.1/32 *[Local/OJ 03:19:09
Local via ge-0/0/1.0
172.25.1.0/24 *[Direct/OJ 03:32:41
> via ge-0/0/1.0
172.25.1.1/32 *[Local/OJ 03:19:09
Local via ge-0/0/1.0

Chapter 4-52 • Virtualization www.juniper.net

Advanced Junos Security

Case Study: Verify the Results (2 of 2)

• Perform a traceroute from the 172.25.0.0/24 and
172.25.1.0/24 subnets:
user@Rl-A> traceroute 172.19.25.l source �72.25.0 .lOO!
traceroute to 172.19.25.l (172.19.25.1) from 172.25.0.100, 30 hops max,
40 byte packets
1 172.25.0.1 (172.25.0.1) 2.758 ms 2.822 ms 2.732 ms
2 !172.20.0.2!{172.20.0.2) 2.970 ms 3.108 ms 2.926 ms

B:JEJ � ��2��0�
host-A

0.100

host-B
,,l.i"lEJ r1+i2s:1.ai�·i
-- ............ "........... t
1100

user@Rl-B> traceroute 172.19.25.l source �12.25.1.100!

traceroute to 172.19.25.1 (172.19.25.1) from 172.25.1.100, 30 hops max,
40 byte packets
1 172.25.0.1 ( 172.25.0.1) 4.125 ms 2.586 ms 2.965 ms
2 lil2.2u.LL!(l72.20.1.2) 2.887 ms 4.312 ms 3.117 ms

zrn-�:s:s'"Y"" � =
�#-JJUf;llPer:L Woiiclwide Education Services ""'"' Jun,pe, net I SJ
�'"'"-"""" = - ··-"-
'i:)20i3JunlporNel"orl", lncc.M�pt;1-&,eived, ')

Case Study: Verify the Results-Part 2

As indicated on the slide, you can also perform a traceroute operation from a host on the subnets for
which FBF is being performed to verify that the traffic takes the correct forwarding path.
As stated earlier, our objective was to ensure that traffic sourced from the 172.25.0.0/24 subnet
used ISP A and traffic sourced from the 172.25.1.0/24 subnet used ISP B. The captures shown on
the slide, which display the traceroute results from hosts on the two previously mentioned subnets,
indicate that our FBF implementation works as designed.

www.juniper.net Virtualization • Chapter 4-53

Advanced Junos Security

Test Your Knowledge

• Using the previous example and configuration, what

would R1 do with traffic sourced from
172.26.5.0/24?
,------
1!23�0�/��
'""I
L
1_7_2 -.2-6.-5.-0/_
24_ 1 ..

t_112.25:1o;24 �

Rl drops all traffic en1eringthe ge-0/0/1.0 interface not sourced from the 172.25 .0 .0/24 and
17 2.25.1.0/24 subnets. You can include an additional term to accept all other traffic.

term else-accept {
then {
accept i

Test Your Knowledge

This slide is designed to make you think through the overall effects of the configuration implemented
in the preceding case study.
Continued on the next page.

Chapter 4-54 • Virtualization www.juniper.net

Advanced Junos Security

Test Your Knowledge (contd.)

Because the configuration used in the preceding case study only accepts traffic sourced from the
172.25.0.0/24 and 172.25.1.0/24 subnets, you must either modify the existing terms or include a
third term to accept traffic with a different source address. The following example illustrates the use
of a third term named else-accept which permits all other traffic:
[edit firewall]
user@Rl# show family inet filter my-match-filter
term match-subnet-A {
from {
source-address
172.25.0.0/24;

}
then {
routing-instance ISP-A;

term match-subnet-B
from {
source-address
172.25.1.0/24;

}
then {
routing-instance ISP-B;

term else-accept
then {
accept;

The else-accept term accepts all traffic that does not match the preceding terms. The system
forwards the traffic that matches the else-accept term out the appropriate egress interface
using the normal route lookup process based on the destination prefix. We recommend you use a
similar approach when implementing FBF so traffic is not dropped unintentionally.

www.juniper.net Virtualization • Chapter 4-55

Advanced Junos Security

Summary
• In th is content, we:
• Described virtualization provided by Junos security devices
• Configured routing instances and shared routes between
instances
• Configured logical systems and discussed how to route
between logical systems
• Implemented FBF

4)2013 Junlpe;Netwone, 1nc.A11 rt&IITT .,,,.ived. ..

·r,.:31J'ifi' n-c: ;Worldwide Education Services ww" 1un,per not I ss
ffi -- �••""""�� �-

We Discussed:
The benefits of virtualization with Junos security devices;
Configuring and sharing routes between routing instances;
Configuring and routing between logical systems; and
FBF.

Chapter 4-56 • Virtualization www.juniper.net

Advanced Junos Security

Review Questions

1. What are three benefits of virtualization?

2. What is the purpose of a forwarding type of
routing instance?
3. What is the purpose of a RIB group?
4. List three methods for routing between routing
instances.

.::r-·,�,,· "·- ..
©20i3JuniperNel"1orl:,, lncc.,,ll.nJlllls,.sel\led. ' r,;.�:JLJlllPe(i. Worldwide Educa1ionServices """' Jun,pe, net 1 ,7
• �... .._ ·""���= �

Review Questions
1.

2.

3.

4.

www.juniper.net Virtualization • Chapter 4-57

Advanced Junos Security

lmplementingJunos Virtual Routing Lab

• Implement virtual routers.

• Configure and monitor FBF.

Eili�=lilllilf��0f� Wor�dwide Education Services www ,un,per n,t I sa

Implementing Junos Virtual Routing Lab

The slide provides the objectives for this lab.

Chapter 4-58 • Virtualization www.juniper.net

Advanced Junos Security
Answers to Review Questions
1.
Virtualization helps promote lower costs by consolidating to fewer devices, providing a single management
interface, and lowering energy requirements.
2.
A forwarding type of routing instance is most commonly used for FBE
3.
A RIB group is used to share routes among multiple routing tables.
4.
To route between routing instances, you can configure logical tunnels, instance imports or exports, !UB
groups, physical interface connections, and the next-table static route option.

www.juniper.net Virtualization • Chapter 4-59

Advanced Junos Security

Chapter 4-60 • Virtualization www.juniper.net

JUnlev�[
Advanced Junos Security

Chapter 5: Advanced NAT Concepts

Advanced Junos Security

Objectives
• After successfully completing this content, you will be
able to:
• Describe the separation and interaction between NAT rules
and security policies
• Implement persistent NAT
• Demonstrate DNS doctoring
• Explain 1Pv6 NAT operations
• Describe how to use and configure NAT in situations beyond
simple edge-device implementations

E
'"""'
Networle} lnc"A �
· ltrlztrt,: �·Md �1 '� �rldwide Education Ser.ices w\<\•w Juniper net 1 2
MEL •

We Will Discuss:
The separation and interaction between Network Address Translation (NAT) and security
policy;
Persistent NAT;
Domain Name System (DNS) doctoring;
IP version 6 (1Pv6) NAT operations; and
Advanced NAT implementations.

Chapter 5-2 • Advanced NAT Concepts www.juniper.net

Advanced Ju nos Security

Agenda: Advanced NAT Concepts

�Operational Review
• NAT: Beyond Layer 3 and Layer 4 Headers
• DNS Doctoring
• 1Pv6 NAT
• Advanced NAT Scenarios

Operational Review
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Advanced NAT Concepts • Chapter 5-3

Advanced Junos Security

Expanded View of NAT Processing

Fi rst-pacl«lt path

Static
NAT
Dest
NAT
Security R::�: Source Services
Policy
NAT
NAT ALGs
=��
Table

NAT
Header
Services
ALGs
1-----------.
Rewrites

Ju nos OS Flow Module

Per Per
Packet Packet
Filter Filter
Per Per
Packet Packet
Policer Shaper

Network Address Translation

NAT allows a network device to modify IP address information in the Layer 3 header as a packet
traverses the device. Port Address Translation (PAT) allows a network device to modify the protocol
port information in the Layer 4 header. NAT can be used with or without PAT. The process of
modifying header information as it passes through a network device, sometimes called
masquerading, facilitates the use of private IP address ranges behind edge devices, allows different
networks that might be using overlapping address spaces to interact with each other, provides the
ability to hide network resources behind a network device, and so on.
Logical Packet Flow Review
The slide shows the logical packet flow used by security platforms running the Junos OS. The
software performs a session lookup to determine if an incoming packet belongs to an existing
session. If the packet does not match an existing session, the software creates a new session for it.
This process is referred to as the first-packet path. If the packet matches a session, the software
performs fast-path processing.
When the session entry is created during first-packet path processing, the session table is populated
with the end host's IP address and port information.This functionality is accomplished by allocating
any destination NAT before the route lookup (and subsequent policy evaluation) and allocating any
source NAT after the route lookup and policy evaluation have taken place. If static NAT is used during
first-packet-path processing, the software performs the static address translation, bypasses
destination NAT, and then performs a route lookup.
Continued on the next page.

Chapter 5-4 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security
Logical Packet Flow Review (contd.)
This approach makes it easier for system administrators to write and maintain security policies,
because they only need to work with the IP address and port information as the information appears
in the corresponding headers when they arrive at the respective interface. This operational design
allows great flexibility.
Subsequent packets of a flow are subject only to fast-path processing. During fast-path processing,
the software applies NAT, rewriting the appropriate fields in the Layer 3 and Layer 4 headers of the
packet. In addition to modifying the IP address, port information, or both, the corresponding
checksum must also be recalculated and rewritten.

www.juniper.net Advanced NAT Concepts • Chapter 5-5

Advanced Junos Security

NAT Rules and Security Policies

• NAT implementation requires:
• Appropriate NAT rule-sets
• Appropriate NAT rules
• Appropriate security contexts
• Appropriate security policies
• Use each appropriately
• Avoid over-inclusive security policies
• Compound matching is available in NAT rule-sets
• Compound matching is also available for match criteria
within NAT rules and security policies

NAT and Security Policy Interaction

NAT and security policies work together, but independently. No direct correlation exists between a
particular NAT rule and any particular security policy. However, traffic that is identified and processed
by any NAT rule must also match the conditions of a security policy with a perrni t action to transit
the security device.
NAT works together with security policies during first-packet path processing to determine which
sessions will be created and therefore which traffic will be allowed to transit the security device.

Each Has Its Own Place

Do not fall into the trap of relying on NAT rules to perform the role of security policies!
NAT rules and security policies each play an important role on an SRX device and both are needed
for a proper (and secure) implementation. Relying on either to fulfil the role of the other increases
the likelihood that the future addition of a NAT rule or security policy will create an unintentional
vulnerability.
The ability to use multiple match criteria in NAT rule-sets and security policy contexts, as well as for
match criteria in NAT rules and security policies, ensures the most flexible options available for
configuration and ongoing maintenance.

Chapter 5-6 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

NAT Rules Versus Security Policies

• NAT rules:
•Are configured under [edit security nat] hierarchy
• Use prefix references for source and destination matching
•Allow you the option of using application (port) information
• Security policies:
•Are configured under [edit security policies J
hierarchy
• Use predefined security objects for source and destination
matching
• Require a complete set of match criteria
• Source object. destination object. and application object

NAT Rules
All NAT configuration occurs in the [edit security natl hierarchy. Three types of NAT
configuration are available-source, destination, and static.
Within each NAT type hierarchy, a rule-set is used to identify the direction of a potential initiating flow
and the NAT rules that will be evaluated.

For static and destination NAT, which are evaluated before the route lookup (and therefore
before the egress interface is known), the direction is established using only a from statement.
One notable difference between the configuration of match criteria for NAT rules and match criteria
for security policies, is that NAT rules use IP prefixes to identify matching traffic and allow you to pick
and choose which match criteria to use.

Security Policies
All security policy configuration occurs in the [edit security policies] hierarchy.
Security contexts are used to identify the direction of a potential initiating flow and the security
policies that will be evaluated. All security contexts require a from- zone and a to- zone.
Security policies use predefined security objects for all match conditions and always require all three
match criteria-a source object, a destination object, and an application object. A predefined any
option exists that can be used for any of the required matches.

www.juniper.net Advanced NAT Concepts • Chapter 5- 7

Advanced Junes Security

NAT Rule-Set Configuration

[edit secu rity natl Use a NAT pool to specify
user@srx# show post-NAT IP and port
information.
destination {
ool Telnet-Server
a ddress 172.20.205.10/32;
Compound match criteria
rule-set available for NAT rule
from match criteria
rule To-telnet-server {
match {
source-address [ 19 _.J
- _ _ ____ - - - - - � -- ________________
destination-addr � e ss 1 72_ __1_ _8. 1. 2/ 3 2 ;_
destination-port 23;
NAT action to be performed
the n { on flows whose initiating flow
.-
""'"''" '"'""="' """"""""'"""",,..... """"--::""""""="'--:: """'"'"""' __.,,, matches the rule-set context
, st 1. nat 1. on n a t p=o ol T e 1 n e t S�e r v e r·',.....-
"'"'e
!j
and rule match criteria

Remember, an [edit security policies]

context and policy matching the initiating flow must
also be defined for a session to be established.

NAT Rule-Set Configuration

The slide shows a simple NAT configuration with several callouts.
Remember that all traffic must also match the conditions of a security policy with a permit action to
transit the security device.

Chapter 5-8 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Choosing the Correct NAT Implementation

• Destination NAT versus source NAT

• NAT type (and configuration hierarchy) indicate which fields
are subject to being rewritten as the initiating flow traverses
the device
• Direction of initiating flow is not relevant in choosing which
type of NAT to configure
• Direction of initiating flow will determine NAT rule-set configuration
( context) and security context configuration
• Direction of initiating flow will also determine match criteria
configuration within NAT rules and security policies
• Both destination NAT and source NAT can occur
simultaneously in the same initiating flow

Types of NAT
Remember that the terms destination NAT and source NAT identify which IP address (and optionally,
port information) will be changed in Layer 3 (and Layer 4) headers of session-initiating flows as they
transit the security device.
Destination NAT changes the contents of the destination IP address field, while source NAT changes
the contents of the source IP address field. Put another way, if the Layer 3 header of a particular
packet, as it arrived at the network device performing NAT, is compared to the Layer 3 header of the
same packet as it leaves the device, destination NAT will result in a new IP address in the destination
IP address field of the Layer 3 header whereas source NAT will result in a new IP address in the
source IP address field.
The most common implementations use destination NAT for access to internal resources from the
public side of an edge device, and source NAT when internal hosts communicate with resources
beyond the edge device. However, this usage is not always the case. For example, source NAT could
be utilized to initiate a session from the public side of an edge device to an internal resource, to
eliminate the need to equip the internal resource with a default gateway or other routing information.
By changing the source IP address field as the packet traverses the edge device to an IP address on
the same network as the internal resource, the ability to establish two-way communications between
end-hosts will be accomplished without creating additional security exposures.
It is possible to perform both destination NAT and source NAT on the same session.
Continued on the next page.

www.juniper.net Advanced NAT Concepts • Chapter 5-9

Advanced Junes Security

Types of NAT (contd.)

Static NAT is a special type of NAT that requires a one-to-one IP address allocation. PAT is not
supported for use with static NAT.
Static NAT is functionally comparable to destination NAT without PAT, but with implicit corresponding
source NAT functionality. This design allows the initiating flow of a session to occur in either
direction, which provides a simple configuration option when a one-to-one correlation exists between
hosts and IP addresses available on the other side of the network device performing NAT
translations. Static NAT would not be a plausible configuration option on a public-facing interface
with a single IP address.

Chapter 5-10 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Check Your Knowledge

• Which type of NAT is depicted below?

Initiating Flow
! Pre-NAT header !
s 1.1.1.1 61706 D 3.3.3.3 80

�
!Post-NAT header ! �
1.1.1.1 1617061 DH 10.0.0.3 n 80

• Does the graphic indicate which zones are involved in

this initiating flow?
• Can this type of NAT only be performed from a public
network toward a private network?

Which Type of NAT Is Depicted on the Slide?

The graphic shows the destination IP address was changed during the initiating flow from 3.3.3.3 to
10.0.0.3. This change indicates that destination NAT has occurred.

Does the Graphic Indicate Which Zones Are Involved in the Initiating Flow?
No!
Common implementations have created an assumed correlation between the type of NAT and the
direction of the initiating flow. The output shown does not indicate which zones are involved, nor
whether the interfaces involved are internal or external facing.

Can This Type of NAT Only be Performed from a Public Network Towards a Private
Network?
No!
One of the most common misconceptions about NAT, is that the type of NAT used is dependent on
whether the traffic is initiated from an inside-facing interface toward an outside-facing interface, or
from an outside-facing interface toward an inside-facing interface. While equipment from some
vendors might be limited in its implementations, the Junos implementation of NAT allows for
complete flexibility.

www.juniper.net Advanced NAT Concepts • Chapter 5-11

Advanced Junos Security

Agenda: Advanced NAT Concepts

• Operational Review
�NAT: Beyond Layer 3 and Layer 4 Headers
• DNS Doctoring
• 1Pv6 NAT
• Advanced NAT Scenarios

NAT: Beyond Layer 3 and Layer 4 Headers

The slide highlights the topic we discuss next.

Chapter 5-12 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

NAT-Great At What It Does, But...

• Some applications have problems with NAT

• Some applications require more than one concurrent
session between end hosts
• Information about additional sessions can be contained within the
packet payload
• Some applications require the initiating host to be aware of
its own post-NAT IP address and port (called the reflexive
transport address)
• Some applications require additional sessions be initiated
from the post-NAT side of a security device toward the
reflexive transport address
• Some applications rely on information contained within
encrypted payloads for authentication and integrity checks

NAT-Great At What It Does, But.•.

Simple NAT/PAT works well for what it is designed to do: modify the source and destination IP
addresses as needed in Layer 3 headers, and also modify the source and destination ports as
needed in Layer 4 headers. Many session-based applications rely only on the establishment of a
session between two endpoints and never need to be aware that NAT has occurred.
Other applications, however, rely on more than just session establishment. Some applications also
rely on the ability to create additional, related sessions. They might rely on the ability to read
information contained within the payload of the packet to learn information about those sessions.
They might even have a dependency on information contained within an encrypted payload. Some of
today's modern session-based applications even rely on the ability for additional sessions to be
initiated from the post-NAT side of a security device, toward a reflexive address-the IP address that
represents the original host when it passed through the most recent NAT device.

www.juniper.net Advanced NAT Concepts • Chapter 5-13

Advanced Junos Security

Address Persistency

1.1.1.1 I --
. -:::: . 2�2.2.2
rl
cEJ -1
"
Se..:....-
rve-r
!;]EJ··········· -·�--�-
·-·· """" ····················)\
�
�-�.__,______,
Initiating Host I
NAT Pool
15.0.0.1 �15.0.0.10

[edit security natl

user@srx# show
source {
address-persistent;

Flowl
Flow2

Address Persistency
Some applications expect related sessions to originate from the same source IP address. You can
enable the persistent address feature on a device to ensure that the device assigns the same IP
address from a source pool to a host for multiple concurrent sessions. The slide shows an example
of an initiating host that receives the same egress IP address from the NAT pool for each flow toward
an external server. At the [edit security nat source] hierarchy level, you can configure the
set source address-persistent command.

Chapter 5-14 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Persistent NAT

• Persistent NAT provides additional capability to assist

applications passing through a NAT device
• Formerly known as cone NAT
• Uses two predefined services:
• junos-stunandjunos-persistent-nat
• persistent-nat option:
• Applies only to source NAT
• Ensures all requests from a specific internal transport address are
mapped to the same reflexive transport address
• Allows new sessions to be initiated toward the reflexive transport
address

Persistent NAT
Persistent NAT, formerly identified as cone NAT by the Internet Engineering Task Force (IETF), is a
mechanism that further facilitates an end-host's ability to function from behind a security device (or
even several security devices) that perform NAT.
Persistent NAT should not be confused with address persistency, which allows session establishment
only in the direction of the source NAT initiating flow. Address persistency ensures that any
concurrent sessions from the same pre-NAT IP use the same post-NAT IP address supplied from the
source NAT pools configured on the device.
Whereas persistent NAT also ensures concurrent sessions use the same post-NAT IP address for a
source behind a NAT device, the primary difference is that persistent NAT also allows outside devices
to initiate traffic flows toward the device behind the network translator, using its reflexive transport
address.
Persistent NAT applies to address mappings on an external NAT device, and is configured for a
specific source NAT pool or egress interface. Also, persistent NAT supports Session Traversal Utilities
for NAT (STUN) client;server applications. In some cases, even new devices that have not
communicated with a translated host, might be able to initiate a session with the translated host.
The behavior depends on the persistent NAT configuration. The flexibility of persistent NAT is useful
for voice-over-IP (VoIP) applications, peer-to-peer applications, and others. The window opened by
persistent NAT to the outside world can be limited with a configurable timer.
Continued on the next page.

www.juniper.net Advanced NAT Concepts • Chapter 5-15

Advanced Junos Security

Persistent NAT (contd.)

The Junos OS supports two new services for use with persistent NAT and STUN as shown on the
slide. We discuss STUN and persistent NAT configuration more on subsequent slides.
Persistent NAT allows applications to use the STUN protocol when passing through network·
translators. It also ensures that all requests from the same internal transport address are mapped to
the same reflexive transport address (the public IP address and port created by the NAT device
closest to the STUN server). This mapping allows the deployment of voice over IP (VoIP) and
peer-to-peer applications with full protocol support and much more scalability.
Persistent NAT does not support the port overloading feature, which is default for interface-based
NAT, and it must be explicitly disabled.

Chapter 5-16 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Persistent NAT Types (1 of 3)

• any-remote-host
• Either side can initiate a session
• The source address of Host A is translated to the reflexive
address when Host A initiates a session to Server B
• Server B or any external host can initiate a session to the
reflexive address of Host A

4r,1��1-· · · · · · · · · }
1

��.)...... - -""""- .'

0
Host A I

Reflexive Address
15.0.0.1 Hoste

-�l��c.�orlclwideEducationServices ,wmjun,ounet 111

Any-Remote-Host NAT
You can configure three persistent NAT types on the SRX device. With all three types, all requests
from a specific internal IP address and port are mapped to the same external address. Differences
exist between the three types.
With the type any-remote-host, any user external to the SRX device can reach the internal host
by sending the packet to the external address used for translation.

www.juniper.net Advanced NAT Concepts • Chapter 5-17

Advanced Junos Security

Persistent NAT Types (2 of 3)

• target-host
• An external host can initiate a session to an internal host by
sending the packet to the reflexive address if the internal
host has previously sent a packet to the external host's IP
address
ealfJ···········•j j · Tc,·j···· ·········-��2222 j

'-"�.:�,:�
! 1.1.1.1 I

�� 15.0.0.1 CJ -
Hoste
1. HostAsends a packet to Server B.
2. After Server B has received a packet from Host A. then it can initiate a session to
HostA"s reflexive address .

Target-Host NAT
With the type target-host, any user external to the SRX device can reach the internal host by
sending the packet to the external address used for translation, but only if the internal host has
previously sent a packet to the external user's IP address.

Chapter 5-18 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Persistent NAT Types (3 of 3)

•target-host-port
• Allows an external host to initiate a session to the reflexive
address and port number only if the internal host has
previously sent a packet to the external host
-��·· 0��-
11.1.1.1:50601 a1E]· ··········>[E
..''"'·· -···················>
' 12.2.2.21
,:,,1:1

t/
��::�:: E
�� E
Q - !
�bmj .
,;==� � @ Serve�· B
HostA
ReflexiveAddress: Port
15.0.0.1:3604
�El .,
Hoste
1. HostA sends a packet to Server B.
2. After Server B has received a packet from Host A. then it can initiate a session to
HostA"s reflexive address. but must also include the reflexive address source port number.

Target-Host-Port
With the type target-host-port, any user external to the SRX device can reach the internal host
by sending the packet to the external address used for translation, but only if the internal host has
previously sent a packet to the external user's IP address and port.

www.juniper.net Advanced NAT Concepts • Chapter 5-19

Advanced Junos Security

Session Traversal Utilities for NAT

• STUN protocol
• Allows the originating host to learn its own reflexive
transport address
• Common requirement with VoIP and peer-to-peer applications
• Client/server protocol
• Provided by application
• Juniper Networks does not provide STUN client or server
• Server usually resides in the public domain
• Client role
• Discover whether it is behind a NAT security device
• Determine the type of persistent NAT binding used
• Learn its reflexive transport address ( closest to the STUN server)

Understanding the STUN Protocol

Many video and voice applications do not work properly in a NAT environment. For example, Session
Initiation Protocol (SIP), used with VoIP, encodes IP addresses and port numbers within application
data. If a NAT firewall exists between the requester and receiver, the translation of the IP address
and port number in the data invalidates the information.
Also, a NAT firewall does not maintain a pinhole for incoming SIP messages. This blockage forces the
SIP application to either constantly refresh the pinhole with SIP messages or use an Application
Layer Gateway (ALG) to track registration, a function that the gateway device might not support.
The STUN protocol, first defined in RFC 3489, Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs) and then later in RFC 5389, is a simple client-server
protocol. A STUN client sends requests to a STUN server, which returns responses to the client. A
STUN client is usually part of an application that requires a public IP address and/or port. Clients
reside in a pre-NAT environment, whereas STUN servers are usually attached to the public Internet.
Note that both the STUN client and STUN server must be provided by the application. Juniper
Networks does not provide a STUN client or server.
The STUN protocol allows a client to perform the following:
Discover whether the application is behind a network translator;
Determine the type of NAT binding used;
Learn the IP address and port bindings allocated by the network translator closest to
the STUN server.

Chapter 5-20 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Configuring Persistent NAT:

Source NAT Address Pool
(edit security nat]
user@srx# show
source {
pool From-Interndl-VoIP-Clients
addre5s {
LO. 0.1. 5/32;

rule-set Support-Internal-VoIP
from zone Trust;
to zone Un'i:.rust;
rule Al.low-VoIP-NAT
match {
source-address 172.20.96.0/20;
destination-address 172.20.192.0/19;

then {
source-nat
pool {
From-Internal -VoIP-Cl.ients;
persistent-nat {
perm.it target-host;
inactivity-timeout 180;

Configuring Persistent NAT with a Source Address Pool

The slide displays an example configuration of persistent NAT with a source address pool. In the
example, the type of persistent NAT used supports the target-host option.
The example configuration also displays the inactivity timer. This value, in seconds, represents the
amount of time that the persistent NAT binding remains in the device's memory when all the
sessions of the binding entry have expired. When the configured timeout is reached, the binding is
removed from memory. The default value is 300 seconds. The value can range from 60 through
7200 seconds. When all sessions of a persistent NAT binding have expired, the binding remains in a
query state in the SRX device's memory for the specified inactivity timeout period. You can explicitly
remove all or specific persistent NAT query bindings with the clear security nat source
persistent-nat-table command.
Optionally you can also configure static address bindings and the maximum number of sessions for
which a persistent NAT binding can be associated. The default number of sessions allowed is
30 sessions. These options are not shown in the example.

www.juniper.net Advanced NAT Concepts • Chapter 5-21

Advanced Junos Security

Configuring Persistent NAT:

Interface NAT
[edit security nat]
user@srx# show
source {
pool From-Interndi-VoIP-Ciients
address {
10. 0.1. 5/32;

Must ex licit! turn off rt-overloadin

interface
port-overloading off;

rule-set Support-Interndi-varP
from zone Trust;
to zone Untrust;
rule Al.iow-VoIP-NAT
match {
source-address 172.20.96.0/20;
destination -address 172.20.192.0/19;

then {
source-nat
interface
persistent-nat
perm.it any-remote-host;

Configuring Persistent NAT with a Source Address Pool

For interface NAT, you need to explicitly disable port overloading with the port-overloading
off option at the [edit security nat source) hierarchy level.
For the any-remote-host persistent NAT type, note that the direction of the security policy is from
external to internal. For target-host or target-host-port persistent NAT types, the direction of
the security policy is from internal to external.

Chapter 5-22 • Advanced NAT Concepts www.juniper.net

Advanced Ju nos Security

View Persistent NAT Allocation

user@srx> show security nat source persistent-nat-table ?
Possible completions:
all Show all persistent NA..T information
inter fac e Show p ersistent NAT information of th is interface
internal- i p Show persistent NAT information of internal IP and por t
pool Show persistent NAT information of th is pool
summary Show p ersistent NAT sununary info:r:mation

user@srx> show security nat persistent-nat-table all

P ersistent NAT Table Statistics:

binding total 131072
binding in use 1
enode to tal 1048576
enode in use
Internal Reflective So urce Type Left_time/ Curr_Sess_Num/
Source
In_IP In_Por t Ref_IP Ref Port N/J..T Pool Conf time Max_Sess_Num
NAT Rule

10.10.10.197 6000 200.200.200.241 6000 src-nat-by-shifting any-remote-host -/300 1/30

cone nat

user@srx> clear security nat source persistent-nat-tahle

World�deEducationServices w"w)onipernet 1 23
-·��� �·

Working with Persistent NAT in Operational Mode

The slide illustrates the command used to view the persistent NAT binding table. It also illustrates the
command used to clear the binding table.

www.juniper.net Advanced NAT Concepts • Chapter 5-23

Advanced Junos Security

NATandlPsec
• NAT can interfere with IPsec tunnels
• IPsec traffic is impacted when ESP or AH traffic transits a
NAT device
• IPsec traffic is subject to transiting intermediate NAT devices
outside the control of the local administrator

NAT and IPsec

NAT can interfere with IPsec traffic, causing IPsec tunnel establishment to fail. A virtual private
network (VPN) connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN.
The traffic that flows between these two points passes through shared resources such as routers,
switches, and other network equipment that makes up the public WAN. To secure VPN
communication while passing through the WAN, the two participants create an IP Security (IPsec)
tunnel.
NAT modifies the original header information of AH and ESP traffic. The IPsec endpoints run a sanity
check to verify that header information has not changed. When an IPsec endpoint detects a change,
the packet will be discarded. NAT can occur at any point along the delivery path, often beyond the
control of the local administrator. We next discuss how NAT modifies the authentication header (AH)
and Encapsulating Security Payload (ESP) headers.

Chapter 5-24 • Advanced NAT Concepts www.juniper.net

Adva nced Junos Security

NAT and AH
IPsec setup begins with a new
flow that uses UDP port 500 for
Ori!1inal IP packet IKE negotiations

Standard packet encapsulation is

used during the first steps of IKE
Phase 1 ne odations.

AH encapsulated packet (Tunnel Mode) AH adds two new headers in the

.-- ----------------------!final stages of IKE Phase 1
ne otiadons.
New AH Original packet
IP header header L3 L4 Payload

New IP, AH headerand payload:

Authenticated

Changes to the new IP header by

'--------------------t an intermediate NAT device will
cause the modified packet to fail
AH inte rit checks.

0
NAT and AH
The slide shows how NAT interferes with the AH pa cket header during Internet Key Excha nge (IKE) Phase
1 negotia tions. AH will not work with NAT and ca nnot be used when a n intermedia te NAT device is
present. AH adds two new headers in the fina l sta ges of IKE Pha se 1 negotia tions. AH does not encrypt
the header, but relies on it for authentica tion of the packet. Intermedia te NAT will cha nge the header,
and changes to the new IP header will cause the AH pa ckets to fail integrity checks.

www.juniper.net Adva nced NAT Concepts • Cha pter 5-25

Advanced Junes Security

NAT and ESP-Tunnel Mode

IPs ec s etup b egins with a new
flow that us es UDP port 500 for
Ori gina 11 P pacl43t IKE negotiations.

Standard packet encapsulation is

used during the firs t s teps of IKE
Phas e 1 ne tiations.

ESP encapsulated pacl43t(Tunnel Mode) ESP adds two n ew head ers and a
in the final stages of IKE
,---------------.....---------i footer
Phase 1 n e gotiacions.
N ew ESP Original packet ESP ESP
ESP he ad er do es not use po rts
IP h ead er h ead er L3 L4 Payload auth
and canno t not provid e a
m echanism for differentiating
between multiple flows involving
the same source IP and
ESP header and payload: ____. destination IP
Authenticated

NAT and ESP

The slide shows how NAT interferes with the ESP packet header in tunnel mode during IKE Phase 1
negotiations. The ESP header contains original IP information that can not be changed, or
authentication will fail. Original Layer 3 and Layer 4 headers are encrypted within the payload, but ESP
does not use port information. Intermediate NAT devices can not differentiate between multiple flows
involving the same source IP address and destination IP address. IPsec end-points will receive packets
from different IKE Phase 1 negotiations and will fail integrity check. NAT also interferes with ESP in
transport mode in the same way. NAT devices cannot differentiate between multiple flows involving the
same source IP address and destination IP address, and IKE negotiations fail the integrity check.

Chapter 5-26 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

NAT Traversal

• NAT-Tallows ESP traffic to transit NAT devices

• Encapsulates ESP header and payload inside UDP
• Allows intermediate NAT devices to differentiate between sessions
• Encapsulates inside UDP port 4500
• Enabled by default on all SRX devices
• You can disable NAT-T for IPsec with a CLI command:
[edit]
usec@scx# show security ike
gateway Serverl {
no-nat-tcaver:sal;

NAT Traversal
When NAT-Traversal (NAT-T) is enabled, UDP-encapsulated IPsec packets arriving and leaving the
SRX device look like standard UDP packets, and can transit NAT devices. NAT-T encapsulates the ESP
header and payload inside of UDP port 4500. NAT-T for IPsec is enabled by default on Junos security
devices. It can be disabled with the command set security ike gateway gateway-name
no-na t traversal.

www.juniper.net Advanced NAT Concepts • Chapter 5-27

Advanced Junes Security

NAf.,,J Encapsulation
Standard packet encapsulation is
Original IP packet used during the first steps of IKE
Phase 1 negotiations. I KE
payloads a re used to determine if
Original packet
NAT-T is available and re uired.
L3 L4 Payload

NAT-T ESP Encapsulation New UDP header (using UDP port

4500) provides a mechanism for
,-----------------------"'1differentiating between multiple
flows involving the same source
New NAT-T ESP IP and destination IP addresses.
IP header header
NAT-T header includes a non-ESP
ESP Pa load: Encr marker. which indicates traffic
that follows is ESP encapsulated
ESP header and payload: ---­ traffic and not standard IKE
Authenticated a load.

NAT-T Encapsulation
The slide shows how NAT-T encapsulates ESP traffic into UDP. The new UDP header (using UDP port
4500) provides a mechanism for differentiating between multiple flows involving the same source IP
address and destination IP address. The header includes a non-ESP marker, which indicates traffic
that follows is ESP encapsulated traffic and not the standard IKE payload_

Chapter 5-28 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Agenda: Advanced NAT Concepts

O
Operational Review
• NAT: Beyond Layer 3 and Layer 4 Headers
� DNS Doctoring
• 1Pv6 NAT
• Advanced NAT Scenarios

DNS Doctoring
The slide highlights the topic we discuss next.

www.juniper.net Advanced NAT Concepts • Chapter 5-29

Advanced Junos Security

DNS Doctoring

• Resolves DNS problems caused by NAT

• Translates the DNS A-record payload of a DNS reply packet
• Necessarywhen performing static NAT for publicly available Web
servers and the resolving DNS server when they are all located on
the same internal subnet
• Verifies tl1at DNS replies are consistentwith your static NAT
configuration
• Will not function if the DNS ALG is disabled
• The command set security alg dns doctoring none
disables DNS doctoring

DNS Doctoring Resolves DNS Problems Caused by NAT

DNS doctoring is a very similar concept to static NAT for the IP header of a packet, although DNS
doctoring has to do with translating the DNS A-record payload of a DNS response consistent with the
static-NAT scheme you have defined.
If your internal network has Web server hosts with private IP addresses, but you want them to be
accessible from a public network, you can set up static NAT translations so that a public host can
attempt to connect to each server by its public address. The SRX device sends a proxy-Address
Resolution Protocol (ARP) reply for the public address and then translates the header information to
the private IP address as the traffic traverses the security device. If the resolving DNS server for the
publicly available hosts is also located on the same internal network as the Web server hosts, and
also has a static public IP for handling requests that come in from the public network, then some
problems can occur to DNS. DNS doctoring handles DNS problems caused by NAT within the DNS
ALG.
When a public host requests the name resolution of the Web server public IP, the DNS server
responds with the DNS A-record of the Web server's private IP address because it is the only address
that the DNS server has for the Web server. DNS doctoring translates the DNS A -record within that
DNS response to be consistent with your static-NAT scheme, allowing the public host to contact the
Web server.
The DNS ALG must be enabled on the devices to perform DNS doctoring. DNS doctoring is enabled
by default as of Junos Release 10.1. To disable DNS doctoring, issue the command set security
alg dns doctoring none.

Chapter 5-30 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

DNS Doctoring Practical Example

/� abJ !9.9.9.9!
\
Internet
-------t HostA sends a DNS query
HostA
for www target. host.com.

The DNS server replies

with a DNS A-Record for
the Web server address
as 172.30.30.10 because
it is located on the same
internal subnet.
LAN
Web Server: www.target.host.com

®
DNS doctoring correctly
translates the DNS
A-Record payload from
172.30.30.10 to
90.90.90.10, allowing
Host A to reach the
Web server.

DNS Doctoring Example

The slide demonstrates a practical example for DNS doctoring. Host A, a public external host, sends
a DNS query for the Web server www.target.host.com. The DNS server replies with a DNS A-record for
the Web server's private IP address, because it is located on the same internal subnet as the Web
server. Without DNS doctoring, Host A would receive the private IP address for the Web server, and
would not be able to contact it. DNS doctoring corrects the DNS A-record within the payload of the
packet to match the static NAT public IP address for the Web server, allowing Host A to contact the
Web server.

www.juniper.net Advanced NAT Concepts • Chapter 5-31

Advanced Junos Security

Configuring DNS Doctoring (1 of 2)

• Verify that the DNS ALG is enabled

• It is enabled by default
user@srx> show sec�ty al.g status
A.LG Status
DNS Enabled
FTP Enabled
H323 Enabled
<snip>

• Enable proxy ARP for each static NAT public

IP address
[edit 5ecuri ty]
user@srx#: show nat p:roxy-arp
interface ge-0/0/2.0 {
address {
90. 90. 90. l.0/32;
90. 90. 90. l.5/32;

Verify the DNS ALG

The slide explains the configuration steps used for DNS doctoring operations. Verify that the DNS
ALG is enabled by issuing the operational mode command show security alg status.

Enable Proxy ARP

The SRX device must answer for each of the public-facing static NAT IP addresses on the interface
facing the external host. The slide demonstrates the configuration used to accomplish this task. In
this case, interface ge-0/0/2.0 is the public-facing interface toward the external host.

Chapter 5-32 • Advanced NAT Concepts www.juniper.net

Advaneed Junos Security

Configuring DNS Doctoring (2 of 2)

• Configure static NAT for the Web and DNS servers

[edit :::::ecurity]
u5er@srx# show nat
static {
rule-set static-nat
from zone DMZ;
rule Web-Server-Rule
match {
destination-address 172.30.30.10/32;
}
then {
static-nat prefix 90.90.90.10/32;

rule DNS-Server-Rule {
match {
destination-address 172.30.30.15/32;
}
then {
5tatic-nat prefix 90.90. 90.15/32;

• You must also define the appropriate security zones and

security policies to permit the traffic

Configure Static NAT for the Web and DNS Servers

Static NAT rules must be defined for external hosts to reach the Web server. The slide displays the
static NAT configuration for the Web server and DNS server IP addresses. The internal addresses for
these hosts are on the 172.30.30/24 subnet, and the external public-facing addresses are on the
90.90.90/24 subnet. You must also define the appropriate security zones, address-book entries,
and security polices to allow the traffic through the SRX device.

www.juniper.net Advanced NAT Concepts • Chapter 5-33

Advanced Junos Security

Verifying DNS Doctoring

• Use a ping test to verify DNS doctoring

• The public host can issue a ping test to verify that the DNS
A-record is correctly translated

Use a PING Test to Verify DNS Doctoring

You can verify that DNS Doctoring is working by testing it out with a ping test from the external host.
The slide screen capture shows a PING sent from Host A to www.target.host.com receives a DNS
response with the DNS A-record defined as 90.90.90.10, the public static NAT IP address, indicating
that DNS doctoring is working.

Chapter 5-34 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Agenda: Advanced NAT Concepts

• Operational Review
• NAT: Beyond Layer 3 and Layer 4 Headers
• DNS Doctoring
�1Pv6 NAT
• Advanced NAT Scenarios

1Pv6 NAT
The slide highlights the topic we discuss next.

www.juniper.net Advanced NAT Concepts • Chapter 5-35

Advanced Junos Security

Need for 1Pv6 NAT

• 1Pv4 address depletion

• NAT helps to continue using remaining 1Pv4 addresses
• Carrier-grade NAT solutions aid customers in 1Pv6
migrations: �� ,...c'�

: �:�:: �:{
lowm��"::)

• NAT444 Provider Access �·

Network
• OS-Lite . .

Q \ J-S'--
JE! � -- da:Eo�
0,>.
1Pv4 Network 1Pv6 Network 1Pv4and 1Pv6
Network

1Pv4 Address Depletion

With the rapid depletion of available IP version 4 (1Pv4) address blocks, service providers and large
enterprises will find it increasingly difficult to acquire new IP addresses. Broadband service
providers, such as DSL, cable, and wireless providers need new IP addresses to support new users.
Providing 1Pv6 addresses alone is often not workable because most of the systems that make up the
public Internet are still enabled to support only 1Pv4.

carrier-Grade NAT Solutions

NAT helps reduce the impact of 1Pv4 address depletion, as well as aid in 1Pv4 to 1Pv6 migration. A
Carrier-grade NAT (CGN) is a NAT solution that helps transition and provide network communication
between 1Pv4 and 1Pv6 addresses. CGN solutions that help customers accomplish this task include
NAT64, NAT46, and dual-stack lite (OS-Lite).

Chapter 5-36 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

NAT64

• NAT64 performs 1Pv6 host to 1Pv4 host translations

.;:ia•:�: : : : .:·:=·�:�:::� �>.1 I · r��;, &=-�:.°-�: '.-: :. ·:.��

12001 db8 1/64 ! Src 2001db8 1/64 Src 77 75/29

-� @\__, ,• V
I
Src 2001db8 8/64
<2) ,;,,,,;, · Src 8888/32

I "" "I
1Pv6Host Dst 2001db8.. 1/64 SRX Dst 777.5/29
- 1Pv4Server
. .

1. The 1Pv6 host 2001:dbS::1 sends a packet toward the server with the destination
address 2001:db8::8.
2. The SRX NAT64 configuration translates both the source and destination from the 1Pv6

-
addresses to the 1Pv4 addresses.
3. The 1Pv4 server replies to the 1Pv6 host's reflexive NAT address.
4. The SRX device performs reverse translation back to the originating host.

���!;;1:!��':·-���;; : •,: JUOIPer WorlclwideEducationServices

::
WWWJUO,pe,net I 37
:::-.""� -�-

NAT64 Supports 1Pv6 to 1Pv4 Host Translations

The slide illustrates the process flow for NAT64 operations.

www.juniper.net Advanced NAT Concepts • Chapter 5-37

Advanced Junos Security

NAT46

• NAT46 performs 1Pv4 host to 1Pv6 host translations

1. The 1Pv4 Host 7. 7. 7.5 sends a packet toward the server with the destination address
7.7.7.6.
2. The SRX NAT64 configllration translates both the source and destination from the 1Pv4
addresses to the I Pv6 addresses.
3. The 1Pv6 server replies to the 1Pv4 host's reflexive NAT address.
4. The SRX device performs reverse translation back to the originating host.

NAT46 Performs 1Pv4 to 1Pv6 Host Translations

The slide illustrates the process flow for NAT46 operations.

Chapter 5-38 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

1Pv6 NAT Requirements

• NAT64 and NAT46 requirements:

• Enable I Pv6 flow mode
• Requires a reboot of the SRX device
[edit security]
user@srx# show forwaz:ding-options
family {
inet6 {
mode flow-based;

• Configure proxy ARP and proxy NOP

[edit security nat] [edit security nat]
user@srx# show proxy-arp u:ser@srx:# show proxy-ndp
interface ge-0/0/2.0 { interface ge-0/0/1.0 {
address { address {
7.7.7.5/32; 2001,dbS,,8/128;

NAT64 and NAT46 Requirements

The slide explains configuration requirements common to both NAT64 and NAT46 implementations.
To perform 1Pv6 NAT, you must ensure that the SRX device is configured for 1Pv6 flow mode. Flow
mode for 1Pv6 is not enabled by default, and requires a reboot on the SRX device the first time it is
configured.
Proxy ARP and proxy NDP are needed for the SRX device to respond on behalf of the NAT addresses
used for translation. Proxy ARP is used for the 1Pv4 addresses, and proxy NDP is used for the 1Pv6
addresses. In this case, the 1Pv6 address 2001:dbS::8 is used for translation purposes, and
interface ge-0/0/1.0 is the interface facing the 1Pv6 host. The 1Pv4 address 7.7.7.5 is also used for
translation purposes, and interface ge-0/0/2.0 is the public-facing interface toward the global 1Pv4
server.

www.juniper.net Advanced NAT Concepts • Chapter 5-39

Advanced Junos Security

NAT64 Example Configuration

• Configure both source and destination NAT rules

[edit security nat] [edit security nat]
user@srx# show destination user@srx# show source
pool ipv6-dest-pool { pool ipv6-source-pool
addres::: { address {
js.s.B.B/32;l 7. 7. 7.5/29;

}
rule-set ipv6-dest { rule-set ipv6-source
from zone Trust; from zone Trust;
to zone Untrust; to zone Untrust;
rule ipv6-host-dest rule ipv6-host-source
match { match {
source-address 2001:dbS::10/128; source-address 2001:dbS::10/128;
destination-address 2001:dbB::8/64; destination-addressl 8. 8. 8. 8/32;1

then { then {
destination-nat { source-nat {
pool { pool {
ipv6-dest-pool; ipv6-source-pool;
} \
Because destination NAT is
performed first, the source NAT
match on destination­
address uses the same
ipv6-dest·-pool address

• Define the appropriate security zones and security policies

Configure Both Source and Destination NAT Rules

To perform NAT64, you must configure both source and destination NAT rules so that both source
and destination 1Pv6 addresses are translated to 1Pv4 addresses. The directional context for NAT is
established with from zone and to zone statements. Destination NAT occurs before source NAT,
and before a route-lookup takes place to determine the egress interface. The slide demonstrates the
NAT rule configuration for both source and destination NAT when performing NAT64. Note that the
source NAT rule match for destination-address uses the pool address that was applied during
destination NAT. You must also define the appropriate security zones, address-book entries, and
security polices to allow the traffic through the SRX device.

Chapter 5-40 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Verifying N.AT64

• Verifying NAT64 Operations

• Issue the command show security flow session to
verify NAT64 operations

user@srx> show security flow session

Session ID: 11232, Policy name: Allow-ipvG-Telnet/11, Timeout: 1788, Valid
In: 2 001:db8: :1/57707 --> 2001:db8::8/23;tcp, If: vlon.101, Pkts: 9, Bytes: 799
Out: 8.8.8.8/23 --> 7.7.7.5/21868;tcp, If: ge-0/0/2.0, Pkts: 8, Bytes: 589
Total sessions: 1

Verifying NAT64 Operations

The slide displays the output for the operational mode command show security flow
session that can be used to verify NAT64 operations. The output shows that the incoming 1Pv6
addresses have been successfully translated to the configured 1Pv4 addresses as they egress the
SRX device.

www.juniper.net Advanced NAT Concepts • Chapter 5-41

Advanced Junos Security

DS·Lite
• OS-Lite overview
• Allows providers to tunnel 1Pv4 traffic over an 1Pv6 network
• Providers can migrate to 1Pv6 without changing end-user software

DS-Lite B4 DS-Lite AFTR

1Pv4-in-1Pv6 Tunnel

These tunnels are

called softwires

Src: 5.5.5 5/29 Src: fec0::2 /64

Dst 8888/32 Dst 2 001:10 5/128

DS-Lite Overview
DS-Lite is a technology that enables Internet service providers to move to an 1Pv6 network while
simultaneously handling 1Pv4 address customers. Service providers can migrate to an 1Pv6 access
network without changing end-user software. The device that accesses the Internet allows 1Pv4
users to continue accessing 1Pv4 Internet content, and enables 1Pv6 users to access 1Pv6 content.
The DS-Lite architecture uses 1Pv6-only links between the provider and the user while maintaining
the 1Pv4 (or dual-stack) hosts in the end-user network.
The slide shows an example of DS-Lite operation. DS-Lite requires a 84 device, also known as a
softwire initiator, and an Address Family Transition Router (AFTR), also known as a softwire
concentrator. When an end-user sends an 1Pv4 packet to an external destination, OS-Lite
encapsulates the 1Pv4 packet in an 1Pv6 packet for transport into the provider network. These
1Pv4-in-1Pv6 tunnels are called softwires. Tunneling 1Pv4 over 1Pv6 is a simple alternative to
translation and can eliminate performance and redundancy concerns. In this example, the customer
premises equipment (CPE) DS-Lite home router functions as the softwire initiator to encapsulate the
1Pv4 packet and transmit it across the 1Pv6 tunnel to the softwire concentrator address 2001:10::5.
The SRX device functions as the softwire concentrator on the local interface used to terminate the
softwire connection. The SRX device then de-encapsulates the 1Pv4-in-1Pv6 packet and also
performs any configured 1Pv4-1Pv4 NAT translations. 1Pv6 packets originated by hosts in the
subscriber's home network are transported natively over the access network.
When the SRX device receives a responding 1Pv4 packet from outside the subscriber network, it
encapsulates the 1Pv4 packet in an 1Pv6 packet and forwards the packet to the end user's CPE
device.

Chapter 5-42 • Advanced NAT Concepts www.juniper.net

Advanced Ju nos Security

DS-Lite Configuration Steps

• Configure the AFTR softwire concentrator

[edit security]
user@srx# set softwires softwire-name <soft:i�i:re-name> softwire­
concentrator 2001:10: :5 softwire-type IPv4-in-IPv6

[edit security]
user@srx# show softwires
softwire-name <softwire-na m_e_>.....,.<��
� ..,
softwire-con centrator!2001: 10:: 5!;
softwire-type IPv4-in-IPv6;

• Verify OS-Lite
• The status indicates if a softwire connection is established
user@srx> shOW" security softwires
Softwire Name SC Address Status Number of SI connected
my-'iAo'it:-e 2001:10::5 Active 0

user@sLx> ShCM security softwires

Softwire Name SC Address Status Nwnber of SI connected
rnywire 2001:10::5 Connected 1

Configure the AFTR Softwire Concentrator

The slide configuration example shows how to configure a softwire concentrator on the SRX device.
The softwire concentrator 1Pv6 address can match an 1Pv6 address configured on a physical
interface or an 1Pv6 address configured on a loopback interface.

Verify OS-Lite
From operational mode, enter the show security softwires command to verify whether a
softwire connection is established. If a connection is established, the output displays a status of
connected, and the number of system integrator (SI) connected fields will increment.

www.juniper.net Advanced NAT Concepts • Chapter 5-43

Advanced Junos Security

Agenda: Advanced NAT Concepts

• Operational Review
• NAT: Beyond Layer 3 and Layer 4 Headers
• DNS Doctoring
• 1Pv6 NAT
�Advanced NAT Scenarios

Advanced NAT Scenarios

The slide highlights the topic we discuss next.

Chapter 5-44 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Local NAT: Routed Environment

• What is the problem?

user@host> telnet 3. 3 .3. 3
Trying 3.3.3.3 ...

[edit]
user@srx# rtu1 show security flow session
Session ID: 787, Poli cy- name: self-traffic-policy/1, Timeout: 2,
Valid .-�������-,
In: !172.2 0 .13.49/53060!--> 3.3.3.3/23;tcp, If: vlan.105, Pkts: 6,
Bytes: 336
Out: 3.3.3.3/23 -->!172.20.13.49/53060�tcp, If: .local..0, Pkts:
O, Bytes: 0
Total sessions: 1

Initiating flow pre-NAT -­

Initiating flow post-NAT - - ,

Using NAT Locally in a Routed Environment

Many times internal hosts will access internal resources also available to the public Internet using
DNS name resolution rather than with an IP address. Often this resolution will be an external DNS
resolution, which will resolve to the external IP address. NAT implementations can accommodate this
functionality, but require appropriate configuration.

www.juniper.net Advanced NAT Concepts • Chapter 5-45

Advanced Junes Security

Routed Environment Solution

• The problem:
• NAT is not occurring for the local host
• How to fix the problem:
•Add a NAT rule set so that local traffic
is evaluated for NAT
[edit security nat de3tination]
user@srx# show
pool Telnet-Server {
addre�s 172.20.17 .101/32;

rule-set To-Server {
from zone Trust;
rule To-Telnet-Server
match {
sour ce-address 172.20.13.0/24;
destination-address 3.3.3.3/32;
destination-port 23;

then {
destination-nat pool Telnet-Server;

The Problem
The slide answers the question from the previous slide, indicating which NAT problem is occurring. In
this case, the local host 172.30.13.49 is not being evaluated for NAT. The local zone was not
included in the rule-set context. Compound matching is allowed within the context, allowing the local
zone to be easily added to the context evaluation. Appropriate security policies allowing local traffic
also are required for a session to be established.

How to Fix the Problem

The NAT issue can be resolved by adding a destination NAT rule set for the local host traffic to match
telnet traffic destined for the telnet server's public IP address. The slide displays the correct
configuration needed to accomplish this task.

Chapter 5-46 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Local NAT: Switched Environment

• What is the problem?

user@host> telnet 3.3.3.3
Trying 3.3.3 .3...

[edit)
user@srx# run show security flow session
Session ID: 2148, Policy name: intrazone-ACME-SV/5, Timeout: 16,
r�)
\"'-
Valid ,------------,
In: !172.20.13.49/59302 -->!3.3. 3.3/23;tcp, If: vlan.205, Pkts: 2, .//
Bytes: )

2!
Out:f172.20.13.101/23 --> 172.20.13.49/59302�tcp, If: vlan.205, . . - :-.t_ .. ,
Advertising
/ L ?}E/.2? _:
:
Pkts: �, ytes: Li
Total sessions: 1

Initiating flow pre-NAT -­

Initiating flow post-NAT - -

Using NAT Locally in a Switched Environment

Most discussions about NAT operation focus on the changes made in the Layer 3 and Layer 4 ht!ader
information. Considering and accounting for the role Layer 2 communications can play in NAT
operations is also important. Remember, all delivery occurs at Layer 2.
Consider the situation of an internal resource that is accessible through a public-facing IP address in
the topology illustrated on the slide. The output on the slide shows a flow that originates with an
internal host on the same network as the post-NAT IP of the destination host. The local host is unable
to establish a telnet connection to the public IP address of the telnet server.

www.juniper.net Advanced NAT Concepts • Chapter 5-4 7

Advanced Junes Security

Switched Environment Solution

• The problem:
• The target host is responding directly to the
originating host on the same network
• How to fix the problem:
•Add a source NAT rule for the local host to
create a reverse NAT from the destination
host
[edit security nat source r ule-set Switched-Network]
user@srx# show
rule NAT-Return-Flow {
match {
source-address 172.20.13.0/24;
destination-address 0.0.0.0/0;
Zone:
then {
source-nat {
inte rface;

172.20.13.101
�Al/',:)' f":'(�_. � "-'- � _..,, 'V o/Yj;" ,>
©20iSluntper NetworJe, Inc.All rlghbreieMd�,,-.j> :;;� {,< � ·JUFllPer�� Worldwide Education Services WWW :uniper net I 48
� > t�L--.......-...""""Ji.S:t.t," • •=

The Problem
The slide answers the question from the previous slide, indicating which NAT problem is occurring.
The problem occurs when the destination host responds directly to the originating host's IP address.
The destination host uses ARP information rather than a route lookup to reach the originating host.
The originating host is not expecting a response from the post-NAT IP address and will drop the
packet.

How to Fix the Problem

The destination host must reply through the SRX device for the proper reverse NAT operations to
occur and the origination host to receive the expected return flow. The result is a double NAT
translation-both source and destination IP addresses are changed as they transit the device. The
slide also demonstrates a behavior called hairpinning, which allows two endpoints on the internal
side of a NAT device to communicate with each other, even if they only use each other's external IP
addresses and ports. This behavior is common with applications that also use persistent NAT. The
slide illustrates the proper NAT rule configuration to enable the destination host to respond to the
originating host.

Chapter 5-48 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Overlapping Address Space (1 of 2)

• Overlapping address space

• Can occur with acquisitions and mergers
• Is frequently used with So Ho deployments
• Allows similar network environments to be pushed to several
locations with minimal maintenance requirements

Overlapping Address Space

Overlapping IP addresses can sometimes occur in a network or company. Certain IP address ranges
might be commonly used in small office/home office (SoHo) environments. The slide shows the same
IP address subnet being used at both sites-Widget Shop A andWidget Shop B.

www.juniper.net Advanced NAT Concepts • Chapter 5-49

Advanced Junos Security

Overlapping Address Space (2 of 2)

• Implementation requirements:
• Requires two nonshared equal-size address blocks
• Can be virtual
• Double NAT
• Can be accomplished using static NAT
• Route information for remote side
• Required security policies
• Single device implementation requires routing instances

Overlapping Address Space Implementation Requirements

To combat the problem of overlapping address space, certain requirements must be met. The two
overlapping subnets must be nonshared equal-size address blocks. The two subnets are generally
routed to each other through direct links, or through an IPsec tunnel. The two subnets must be allowed
to communicate to each other through security policies. Double NAT can fix the problem of overlapping
subnets.

Chapter 5-50 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Double NAT
1- � s ]£1Jo§1§( JD I 10.2.100.100 I- - - - - - - 1

r - - - -{ �i )f2Xo§l§o_- ID I 10.1.100.100 l<-1

Static NAT Static NAT
.
I �� ! ��

�---------------------------------- �

Initiating flow pre-NAT -­

Initiating flow post-NAT - - ,

···········...

172.31100.100 172.31.100.100

Using Double NAT for Overlapping Address Space Implementations

The slide demonstrates how double NAT provides communication between the two sites. Nonexisting
virtual subnet ranges are chosen for the purposes of double NAT communication. The host at Widget
Shop A, 172.31.100.100, is translated to the virtual address 10.1.100.100 when its destination is the
virtual host address for the host at Widget Shop B. In this case, the virtual host IP address for Widget
Shop B is 10.2.100_100_ The host at Widget Shop B will be translated to 10.2.100.100 when its
destination is the host at Widget Shop A, 10.1.100.100.

www.juniper.net Advanced NAT Concepts • Chapter 5-51

Advanced Junos Security

Overlapping Address Space with

Two Security Devices

• Based on the previous slide, which SRX device is this

configuration from?
[edit security nat]
user@srx# sh.OW' I no-more
static {
rule-set Happy-Merger
from interface ge-0/0/2.0;
rule Translate-Overlapping-Addresses The virtual IP address used
match < by outside resources to
� ,.......a _,.�-,-�--:,...,...��.,.,,--,--,,--:-,�-,,·-
destination-address 10.1.0.0/16; ----­
reach internal resources
then,....�������������
--,
static-nat refix 172.31.0.0/16;
The IP address range being
used local!

� �!�;;,•'""'"• .+•Jq�IP� �orldwideEducationServices

�,.;5··.· www,un,pernet I s2

Overlapping Address Space Implementation Using Two Security Devices

The slide shows a configuration output for a static NAT rule used in double NAT, and asks from which
SRX device the configuration appears. The answer in this case, is that the configuration is applied
inbound on the SRX device at Widget Shop A. Based on the previous slide's diagram, the SRX device at
Widget Shop A will receive traffic with a destination of the 10.1.0.0/16 subnet. The SRX device then
translates that destination address back to the local 172.31.0.0/16 address so it can reach the local
host on the network.

Chapter 5-52 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Overlapping Address Space with a

Single Security Device
[edit security nat]
user@srx# show I no-more
static {
rule-set To---WidgetShopA
from routing-instance Widge"tShopB;
rule Frcm-WidgetShopB {
matc h { �-,..,..-��,,..,,....,,....,,...,,..,.,...,,...,
,-- ",-,---,-,--
rdestination-address 10.1.0.0/16;

then...-'����������������
tatic-nat prefix 172. 31. 0. 0/16;

The IP address range being

rule-set To---Wi dgetShopB {
used locall
from routing-instance Widge"tShopA;
rule Frcm-WidgetShopA {
match
�a....a���������������.L
destination-address 10.2.0.0/16;

then.....1:........ ����
., .....,.. -,,.,..........,.,,,.,......,,..,.......,.......,....,,.,...,,..,,/'
s tatic-nat prefix 172. 31. 0.0/16;

Overlapping Address Space Implementation Using a Single Security Device

The slide demonstrates overlapping IP address space at two sites, separated by a single security device
performing NAT. The slide shows the NAT rules used to perform the necessary translations for
bidirectional communication on each side.

www.juniper.net Advanced NAT Concepts • Chapter 5-53

Advanced Junes Security

Common SoHo Implementation

• SoHo implementations:
• A combination of source and
destination NAT is
recommended to allow
oversubscription of public
addresses in both directions
• Static NAT is allowed but
reduces the number of
addresses available for
oversubscription
• Static NAT is not a viable option
when only a single public IP
address is available

SoHo Implementation
A SoHo environment, by definition, has a very limited number of public IP addresses available­
sometimes a single public IP address. This limit makes NAT a common element in SoHo
implementations.
A combination of source and destination NAT is recommended to allow oversubscription of public
addresses in both directions. Static NAT can be used in Soho implementations, but it reduces the
number of addresses available for oversubscription because static NAT is a one-to-one mapping and
port translation is not available. Static NAT is not a viable option when only a single public IP address
is available-unless, of course, only a single host exists behind the security device.
Remember to configure proxy ARP for IP addresses that are part of the same subnet as the
public-facing interface, but are not physically assigned to the interface.

Chapter 5-54 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Multihomed SoHo Environments

• Multihoming adds redundancy

• NAT and filter-based forwarding
can provide redundancy
between ISPs
• Compound matching is available
in NAT rule sets and security
policy match criteria

Multihoming Adds Redundancy

Frequently, organizations will use multiple Internet service providers (ISPs) to provide redundancy.
SoHo implementations might be assigned a relatively small block of addresses from more than one
ISP. The NAT implementation should account for this redundancy. The following configuration
addresses redundancy for both source and destination NAT. Certain factors will dictate which path is
the preferred route to the Internet (and from the Internet to internal resources). but now NAT is ready
to handle any of the possibilities. The following configuration uses a combination of multiple
routing-instances with filter-based forwarding and a qualified-next-hop on the default route.
The Trust zone network is 192.168.13.0/24 on ge-0/0/0, and the DMZ zone network is
192.168.17.0/24 on ge-0/0/1. The ISP_A zone network is 1.1.1.0/24 on fe-0/0/6, and the ISP_B
zone network is 2.2.2.0/24 on fe-0/0/ 7. The Trust and DMZ zones should egress out ISP_A with
source NAT. If the ISP_A interface goes down, then the Trust and DMZ zones should egress out
ISP_B instead with source NAT. If the ISP_A interface returns, then the Trust and DMZ zones
should revert back to using ISP_A again. ISP_A and ISP_B will allow destination NAT for the Web
server in the DMZ zone.
Continued on the next page.

www.juniper.net Advanced NAT Concepts • Chapter 5-55

Advanced Junes Security

Multihoming Adds Redundancy (contd.)

[edit]
user@srx# show
<Snip>
interfaces {
ge-0/0/0
unit O
family inet
address 192.168.13.1/24;

ge-0/0/1
unit O
family inet
address 192.168.17.1/24;

fe-0/0/6
unit O
family inet {
filter {
input ISP_A-in;

address 1.1.1.2/24;

}
fe-0/0/7
unit O
family inet {
filter {
input ISP_B-in;

address 2.2.2.9/24;

routing-options
interface-routes
rib-group inet inside;
}
static {
route 0.0.0.0/0 {
next-hop 1.1.1.1;
qualified-next-hop 2.2.2.1 {
preference 10;

rib-groups
inside
import-rib [ inet.0 TRUST-VRF.inet.0 INSIDE.inet.0 ISP B.inet.0];

Continued on the next page.

Chapter 5-56 • Advanced NAT Concepts www.juniper.net

Advanced Junes Security

Multihoming Adds Redundancy (contd.)

security {
nat {
source
rule-set interface-nat-out {
from routing-instance INSIDE;
to routing-instance [ ISP B default];
rule interface-nat-out { -
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat
interface;

destination
pool WebServer
address 192.168.17.101/32;

rule-set ISP_A-to-DMZ {
from interface fe-0/0/6.0;
rule ISP_A-http-in {
match {
source-address 0.0.0.0/0;
destination-address 1.1.1.6/32;
destination-port 80;
}
then {
destination-nat pool WebServer;

rule-set ISP_B-to-DMZ {
from interface fe-0/0/7.0;
rule ISP_B-http-in {
match {
source-address 0.0.0.0/0;
destination-address 2.2.2.13/32;
destination-port 80;
}
then {
destination-nat pool WebServer;

proxy-arp
interface fe-0/0/6.0
address {
1.1.1.6/32;

Continued on the next page.

www.juniper.net Advanced NAT Concepts • Chapter 5-57

Advanced Junos Security
Multihoming Adds Redundancy (contd.)
interface fe-0/0/7.0
address {
2.2.2.13/32;

firewall
filter ISP A-in
term 1-(
from {
destination-address
1.1.1.0/24;

}
then {
routing-instance TRUST-VRF;

term 2
then
accept;

filter ISP B-in

term 1 {
from {
destination-address
2.2.2.0/24;

}
then {
routing-instance TRUST-VRF;

term 2
then
accept;

routing-instances
TRUST-VRF {
instance-type forwarding;
routing-options {
static {
route 192.168.13.0/24 next-hop 192.168.13.1;
route 192.168.17.0/24 next-hop 192.168.17.1;

Continued on the next page.

Chapter 5-58 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security
Multihoming Adds Redundancy (contd.)
INSIDE {
instance-type virtual-router;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
routing-options {
interface-routes {
rib-group inet inside;
}
static {
route 0.0.0.0/0 next-table inet.O;

ISP_B
instance-type virtual-router;
interface fe-0/0/7.0;
routing-options {
interface-routes {
rib-group inet inside;
}
static {
route 0.0.0.0/0 {
next-hop 2.2.2.1;
qualified-next-hop 1.1.1.1 {
preference 10;

www.juniper.net Advanced NAT Concepts • Chapter 5-59

Advanced Junos Security

Summary
• In this content, we:
• Described the separation and interaction between NAT rules
and security policies
• Implemented persistent NAT
• Demonstrated DNS doctoring
• Explained 1Pv6 NAT operations
• Described how to use and configure NAT in situations
beyond simple edge-device implementations

We Discussed:
NAT rules and security policies operation and interaction;
Persistent NAT;
DNS doctoring;
1Pv6 NAT operations; and
Advanced NAT implementations.

Chapter 5-60 • Advanced NAT Concepts www.juniper.net

Advanced Ju nos Security

Review Questions

1. What are two key differences between address

persistency and persistent NAT?
2. How does NAT-T resolve the NAT traversal problem?
3. Which type of NAT is required for internal hosts in a
switched environment to reach internal resources
using public-facing IP addresses?
4. Which type of NAT would you configure to connect
two organizational units with overlapping address
space?

Review Questions
1.

2.

3.

4.

www.juniper.net Advanced NAT Concepts • Chapter 5-61

Advanced Junos Security

Advanced NAT Implementations Lab

• Configure and monitor NAT in situations beyond

simple edge-device implementations.
• Configure and verify NAT64 and NAT46 operations.

Advanced NAT Implementations Lab

The slide provides the objectives for this lab.

Chapter 5-62 • Advanced NAT Concepts www.juniper.net

Advanced Junos Security

Answers to Review Questions

1.
Address persistency allows sessions to be allocated in the same direction as the source NAT initiating flow. It
ensures that all concurrent sessions use the same IP address. Persistent NAT allows sessions to be allocated
in the opposite direction of the source NAT initiating flow.
2.
NAT-T encapsulates an ESP header and payload within a UDP header. The new packet appears as a standard
IKE packet to intermediate NAT devices. When the destination host processes the packet, the NAT-T
header indicates that an ESP packet follows rather than an IKE packet. During IKE negotiation, NAT-T also
passes additional information that can be used to verify packet authenticity.
3.
Both destination and source NAT are required for an internal host in a switched environment to reach
internal resources using the public-facing IP address. Without source NAT, the destination host will reply
directly to the originating host. The originating host will drop the return flow packets because they do not
originate from the expected transport address.
4.
A NKf implementation to accommodate overlapping address spaces requires double NAT and a one-to-one
IP address allocation. Static NAT is an easy way to accomplish both of these goals.

www.juniper.net Advanced NAT Concepts • Chapter 5-63

Advanced Junos Security

Chapter 5-64 • Advanced NAT Concepts www.juniper.net

JUntE:�f
Advanced Junos Security

Chapter 6: IPsec Implementations

Advanced Junos Security

Objectives

• After successfully completing this content, you will be

able to:
• Differentiate and configure standard point-to-point VPN
tunnels and hub-and-spoke VPNs
• Monitor the operations of the various I Psec VPN
implementations
• Describe public key cryptography for certificates

We Will Discuss:
Differentiating and configuring standard point-to-point virtual private network (VPN)
tunnels and hub-an d -spoke VPNs;
Monitoring the operations of the various IP Security (IPsec) VPN implementations; and
Public key cryptography for certificates.

Chapter 6-2 • IPsec Implementations www.juniper.net

Advanced Ju nos Security

Agenda: IPsec Implementations

�Standard VPN Implementations Review

• Public Key Infrastructure
• Hub-and-Spoke VPNs

Standard VPN Implementations Review

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net IPsec Implementations • Chapter 6-3

Advanced Junos Security

IPsec: Review
• IPsec VPNs consist of two major steps:
1. Tunnel establishment: Establishes a secure tunnel and
parameters that define secure traffic
• Manual: Set all I KE parameters manually
• Dynamic: Uses IKE pre-defined options to define parameters
2. IPsec traffic processing: Protects traffic between the two
tunnel endpoints by using security parameters defined in
the tunnel establishment step

IPsec: A Two-Step Process

IPsec VPNs consists of two major steps:
1. IPsec tunnel establishment: You can manually establish an IPsec tunnel or the Internet
Key Exchange (IKE) protocol can do it dynamically.
2. IP traffic processing: During this step payload protection takes place using security
parameters defined in the tunnel establishment phase.

Chapter 6-4 • IPsec Implementations www.juniper.net

Advanced Junos Security

Step 1: Tunnel Establishment Using IKE

• IKE provides increased functionality in secure
environments
• Uses UDP, Port 500
• Establishes:
• Security parameters (security associations)for creating IPsec VPN
tunnels
• Negotiates proposals containing encryption and authentication
algorithms
• Creates encryption and authentication keys automatically, which
provides the ability to rekeyfrequently
• Support for I KE termination in virtual routers

Step 1: Tunnel Establishment Using Internet Key Exchange

IKE is a secure key management protocol used by IPsec to have information exchanged in a secure
and dynamic manner with little or no intervention. The IKE proposal exchange is Phase 1 of the IPsec
tunnel establishment process. The following attributes exchange between IPsec peers as a part of
the IKE process:
Encryption algorithm;
Hash algorithm;
Authentication method; and
Diffie-Hellman group.
Once IPsec peers negotiate these attributes, they secure future attribute exchanges used to protect
data. IKE exchanges authenticate using one of the following methods:
Preshared keys;
Digital signatures; or
Public key encryption.
When configuring IKE, you now have the option to terminate IKE messages directly inside a virtual
routing instance for route-based and policy-based IPsec VPNs that use static addressing. This option
is also available for IPsec VPNs in which one side of the VPN uses dynamic addressing. However, the
side that uses the dynamic addressing must be the IKE responder; the IKE initiator must use static
addressing.

www.juniper.net IPsec Implementations • Chapter 6-5

Advanced Junos Security

IKE Phases
• IKE tunnel establishment:
• Phase 1:
• Two peers establish a secure. authenticated channel with which to
communicate
• Diffie-Hellman key exchange algorithm is used to generate a
symmetric key common to the communicating gateways
• Main mode: Used when botl1 tunnel peers have static IP addresses
• Aggressive mode: Used when one tunnel peer has a
dynamically assigned IP address
• Phase 2:
• IPsec SAs are negotiated using a Pl1ase 1 secure cl1annel
• Proxy ID is used to identify which SA is referenced for a VPN
• Diffie-Hellman key exchange algorithm can be used (again) to
create PFS
• Phase 2 mode is called quick mode

IKE Phases
IKE tunnel establishment happens in two phases:
Phase 1 establishes a secured channel between gateways for Phase 2 negotiations to
occur. The Diffie-Hellman key exchange algorithm establishes a shared key for
encryption.
Phase 2 establishes the specific VPN connections. Security associations (SAs) are
negotiated on behalf of IPsec to determine the encryption and authentication
algorithms to use when sending user data. The SA is identified by a unique security
parameter index (SPI) that is also negotiated during Phase 2.

A single Phase 1 channel can establish multiple Phase 2 SAs or VPNs. If wanted, a second
Diffie-Hellman exchange can be performed during Phase 2 to negotiate a new tunnel key. Because of
the encryption on this exchange, it is named Perfect Forward Secrecy (PFS).

Chapter 6-6 • IPsec Implementations www.juniper.net

Advanced Junos Security

Step 2: IPsec Traffic Processing

• IPsec data protection

• I Psec modes:
• Transport: End systems are IPsec aware
• Tunnel: Gateway devices are IPsec aware
• I Psec protocols:
• AH: Provides integrity and authentication
• ESP: Provides integrity. authentication. and confidentiality

IPsec: A Two-Step Process-Step 2

Now that we have covered the tunnel establishment step of the IPsec process, we cover the next
step-lPsec traffic processing. Once the IPsec tunnel establishes, the devices are ready to send the
payload using the JPsec attributes and protocols, which ensure payload protection.

www.juniper.net IPsec Implementations • Chapter 6-7

Advanced Junos Security

Traffic Processing (1 of 2)

-li�IiJ
Remote Corporate

fj·:--liil-
Host A , - HostB

ge-0/0/1 I ge-0/0/0 ge-0/0/0 ge-0/0/1

10.1.10.5 10.1.10.1 I 1.1.8.1 2.2.8.1 10.1.210.1
10.1.210.5

0 10.110_5 110.1.210.5 I
0 Prefix
10 1.2105
Interface
ge-0,0,,0
Gateway
11.0.254

0 From zone Private to zone Publ:ic ifSA=10.1.10.5 & DA= 10.1.210.5& Application =any, then use tunnel

0
© XO MO.!X �1.1:)fil()(, HASH

0 1.1.8.1 228.1 ! 50 I SPI l�o :Mo� I �1.'-<l.ol(J HASH

��l��I!��ril?·J}:!D�'
� ,
Worldwide Education Services
,-
'"'"''"'""P""'' 1 s

Traffic Processing: Part 1

The following list describes the order of traffic processing:
1. The packet arrives at the remote Junos security platform.
2. The Junos operating system looks up the destination route and determines the Egress
Zone.
3. The Junos OS looks up the security policy. The traffic matches a tunnel policy.
4. The original packet receives encryption.
5. The Junos OS hashes the packet with an authentication key.
6. The Junos OS builds the tunnel packet with a new IP header, IPsec header, and hash
value. The new packet travels to the tunnel peer.

Chapter 6-8 • IPsec Implementations www.juniper.net

Advanced Junos Security

raffic Processing (2 of 2) ....

Remote
����--������
i+-����-o-r_po_ra�te�1-�H��
o

"ffi-• A--·liil---
ge-0/0/1: j ge-0/0/0: ge-0/0/0: I ge-0/0/1:
10.1.10.5 10.1.10.1 1.1.8.1 2.2.8.1 I 10.1.210.1
10_1.210.5
I

01 11.8.1 2.2.8.1 ! 50 I SPI I >.(O XI.OX I Xi1XO)( I HASH

Enca p Encryp Auth
ESP AES SHA

01 HASH I = HASH

€) )(0 1)(0$( �1�_0)5( 10.1.10.5 10.1.210.5

'10
'(:.}
Prefix
10.1.210 .5
Interface
ge -0,.0/1
Gateway
0 .0.0.0
'--������������-'

@ From zone Public to zone Private if SA =10.1.10.5& DA =10.1210.5&Application = a ll then use tunnel

<!)2013 Juniper Netl'10rl(S, lne.AII 1......,,.4 -�.ruur;i[pff{Worfdwide Educa1ionServlces WWW j,n,pe, net I 9
�:,,_,.;.��"''"'""-

Traffic Processing: Part 2

This list is a continuation of the list from the previous page, describing the order of traffic processing:
7. The corporate Junos security platform receives the encrypted packet.
8. The Junos OS looks up the incoming SPI in the local SA database. The matching record
contains encryption and authentication algorithms, and keys.
9. The Junos OS compares the locally calculated hash with the received hash.
10. The Junos OS decrypts the packet.
11. The Junos OS performs the routing lookup for the decrypted packet and determines the
egress zone.
12. The Junos OS checks the associated security policy. It forwards the packet if the tunnel
policy exists for the packet.

www.juniper.net IPsec Implementations • Chapter 6-9

Advanced Junos Security

IPsec Processing

�---11:.:·��t�j...----'ll;�i----D
Remote Corporate

ge-0/0/1: ge-0/0/0: ge-0/0/0: ge-0/0/1:

10.1.10.5 10.1.10.1 1.1.8.1 2.2.8.1 10.1.210.1 10 .1.210.5

Phase 1
Header, SA, DH
...................................� Header, SA, DH
Phase 2
SA, Proxy ID SA, Proxy ID

IPsec Tunnel

Data �•..,_______........., •�------......._ Data

ii).l!>l1Slu•lpetN.w,ooo,l••:A11�r•,.,..•. )!I fJ!Jn

,,-;,;,1p,�;.,.r,,o,•,•<',�-<�r , G s
,ff:��deEducationServices ,.w,,1unipernel 1 10

IPsec Processing Summary

The slide provides a summary of all the steps of IPsec traffic processing.

Chapter 6-10 • IPsec Implementations www.juniper.net

Advanced Junos Security

Global SPI Checking

• SPI overview and monitoring
• The SPI is an arbitrary (hexadecimal) value used to identify
the encryption algorithm and key used to decrypt packets at
the receiving host
• At the sending host the SPI is used to identify and select
which SA is to be used to secure every packet
usec@scx> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131074 192.168.1.1 500 ESP:3des/shal 49852da0 2345/ unlim root
>131074 192.168.1.1 500 ESP:3des/shal bd82135 2345/ unlim root

• A threshold can be configured with a value for the number of

times the device will respond to an incorrect SPI value
[edit]
user@srx# set security ike respond-bad-spi�

....,...,.,.f,WorldwideEducationServices
-IPf
--��-=>< " www)uoope,net J 11

SPI Overview and Monitoring

An SPI is an arbitrary value that uniquely identifies which SA to use at the receiving host. The
receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt
packets. The sending host uses the SPI to identify and select which SA to use to secure every packet.
Peers in an SA can become unsynchronized when one of the peers fails. For example, if one of the
peers reboots, it might send an incorrect SPI. You can enable a device to detect such an event and
resynchronize the peers by configuring the bad SPI response feature.
In this example, you configure the device to detect and respond five times to a bad IPsec SPI before
deleting the SA and initiating a new one.

www.juniper.net IPsec Implementations • Chapter 6-11

Advanced Junos Security

VPN Monitoring Options

• DPD
• IKE method used to verify the current existence and
availability of IPsec peer devices
• Based on RFC 3706
• Operates over Phase 1 SA
• vpn-moni tor (Juniper proprietary)
• Sends ICMP request through IPsec tunnel to remote
gateway address
• Specify optimized option to consider traffic traversing the
tunnel as a verification that the tunnel is operational
• Operates over Phase 2 SA

DPD
Junos security devices utilize dead-peer-detection (DPD) to verify the current existence and
availability of IPsec peer devices. A device performs this verification by sending encrypted IKE Phase
1 notification payloads (R-U-THERE) to peers and waiting for DPD acknowledgments
(R-U-THERE-ACK). DPD operates on top of the Phase 1 SA and is a standard defined under
RFC 3706. DPD should inter-operate with other vendors. The dead-peer-detection option is
configured under the [edit security ike gateway qa teway-name] hierarchy. There are a
few parameters that can be configured for this command:
always-send: This option tells the device to always send liveliness requests to the
peer, regardless of traffic patterns. The command is disabled by default. If always-send
is absent, then DPD will operate in optimized mode. DPD will be initiated only if there is
an actual attempt to pass traffic through the tunnel and the device has not seen traffic
from the peer for the configured interval.
in terval: The interval at which the liveliness of the peer is questionable. At this point,
the device will start sending DPD requests. The range is 10-60 seconds, and the
default is 10 seconds.
threshold: The maximum number of unsuccessful DPD requests before declaring
the peer dead. The range is 1-5, and the default is 5.
Continued on the next page.

Chapter 6-12 • IPsec Implementations www.juniper.net

Advanced Junos Security
Using vpn-moni tor
You can also use the global VPN monitoring feature to periodically send Internet Control Message
Protocol (ICMP) requests to the peer to determine if the peer is reachable. VPN monitoring operates
on top of the Phase 2 SA and is a better solution, because it guarantees the data path. The problem
is that it's a proprietary solution and will work only on Junos security devices and ScreenOS devices.
Thevpn-monitoroption is configured under the [edit security ipsec vpn vpn-name]
hierarchy. There are a few options that can be used with VPN monitoring to customize the behavior
based on the network needs. The following parameters are configurable under the vpn-monitor
option.
optimized: Specifies the system should use traffic patterns as evidence of peer
liveliness. In such cases, the software suppresses the ICMP requests. This behavior is
disabled by default.
source-interface: Specifies the source interface for the ICMP requests (the VPN
monitoring "hellos"). If unspecified, the system automatically uses the local tunnel
endpoint interface as the source-interface.
destination: Specifies the destination of the ICMP pings. If this parameter is
unspecified, the system uses the peer's gateway address by default.
There are additional settings that can be changed to alter the default behavior ofvpn-monitor.
The following options can be configured under the [edit security ipsec
vpn-monitor-options] hierarchy.
interval: Interval at which to send ICMP requests to the peer in seconds
(1-3600 seconds). The default interval value is 10 seconds.
threshold: Number of consecutive unsuccessful pings before the peer is declared
unreachable (1-65536 pings). The default threshold value is 10 pings.

www.juniper.net IPsec Implementations • Chapter 6-13

Advanced Junos Security

Agenda: IPsec Implementations

• Standard VPN Implementations Review

7Public Key Infrastructure
• Hub-and-Spoke VPNs

JP- =• •, •Wft&tt·"'"'t?
., tnc.AltriCl>tt ,.,.,..... .1.• �l:Jfi1!!:!�fi;,vvorldwide Education Services """" 1uniper net 1 14
��xt;ad:�

Public Key Infrastructure

This slide highlights the topic we discuss next.

Chapter 6-14 • IPsec Implementations www.juniper.net

Advanced Junos Security

Public Key Infrastructure

• PKI is a set of hardware, software, policies, and
procedures to manage, create, store, distribute, and
revoke public keys:
• Based on the concept of trust
• Primary role of PKI is establishing digital identities that can be
trusted
• Certificate authority is the trusted authority
• PKI uses digital certificates to prove and bind public keys to
an entity

-� WorlclwideEducationServices "''""Jun,pe,net t 15

Public Key Infrastructure

Establishing IPsec VPN tunnels with remote sites requires identification during Phase 1 of IKE
negotiations. Public key infrastructure (PKI) offers a way of verifying the identity of a remote site
without the use of a preshared key but by using a digital certificate, which is very similar to a
passport.
PKI uses a certificate authority (CA) to validate your information and to sign it with a digital signature
such that neither your information nor the signature can be modified. Once signed, the information
becomes a digital certificate.
Devices that receive a digital certificate can verify the information in the certificate by validating the
signature using public key cryptography.
An analogy to the PKI function is the use of a passport. When you go to most foreign countries, you
must have a passport. How does the foreign country know the information in your passport is valid?
It all comes down to trust. The government has a stamp that certifies the information in the
passport. Though they might not have even met you before, each foreign country does not need to
certify all information in your passport because your government has already signed and validated it.
As long as the foreign country trusts your government, this system works.
PKI functions on this same concept of trust.

www.juniper.net IPsec Implementations • Chapter 6-15

Advanced Junos Security

PKI Implementation in the Junos OS

• PKI in the Junes environment

• Defined in RFC3280
• The Junos OS also implements the required security features of
RFC 2459 (the predecessor of RFC 3280).
• X.509 certificate format
• Only utilized for IKE Phase 1 negotiations
• The Junos OS supports the following CA vendors:
• Entrust
• Verisign
• Microsoft

The Junos Implementation of PKI

Currently the Junos OS supports the use of PKI certificates for public key validation during IKE Phase
1 negotiations. The Junos OS's implementation of PKI follows the standards defined in RFC 3280. It
also has all the required security features of RFC 2459, which is the predecessor of RFC 3280. The
Junos OS supports both versions of X.509 certificates. However, you must use V3 if you want to use
the SubjectAlternativeName extension field for a non-distinguished name (DN) IKE ID type (for
example, IP address, e-mail address, or fully qualified domain name (FQDN).
The Junos OS supports the following CA vendors:
Entrust
Verisign
Microsoft
Although other CA software services such as OpenSSL can be used to generate certificates, these
certificates are not verified by the Junos OS. Support for other vendors that conform to X.509
certificate standards might be extended in the future.

Chapter 6-16 • IPsec Implementations www.juniper.net

Advanced Junos Security

PKI Basic Elements

• The Junos OS supports three specific types of PKI

objects:
• Private/public key pair
• Certificates
• Local certificate
• Pendingcertificate
• CA certificate
• Certificate revocation lists

Three PKI Objects

The Ju nos OS supports three specific types of PKI objects:
Private/public key pair
Certificates

Local certificate: The local certificate contains the public key and identity
information for the Juniper Networks device. The device owns the associated
private key. This certificate is generated on the Juniper Networks device.
Pending certificate: A pending certificate contains a key pair and identity
information that is generated into a PKCS10 certificate request and manually
sent to a CA. While the device waits for the certificate from the CA, the existing
object (key pair and the certificate request) is tagged as a certificate request or
pending certificate. This process can be automated using Simple Certificate
Enrollment Protocol (SCEP).
CA certificate: When the certificate is issued by the CA and loaded into the Junos
device, the pending certificate is replaced by the newly generated local
certificate. All other certificates loaded into the device are considered CA
certificates.
Certificate revocation lists (CRLs), which are basically lists of certificates that the CA
has revoked and are no longer valid.
Continued on the next page.

www.juniper.net IPsec Implementations • Chapter 6-17

Advanced Junos Security
Three PKI Objects (contd.)
The following key points apply to certificates:
Local certificates are generally used when a Junos device has VPNs in more than one
administrative domain;
All PKI objects are stored in a separate partition of persistent memory, apart from the
Junos image and the system's general configuration;
Each PKI object has a unique name or certificate-ID given to it when it is created and
maintains that ID until its deletion. You can view the certificate-ID using the
command-line interface (CLI) command show security pki
local-certificate;
A certificate cannot be copied from a device (generally). The private key on a device
must be generated on that device only, and it should never be viewed or saved from that
device; and
CA certificates validate the certificates received by the IKE peer. If the certificate is
valid, then it is verified in the CRL to determine whether the certificate has been
revoked. Each CA certificate includes a CA profile configuration that stores the following
information:
CA identity, which is typically the domain name of the CA.
E-mail address for sending the certificate requests directly to the CA.
Revocation settings for the following: Revocation check enable/disable option,
disabling of revocation check in case of CRL download failure, location of CRL
Distribution Point (CDP) (for manual URL setting), and CRL refresh interval.

Chapter 6-18 • IPsec Implementations www.juniper.net

Advanced Junos Security

Certificate Life cle

• The general life cycle for certificates includes the
following phases:
• Generation of public/private keys, identity information, and
certificate request
• Enrollment (request and retrieval)
• Manual
• Automatic usingSCEP
• Usage within IKE Phase 1
• Certificate validation and revocation checks
• Certificate renewal

'il20'13'JUofpor MOOO,lncd\llrlg!jt. ........tm

,� _uµ1;11ml'll;rldwidel:ducalionServlces
"%W� • �-
""'WJUO,pe,net I 19

Certificate Life Cycle

The general life cycle for certificates include the following phases:
Generation of Public/Private Keys, identity information, and certificate request:
The private key on a device must be generated on that device, and it should never be
viewed or saved from that device. The user identity and private key form the basis of the
certificate request and will continue to be used with the local certificate after
enrollment. Therefore it is important to match the certificate-ID of the keys that are
generated with the proper certificate request and eventually with the local certificate.
The certificate request is available in PKCS10 format; the certificate request must be
sent to the CA either through an e-mail or some sort of web-based front-end site.
Certificate Enrollment:
In Junos OS releases 8.5 and earlier only manual certificate requests are supported.
This process includes generation of a PKCS10 request, submission to the CA, retrieval
of the signed certificate, and manually loading of the certificate into the device as the
local certificate. Automatic sending of certificate requests through SCEP is also
supported in Junos OS releases 9.0 or later.
Continued on the next page.

www.juniper.net IPsec Implementations • Chapter 6-19

Advanced Junos Security

Certificate Life Cycle (contd.)

The general life cycle for certificates include the following phases:
Using the certificate identity during the IKE Phase 1 setup. A certificate can identify the
peer by:

IP address
FQDN
User fully qualified domain name (U-FQDN) (e-mail address)
DN
Most VPN administrators use an IP address or FQDN for a VPN gateway identity type
and use an e-mail address (U-FQDN) for a NetScreen-Remote (NSR) Client VPN laptop/
user's identity type. The IKE IDs are added into the SubjectAlternativeName (a V3
extension) field of the certificate. Note that if the IP address of the VPN peer changes,
then a new certificate must be issued with the new IP address, and the old certificate
should be revoked. If the CA does not support the signing of certificates with a
SubjectAlternativeName field, then you must use the DN as the IKE ID on the Junos
device or NSR configurations. You must specify one of the following as the IKE ID in the
certificate request:
IP address
Domain name
E-mail address
Certificate Validation and Revocation Checking:
The Junos OS supports revocation checking by using the CRL lookup method. The CRL
can either be manually loaded in the Junos device, automatically retrieved online from
the CDP, or it can be loaded on demand through Lightweight Directory Access Protocol
(LDAP) or Hypertext Transfer Protocol (HTTP). The Junos OS supports both Distinguished
Encoding Rules (DER) and Privacy-Enhanced Mail (PEM) formats for the CRL.
Certificate Renewal:
The certificate renewal process is similar to the initial certificate enrollment process.
The renewal process includes replacing an old certificate (about to expire) on the VPN
device with a new certificate. Currently the Junos OS supports the manual renewal
process as well as using SCEP to re-enroll the local certificates automatically before
they expire.

Chapter 6-20 • IPsec Implementations www.juniper.net

Advanced Junos Security

Configuring the CA Profile (1 of 2)

• The CA profile defines the attributes of a certificate

authority.
• Each profile is associated with a CA certificate.cert
• Mandatory fields
• CA profile name
• CA identity (domain name)

user@srx# set security pki ca-profile!my-ca !ca-identity!Labdornain.com!

Configuring the CA Profile

The CA profile defines the attributes of a certificate authority. Each CA profile is associated with a CA
certificate. If a new or renewed CA certificate should be loaded without removing the older CA
certificate, a new profile must be created. This profile can also be used for online retrieval of the
CRL. There can be multiple such profiles present in the system which can be associated with
different users.
A CA profile is created by defining the following mandatory values:
CA profile name -my-ca for this example (any value)
CA identity- labdomain. com for this example (CA domain name)

www.juniper.net IPsec Implementations • Chapter 6-21

Advanced Junos Security

Configuring the CA Profile (2 of 2)

• Configure the properties for checking certificate
revocation (optional)
user@srx# set security pki ca-profile� revocation-check crl

• Specify the frequency, in hours. to update the CRL using the

refresh-interval statement (optional)
user@srx# set security pki ca-profile� revocation-check crl refresh-interval 48

• Specify the location (URL) to retrieve the CRL from the CA

(optional)
• HTTP or LDAP
user@srx# set security pki ca-profile� revocation-check crl url
!http://Labsrvl.Labdomain.com/CertEnroLL/LABDOMAIN.crLI

• Send certificate request directly to CA admin by including

their email address (optional)
I
user@srx# set security pki ca-profile� administ rat or email-address
lcert:admini!Labdomain.com

Configuring the CRL properties

The next step is optional, but recommended to ensure the certificates being used have not been
revoked. Begin by configuring the CA profile to use the CRL method for checking certificate
revocation. There are two options for revocation checking. You can use the disable option to
disable revocation checking or you can specify the crl option. Next, define the refresh interval, in
hours, to specify the frequency to update the CRL. The default values are: next-update time
contained in the CRL, or one week if no next-update time is specified. After specifying the refresh
interval, specify the location (URL) to retrieve CRL (HTTP or LDAP). By default, the URL is empty and
uses CDP information embedded in the CA certificate.
Note that the URL can include the server-name and port information such as, ldap://
<ip-or-fqdn>:<port>. If the port number is missing, HTTP will use port 80, and LDAP will use port
443. Currently you can configure only one URL.
The next step, if desired, is to specify an e-mail address to send the certificate request directly to the
CA administrator. If you specify a CA administrator e-mail address, the system composes an e-mail
from the certificate request file and forwards it to the specified address.
All previous options are optional and can be configured at the user's discretion.

Chapter 6-22 • IPsec Implementations www.juniper.net

Advanced Junos Security

Generation of Public and Private Keys

• Generating the Public and Private Key pair is done

using the Junos OS on the local device
• The certificate-id ID is used to uniquely identify the
key pair
• Saved in the certificate store

user@srx> request security pki generate-key-pair certificate-id my-cert

Generated key pair my-keys, key size 1024 bits

Generating a Private and Public Key

When the CA profile is configured, the next step is to generate a key pair on the Junos device. The
private key for the device must be generated on that device, and it should never be viewed or saved
from that device. The user identity and private key form the basis of the certificate request and wil I
continue to be used with the local certificate after enrollment Therefore, it is important to match the
certificate-ID of the keys that are generated with the proper certificate request and eventually
with the local certificate. The certificate request is available in PKCS10 format and must be sent to
the CA either through an e-mail or some sort of web-based front-end site.

www.juniper.net IPsec Implementations • Chapter 6-23

Advanced Junos Security

Enrollment with CA (1 of 4)

• Enrollment with CA involves requesting and installing

certificates from the CA device.
• The process can be automated using SCEP
• Manually request and install certificates on the Junos
device.
• Generate the PKCS10 certificate request to be sent to the CA
user@srx> request security pki generate-certificate-request certifi cate-id
id-name subject "subject-name options" (domain-name domain-name I ip-address
device-ip I email emaiL-ic{) filename £iLename

• certificate-id: Name of the local digital certificate and the

public/private key pair.
• subject: Distinguished name format that contains the common
name. department. company name. state. and country
• domain-name: The FQDN provides the identity of the certificate
owner for I KE negotiations
• filename: (optional) Location where the certificate request
should be laced. or the lo in terminal.

Enrolling with the CA

Enrolling with the CA begins with generating the PKCS10 certificate request to be sent to the CA. This
process can be done either through the manual process or automatically using SCEP. The key
options for generating the request are:
certificate-id- Name of the local digital certificate and the public/private key
pair. This ID ensures that the proper key pair is used for the certificate request and
ultimately for the local certificate.
subject- Distinguished name format. You are not required to enter all subject name
components. You can also enter multiple values of each type, if desired.
CN- Common name
OU -Department
0-Company name
L- Locality
ST-State
C-Country
CN -Phone
DC-Domain component
Continued on the next page.

Chapter 6-24 • IPsec Implementations www.juniper.net

Advanced Junos Security

Enrolling with the CA (contd.)

The key options for generating the request are:

domain-name - FQDN. The FQDN provides the identity of the certificate owner for IKE
negotiations and provides an alternative to the subject name.
ip-address - (Optional) IP address of the device.
email - (Optional) e-mail address of CA administrator.
filename (path I terminal) - (Optional) Location where the certificate request should
be placed, or the login terminal.

You must use one of these: domain-name, ip-address. or e-mail address. This option
defines the IKE ID type and will need to be configured for the IKE gateway profile
described later in this document.
The generated certificate request is stored in a specified file location. A local copy of the certificate
request is saved in the local certificate storage. If the administrator reissues this command, the
certificate request is generated once again. The PKCS10 certificate request is stored in a specified
file and location, from which you can download it and send it to the CA for enrollment. If you have not
specified the file name or location, you can get PKCS10 certificate request details by using the show
security pki certificate-request certificate-id <id-name>command in the
CLI. You can copy the command output and paste it into a Web front-end for the CA server or into an
e-mail.

www.juniper.net IPsec Implementations • Chapter 6-25

Advanced Junos Security

Enrollment with CA (2 of 4)

• Example PKCS10 certificate request

user@srx> request security pki generate-certificate-request certificate-id my-cert
subject "CN=john doe, CN=l. 1. 1. 2, OU=Educa tion, O=JlJniperNetworks,L=SunnyvaLe,ST=CA, C=US"
email user8juniper.net filename ms-cert-req

Gene rated certificate request

-----BEGIN CERTIFICATE REQUEST----­
MIIB3DCCAUUCAQAwbDERMA8GAlUEAxMiam9obiBkb2UxDjAMBgNVBAsTBXNhbGVz
MRkwFwYDVQQKExBKdW5pcGVyIE5ldHdvcmtzMRiwEAYDVQQHEwlTdW5ueXZhbGUx
CzAJBgNVBAgTAkNBMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA5EG6sgG/CTFzX6KC/hz6Czal0BxakUxfGxF7UWYWHaWFFYLqo6vXN08r
OS5Yak7rWANAsMob3E2X/ladlQIRi4QFTjkBqGI+MTEDGnqFsJBqrB6oyqGtdcSU
u0qUivMvgKQVCx8hpx99J3 EBTurfWLlpCN1BmZggNogb6MbwESOCAwEAAaAwMC4G
CSqGSib3DQEJDjEhMB8wHQYDVRORBBYwFIESinVzZXJAanvuaXBlci5uZXQiMAOG
CSqG Sib3DQEBBQUAA4GBAI6GhBaCsXk6/11E2e5AakFFDhY7oqzHhgdlyMjiSUMV
djmf9JbDz2gM2UKpI+yKgtUjyCK/lV2ui57hpZMvnhAW4AmgwkOJg6mpR5rsxdLr
4/HHSHuEGOF17RH06x0YwJ+KElrYDRWj3Dtz447ynaLxcDF7buwd4IrMcRJJI9ws
-----END CERTIFICATE REOUEST-----
Fingerprint:
47:b0:el:4c:be:52:f7:90:cl:56:13:4e:35:52:d8:8a:50:06:e6:c8 (shall
a9:al:cd:f3:0d:06:21:f5:31:b0:6b:a8:65:lb:a9:87 (md5)

1'11f1':,il, i!"'!Tv;;= •• ·•�, •

©2013 Juniper Networle, inc.All rltlfb ....,,,,, "i·JUf'."llPer
t:ii. • Worldwide Education Services """' Juniper ne1 I 26
,
,.� ==-�
.•
-�

Example Certificate Request

In the example provided on the slide the certificate-id points to the public/private key pair
that was generated earlier in the chapter. As displayed in the command the subject options have
· been defined. The e-mail option is also being used to define the IKE ID. The certificate is being
written to a file named ms-cert-reg.
The request starts with and includes the "BEGIN CERTIFICATE REQUEST" line and ends with and
includes the "END CERTIFICATE REQUEST" line. This portion can be copied and pasted to your CA for
enrollment. Optionally, you can also download the "ms-cer t -req" file and send that to your CA.

Chapter 6-26 • IPsec Implementations www.juniper.net

Advanced Junos Security

Enrollment with CA (3 of 4)

• Submit and retrieve certificate from the CA device

• The CA admin submits the certificate request to the CA
• The CA admin verifies the certificate request and generates
a new certificate for the Junos device
• The Junos device administrator retrieves it, along with the
CA certificate and CRL
• The retrieved certificates (local certificate. CA certificate. and CRL)
should be loaded into the Junos device through FTP using the CU.

Submitting and Retrieving Certificates

The next step is to submit the certificate request to the CA and retrieve the certificate.The
administrator submits the certificate request to the CA. The CA administrator will verify the certificate
request and generates a new certificate for the Junes device. The Junes device administrator will
then retrieve it, along with the CA certificate and CRL. The process of retrieving the CA certificate, the
device's new local certificate, and CRL from the CA depends on the CA configuration and software
vendor in use. For more information on how to retrieve the certificates, review the particular
documentation for the CA device being used.
The retrieved certificates (local certificate, CA certificate and CRL) should be loaded into the Junos
device through FTP using the CLI. Assume the following names for certificates:
local certificate - certnew.cer
CA certificate - CA- certnew. cer
CRL - certcrl. crl
user@srx> file copy ftp://10.10.10.10/certnew.cer certnew.cer
/var/tmp//...transferring.file.........crYdEC/100% of 1459 B 5864 kBps
user@srx> file copy ftp:// 10.10.10.10/CA-certnew.cer CA-certnew.cer
/var/tmp//...transferring.file.........UKXUWu/100% of 1049 B 3607 kBps
user@srx> file copy ftp:// 10.10.10.10/certcrl.crl certcrl.crl
/var/tmp//...transferring.file.........wpqnpA/100% of 401 B 1611 kBps
All files can be verified by using the command file list.

www.juniper.net IPsec Implementations • Chapter 6-27

Advanced Junos Security

Enrollment with CA (4 of 4)
• Load the new local certificate, CA certificate, and CRL
• Load the certificate into local storage
user@srx> request security pki local-certificate load certificate-id my-cert
filename certnew.cer
Local certificate loaded successfully

• Load the CA certificate into local storage

user@srx> request security pki ca-certificate load ca-profile my-ca filename
CA-certnew.cer
Fingerprint:
lb:02:cc:cb:Of:d3:14:39:51:aa:Of:ff:52:d3:38:94:b7:ll:86:30 (shall
90:60:53:c0:74:99:f5:da:53:d0:aO:f3:b0:23:ca:a3 (md5)
Do y ou want to load this CA certificate ? [yes,no] (no) �
CA certificate for profile my-ca loaded successfu lly
• Load the CRL into local storage
user@srx> request security pki crl load ca-profile my-ca filename certcrL.crL
CRL for CA profile my-ca loade d successfully

Loading the Certificates

Load the new certificate into local storage from the specified external file and specify the
certificate-ID in order to keep the proper linkage with the private/public key pair. This step
loads the certificate into the RAM cache storage of the PKI module, checks the associated private
key, and verifies the signing operation.
Next, load the CA certificate from the specified external file. The correct CA profile must be specified
to associate the CA certificate to the configured profile. When prompted you must authorize the
device to load the CA certificate.
Finally, load the CRL into the local storage. The allowed maximum size of the CRL is 5 MB. The
correct CA profile must be specified in the command.
Verify that the certificates have been installed correctly using the following commands:
user@srx> show security pki local-certificate certificate-id my-cert detail

user@srx> show security pki ca-certificate ca-profile my-ca detail

user@srx> show security pki crl ca-profile my-ca [brief I detail]

Chapter 6-28 • IPsec Implementations www.juniper.net

Advanced Junos Security

Simple Ceriificate Enrollment Protocol

• SCEP automates the certificate enrollment process:

• Forwards request to CA
• Installs returned certificate
• Uses PKCS10 requests and PKCS7 formatted responses
• Uses HTTP as transport protocol

SCEP
SCEP is the protocol used to allow a device to generate a certificate request and automatically
submit the request to a CA. You can use this protocol only if both the device and the CA support it.
This protocol makes certificate enrollment and re-enrollment easier than manually collecting a
PKCS10 from the device and then submitting it to a CA, which is a painful process when managing a
large number of devices. By using SCEP, an administrator can also manage the expiration of local
certificates by automatically re-enrolling and retrieving new certificates. Currently only the Microsoft
implementation of SCEP is supported with the Junos OS.

www.juniper.net IPsec Implementations • Chapter 6-29

Advanced Junes Security

Certificate Signatures and Verification

© Certificate

l;1 l
Dige1�----l

® (MD5 orSHA-1) -
�
a
I

£ig;,;:tA + - oige£B'

CA's private key

®
© Certificate
DigestA - -1
uncz.J·
nm,;;;;Jll
J (MD5 orSHA-1)
= compare ! ===
SRX t
bigestA - + bigestB

CA's public key®

1. The CA creates digest A by running the certificate through a MD5 or SHA-1 hashing algorithm.
2. The CA encrypts digest A using its private key, which results in digest B (the digital signature).
3. The CA sends the digitally signed certificate to the SRX device that requested it
4. The SRX device creates its own copy of digest A, by applying a MD5 or SHA-1 hashing algorithm to the certificate.
5. The SRX then, decrypts digest Busing the CA'.s public key, which recreates the CA'.s copy of digest A
6. The SRX will then compare the two copies of digest A to verify they are the same. If they match, the SRX knows that the
certificate has not been tampered with.

Certificate Signing and Verification

The slide provides a summary of the steps involved with certificate signing and verification.
The CA that issues a certificate uses a Message Digest 5 (MD5) or Secure Hash Algorithm 1 (SHA-1)
to generate a digest, and then "signs" the certificate by encrypting the digest with its private key. The
result is a digital signature. The CA then makes the digitally signed certificate available for download
to the person who requested it. The recipient of the certificate generates another digest by applying
the same MD5 or SHA-1 hash algorithm to the certificate file, then uses the CA's public key to
decrypt the digital signature. By comparing the decrypted digest with the digest just generated, the
recipient can confirm the integrity of the CA's signature and, by extension, the integrity of the
accompanying certificate.

Chapter 6-30 • IPsec Implementations www.juniper.net

Advanced Junos Security

Using a Certificate for IKE Phase 1

• IKE configuration
• Similar to using preshared key
• Different authentication method
• No changes to IKE Phase 2
• Defining authentication method
• Configure the IKE (Phase 1) proposals to use RSA encryption
• Configure an IKE policy specifying the RSA proposal, local
certificate, CA certificate, and x.509 type peer certificate
• Configure the IKE gateway settings specifying the IKE policy
and a dynamic peer identified by the IKE ID type
• IP address = CU option inet x. x. x. x
• FQDN/U-FQDN = CU option hostname
• ASN1-DN (PKI certificates) = CU option distinguished-name
• Email address = CU option user-at-hostname

Using Certificates with IKE Phase 1

The steps for configuring a VPN using a certificate are similar to the steps for configuring a VPN using
preshared keys. The only difference is the authentication method used for the IKE (Phase 1) policy.
No changes are required for the IPsec (Phase 2) configuration because the use of certificates is part
of Phase 1 negotiations.

Authentication Method
Defining the authentication method consists of the following steps:
Configure the IKE (Phase 1) proposals to use RSA encryption.
Configure an IKE policy specifying the RSA proposal, local certificate, CA certificate, and
x.509 type peer certificate.
Configure the IKE gateway settings specifying the IKE policy, and a dynamic peer which
is identified by the hostname, IP address, distinguished name or e-mail address. The
peer ID configuration depends on how the certificate request was generated earlier. In
this example, assume the remote SRX device used email user@juniper-net
during the certificate request, which means that the IKE ID type for the peer is
user-at-hostname.

www.juniper.net IPsec Implementations • Chapter 6-31

Advanced Junos Security

Sample of IKE Configuration

• IKE configuration
[edit security]
c

::: ::::;;;::;;;���:�;_;e,ao,lr,,-,,,a,r
,res;I
dh-group group2;
authentication-algorith m shal;
}
IKE proposal
encryption-algori thm 3des-cbc;

policy ike-policyl {
mode main;
proposals rsa-propl;
certificate {
!local-certificate my-cert; I I KE po I"ICY
trusted-ca use-all;
peer-certificate-type x509-signature;

gateway ike-gate {
1.ke-policy ike-policyl;
!dynamic user-at-hostname "[email protected]";l
external-interface ge-0/0/3.0;
IKE gateway
�

Sample IKE Configuration

The slide demonstrates a sample IKE configuration designed to use certificates as the
authentication method. There are three parts to configuring IKE:
Configure the IKE (Phase 1) proposal to use RSA encryption. This example uses 3DES
encryption, the SHA! authentication algorithm, and Diffie-Hellman Group 2 keys.
Configure an IKE policy. Main mode is typically used for site-to-site VPNs with static IP
peers where aggressive mode is used for dynamic IP and dial-up peers. This example
uses main mode because both sides have static IPs even though the user-at-hostname
is used on the slide for the IKE ID.

Configure an IKE gateway. A remote !KE peer can be identified by IP address, domain
name or e-mail address. In this example, we are identifying the peer by e-mail address.
Therefore the gateway IKE ID should be the remote peer's e-mail address that was used
to request the certificate. You must specify the correct external interface to properly
identify the !KE gateway during Phase 1 setup.

Chapter 6-32 • IPsec Implementations www.juniper.net

Advanced Ju nos Security

Agenda: IPsec Implementations

ii Standard VPN Implementations Review

III
Public Key Infrastructure
� Hub-and-Spoke VPNs

0- "' "*-sru,..s>Wliv�-u"'1@'
�201'$i!unip•(N• !Orl",lll�Alt!'l,lht.11'••ri"1fi ;' gt.Jli'lffl'li!!arldwideEilucationServices -•,jun,pernet I 33
,e �- -· �� �

Hub-and-Spoke VPNs
This slide highlights the topic we discuss next.

www.juniper.net IPsec Implementations • Chapter 6-33

Advanced Junes Security

Hub-and-Spoke VPN Overvlew I

�
.=. a; � )
§

• IPsec VPNs are often used to connect multiple branch

offices to a central site (corporate office)
• Route based IPsec tunnels only
• Two different approaches on the corporate device
• Separate stO logical unit for every spoke site
• Bind multiple IPsec SAs to a single stO interface using NHTB

4 ':jt:Jn'' er WorldwideEducationServices
�����-?'j
�-��-= - h
www1un;pernet 1 34

Hub-and-Spoke VPNs
There are many ways to implement a hub-and-spoke VPN topology using the concepts of route-based
VPNs. One way is to configure a separate secure tunnel (stO) logical unit for every spoke site.
However, if a device has too many peers, the number of required interfaces becomes a concern from
a scaling and management perspective. To allow for easier management and scalability, the Junos
OS supports multipoint secure tunnel interfaces with the next-hop tunnel binding {NHTB) feature.
This ability allows a device to bind multiple IPsec SAs to a single secure tunnel interface.

Chapter 6-34 • IPsec Implementations www.juniper.net

Advanced Junos Security

Individual s to Logical Units

• Using separate stO units for each SA
• Configured as point-to-point connections
• Routes in inet. O point to the stO units as next hops

����li.��:!l!;J';':nufi11Per: 'WorldwideEduca1ionServlces
.... ;£.::;�-
"""Jun,p .. net I 35

Using Logical stO Units

The concept of hub-and-spoke IPsec tunnel infers that at the hub there are many point-to-point
connections coming together. In order to facilitate this, without multipoint, you have to bind each
tunnel to a different stO unit. When making routing decisions for traffic traversing the device, the
device consults the inet. o routing table to determine where the traffic is to be sent. If the traffic is
to be routed through the IPsec tunnel the route will point either to the logical sto unit or to the
remote gateway IP address.
The only limitations of this method of hub-and-spoke are the finite number of logical units that are
allowed within the Junos OS or the maximum number of supported tunnels for a specific Junos
security device.

www.juniper.net IPsec Implementations • Chapter 6-35

Advanced Junos Security

Hub-and ..Spoke VPN Using NH B

• Hub-and-spoke using NHTB

• Multiple IPsec VPN tunnels can be bound to a single stO
interface unit
• Hub device configured with an stO interface as type multipoint
• Spoke devices configured with a standard stO interface
• Multipoint option is only supported on route based VPNs
• Uses the inet. o route table and the NHTB table to resolve traffic
destinations
• Maps the physical next-hop IP address specified in the route table
entry to a particular VPN tunnel specified in the NHTB table

Hub-and-Spoke Using NHTB

By default, the secure tunnel interface operates as a point-to-point type link. When using the NHTB
method, the Junos OS-based hub device is configured with the sto interface as type multipoint,
which is configured under the stO unithierarchy. The multipoint configuration is only required on
the hub site, the spokes continue to use the default point-to-point mode. As already mentioned,
multiple IPsec VPN tunnels can be bound to a single sto interface unit this way. To link a specific
destination to a specific IPsec tunnel bound to the same stO interface, the Junos OS uses two
tables: the inet. o route table and the NHTB table. The Junos OS maps the next-hop IP address
specified in the route table entry to a particular VPN tunnel specified in the NHTB table. With this
technique, a single sto interface can support many VPN tunnels.
Using this method, the maximum number of IPsec tunnels is not limited by the number of stO
interface units that can be created. The limitations now are either route table capacity or the
maximum number of dedicated IPsec tunnels allowed-whichever is lower. To determine the
maximum route and tunnel capacities by platform, refer to the relevant product data sheet.

Chapter 6-36 • IPsec Implementations www.juniper.net

Advanced Junos Security

Route-to-Tunnel Mapping sto.O

10 1 1 ��.t&LliJ [::J} 1020100/24

ci{ �1 .:.;.:.
stO.O I I

<Q}
.El.;;,,,.·.
� sto.o
· 10.11.1 ! Corporate ..f?� 10.1.1.3 I .·
c(j . ..
6 .. .-.;. ···· ·
a VPN-2 . Branch B
:.1�nternev............... 1 -+ 1030100;24
"" 10.10.10.1.0 - � v,o I
ci • �_;> st0.0 10.3'.H0.10 •
.,... 10.1.1.4 " . . .. 11····
Trust l Untrust

-- "-E]··.
- ' - BranchC .. · . L:.:-J
. ·
.
ll!lffl::2EJ <"'
· ...
}10.40.10.0;24
·-·
untrust ' Trust

inet. o Route Table Next-Hop Tunnel Binding Table

• • ;.It .
10.20.10.0/24 10.1.1.2 sto 10.1 1.2 stO VPN-1 static
10.30.10.0/24 10.1.1.3 stO 10.1.1.3 stO VPN-2 static
10.40.10.0/24 10.1.1.4 stO 10.1.1.4 sto VPN-3 static
The route table is populated through The next-hop to VPN mapping can be done
either static routes or by configuring a statically or if both devices are running the
dynamic routing protocol like OSPF Junes OS, this can be done automatically
orlSIS. during IKE Phase 2 negotiation using the
Notify_NS_NHTB_INFORM notify message.

-�- WorldvAdeEducationServices wwwjun•P""'' 1 37

Route-to-Tunnel Mapping
To sort traffic among multiple IPsec VPN tunnels bound to the same sto interface, the Junos OS
maps the next-hop gateway IP address specified in the route to a particular IPsec tunnel name. The
mapping of entries in the route table to entries in the NHTB table is displayed on the slide. On the
slide, the local device routes traffic sent from 10.10.10.10 to 10.30.10.10 through the sto. o
interface and through VPN-2.
In the table entries displayed on the slide, the IP address for the next-hop in the route table (which is
also the same next-hop IP in the NHTB table) is the sto interface IP of the remote peer site. This
next-hop links the route, and consequently the stO interface specified in the route, to a particular
IPsec VPN tunnel.
The hub device uses the IP address of the remote peer's sto interface as the next hop. The route
can be entered manually (static). or a dynamic routing protocol such as OSPF can be allowed to
automatically enter the route, referencing the peer's sto interface IP address as the next hop in the
route table. The same IP address must also be entered as the next hop in the NHTB table, along with
the appropriate IPsec VPN name. By doing this, the route and NHTB tables are linked. Regarding the
NHTB table, there are again two options: the next hop can be entered manually, or if both devices ar e
running the Junos OS the NHTB route can automatically be obtained from the remote peer during
Phase 2 negotiations using the NOTIFY_NS_NHTB_INFORM message.

www.juniper.net IPsec Implementations • Chapter 6-37

Advanced Junes Security

uration Example Topology

, 172.18.10/3) 'II�: ,�: 1,
Hub Site 1.1.10/24

1721830/3)

...--'"'-"::;.,...----, � loO - 192.168.1.1

stO - 101010 1/24
�
N
�

. r ·"
N

loO - 192.168.1.3 -·-•£'2£3

st0-1010.103/24 srx-3

• Configuration Example
• All branch devices peer to the loO interface on the hub device
• All routes are statically configured
• Configurations and verification commands will be from the
perspective of srx-1 (hub) and srx-2 (spoke)
• Security zones and policies are required but not covered

Configuration Example
The diagram on this slide serves as the basis for the various configuration mode and operational
mode examples that follow. There is no dynamic IGP configured and all routing is being handled
statically. As the slide illustrates, the stO interfaces all participate in the same network. This design
is not required, but strongly recommended.
The goal of this network is to provide IPsec VPNs connectivity between all branch sites and the hub
device. These VPNs will encrypt and transport traffic from branch-to-branch, as well as
branch-to-hub.

Chapter 6-38 • IPsec Implementations www.juniper.net

Advanced Junos Security

Spoke Configuration (1 of 3)
[edit interfaces]
user@srx-2# show stO
unit O {
family inet (
address 10.10.10.2/24;

[edit routing-options]
user@srx-2# show
static (
route 0.0.0.0/0 next-hop 172 .18 .1.1;
route 1.1.1. 0/24 next-hop stO. O;
t'OUte 3.3 .3.0/24 next-hop stO.0;
route 4.4 .4. 0/24 next-hop stO.O;

• Interface and routing options

• The stO interface is configured as point-to-point
• Static routes can point to the sto. O interface or to the hub
site's stO interface IP address

Interface Configuration on Spoke Device

When configuring the spoke devices, you are basically configuring a point-to-point IPsec VPN. As the
slide illustrates, the stO interface is configured with the IP address and network desired. The slide
also illustrates the static routes entered for all networks that are connected to the remote devices.
Throughout the next few slides we focus on a single spoke configuration (srx-2). The other spokes will
be configured similarly with minor changes.

www.juniper.net IPsec Implementations • Chapter 6-39

Advanced Junos Security

Spoke Configuration (2 of 3)
[edit s ecui:ity]
user@srx-2# show ike
policy ike-poll {
mode main;
pro posal-set standard;
pre-shared-key ascii-text "$9$EeJSlM7-waZj BXZjHqQzhSr"; ## SECRET-DATA

gateway my-gate {
ike-policy ike-poll;
address 192.168.1.1; Hubloopback
external-interface g e-0/0/1; Interface used to reach Hub

• Configuring IKE
• Define the proposal or use a predefined proposal-set
• Define the policy and authentication method
• Configure the gateway
• lncludethe IKE policy
• Definethe remote gateway address
.s

Configuring IKE on Spoke Device

As mentioned previously we are configuring a standard point-to-point VPN. In the example on the
slide the device is configured to use the standard proposal set, which includes
esp-group2-3des-shal and esp-group2-aes128-shal proposals. However, if required, a
unique proposal can be created and specified in the IPsec policy. The slide also indicates that the
authentication method is preshared keys. The gateway must also be configured and the slide
displays the proper configuration for the example topology.

Chapter 6-40 • IPsec Implementations www.juniper.net

Advanced Junos Security

Spoke Configuration (3 of 3)
[edit security]
user@srx-2# show ipsec
policy ipsec-poll {
perfect-forward-secrecy
keys group2;

proposal-set standard;

vpn srx2-to-srx1
bind-interface stO.O;
ike
gateway my-gate;
ipsec-policy ipsec-poll;

establish-tunnels immediately;

• Configuring IPsec
• Configure the IPsec policy options
• Define the VPN parameters
• Include the IKE gateway
• Specify the IPsec policy to be used
• Bind the tunnel interface

Configuring IPsec on Spoke Device

The next step on the spoke, is to configure the IPsec properties. The configuration on the slide takes
advantage of the pre-defined proposals by using the standard proposal set. The slide also
indicates that for the session, perfect-forward-secrecy is enabled, this is optional. The next step is to
configure the VPN name and properties. You must bind the VPN to the sto interface being used. The
establish-tunnels immediately option is being used to force the tunnels to be established
from the spoke devices without the initialization by interesting traffic. This feature is also optional.

www.juniper.net IPsec Implementations • Chapter 6-41

Advanced Junos Security

Hub Configuration (1 of 4)
[edit interfaces]
user@srx-1# show stO
unit O {
! multipoint;!
family inet {
address 10.10.10.1/24;

• Configure the stO interface

• The stO interface is configured as multipoint
• If remote device is not running the Junos OS the next hop
tunnel bindings need to be manually defined to populate the
NHTB table
[edit interfaces] remote stO interface IP addresses
user@srx-1# show stO
unit O {
corresponding IPsec VPN tunnel name
---- -- multipoint;
..-- ,
Next hop
tunnel bindings next-hop-tunnel 10.10.10.2 ipsec-vpn srxl-to-srx2;
next-hop-tunnel 10.10.10.3 ipsec-vpn srxl-to-srx3;
next-hop-tunnel 10.10.10.4 ipsec-vpn srxl-to-srx4;
address 10.10.10.1 24;

Interface Configuration on the Hub Device

As with the spoke device, you configure the sto interface with a unit and interface IP address. On
the hub, however, you must also indicate that the interface will be acting as a multipoint gateway by
configuring the multipoint option under the interface's logical unit number. The multipoint
option must be used because the default sto interface is a point-to-point interface and there will be
multiple endpoints for the tunnels bound to this interface.
The output at the bottom of the slide demonstrates the static configuration for next-hop-tunnel
binding, which is also configured under the stO interface. This configuration is required if the
remote device is not running the Junos OS.

Chapter 6-42 • IPsec Implementations www.juniper.net

Advanced Junos Security

Hub Configuration (2 of 4)

[edit routing-options]
user@srx-1# show
static {
route 2.2.2.0/24 next-hop 10.10.10.2;
route 3.3.3.0/24 next-hop 10.10.10.3;
route 4.4.4.0/24 next-hop 10.10.10.4;

• Static route configuration

•· On multipoint IPsec tunnels the next-hop needs to be the
remote stO interface IP address

Static Route Configuration on the Hub Device

Because the stO interface is acting as a multipoint interface, the static route next hop must point to
the remote gateway's IP address and not to the sto interface (unlike the static route configuration
on spoke devices). The next-hop IP address allows the routes in the inet. o routing table to map to
the NHTB table's VPN names.

www.juniper.net IPsec Implementations • Chapter 6-43

Advanced Junos Security

Hub Configuration (3 of 4)
[edit security]
user@srx-1# show ike
policy ike-poll {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$ca-rK8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA

gateway gate-srx2 {
ike-policy ike-poll;
address 172.18.1.2;
external-interface lo0.0;

gateway gate-srx3 {
• Configuring IKE
ike-policy ike-poll;
address 172.18. 2.2;
• Define the proposal
external-interface lo0.0;
• Define the policy
gateway gate-srx4 {
ike-policy ike-poll;
• Configure the gateways
address 172.18.3.2; • Include the IKE policy
external-interface loO;
• Define the remote gateway address
• Specify the external interface

Configuring IKE on the Hub Device

As the slide illustrates, there is nothing special about the IKE configuration, except that you need to
configure a separate gateway that specifies each remote peers' properties. As demonstrated, it is
possible to use the same IKE policy for each peer gateway configuration. Also note that all three
gateways share the same external interface.

Chapter 6-44 • IPsec Implementations www.juniper.net

Advanced Junos Security

Hub Configuration (4 of 4)
[edit security]
user@srx-1# show ipsec
policy ipsec-poll (
• Configuring IPsec
perfect-f orward-secrecy • Configure the IPsec policy options
keys groupZ;
• Define the VPN parameters
proposal-set standard;
• Include the IKE gateway
vpn srxl-to-srx2 (
I
bind-interface stD. D; I • Specify the IPsec policy to be used
ike { • Bind the tunnel interface
gateway gate-srx2;
ipsec-policy ipsec-poll; • The same stO interface is bound
to all VPNs
vpn srxl-to-srx3 { ....----,
bind-interface!stO.O;!
ike {
gateway gate-srx3;
ipsec-policy ipsec-poll;

vpn srxl-to-srx4 (
!
......,.....,,.....,
bind-interface!st0.0;
ike {
gateway gate-srx4;
ipsec-policy ipsec-poll;

Configuring IPsec on the Hub Device

The configuration for the IPsec policy is exactly the same as the ones that are created on the spoke
devices. There must be a VPN configuration for each of your remote devices connecting to the hub.
Under each VPN, the appropriate IKE gateway that was created in the previous slide must be applied.
Each VPN binds the same sto interface unit, thus, defining it as a route based VPN.

www.juniper.net IPsec Implementations • Chapter 6-45

Advanced Junos Security

Spoke Verification (1 of 2)

• Verify tunnel establishment

• Verify I KE negotiation
user@srx-2> show security ike security-associations
Index Re mote Address State Initiator cookie Responder cookie Mode
39 192.168.1.1 UP Oa642ldac4f34f88 f5a8842f89bf53lc M ain

• Verify I Psec negotiation

user@srx-2> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131074 192.168.l.l 500 ESP:3des/shal 49852da0 2345/ unlim root
>131074 192.168.1.l 500 ESP:3des/shal bd82135 2345/ unlim root

- . - JUnlPer ---"- -' �;;,; flit.�

WorldwideEducationServices "W�

Verifying Tunnel Establishment on the Spoke Device

The first step to confirm VPN status is to check the status of any IKE Phase 1 SAs. The slid!e
illustrates the command used to verify these SAs are established.
We can verify that the remote peer is the hub and the state shows UP. If the state shows DOWN, or if
there are no IKE SAs present, then there is a problem with Phase 1 establishment. Confirm that the
remote IP address, IKE policy, and external interfaces are all correct. Common errors include
incorrect IKE policy parameters such as wrong mode type (aggressive or main), pre-shared keys, or
Phase 1 proposals (all must match on both peers). Incorrect external interface is another common
configuration error. This interface must be the interface that would receive the IKE packet,. If
configurations have been checked and verified as correct, check the kmd log for any errors or turn on
traceoptions.
Note that the index number for the hub peer is unique for each IKE SA and can be used to receive
more details for that particular SA. Example of these details for the hub IKE SA index 39 are shown
on the following page.
Continued on the next page.

Chapter 6-46 • IPsec Implementations www.juniper.net

Advanced Junos Security
Verifying Tunnel Establishment on the Spoke Device (contd.)
[edit]
user@srx- 2# run show security ike security-associations index 39 detail
IKE peer 192.168.1.1, Index 39,
Role: Initiator, State: UP
Initiator cookie: Oa642ldac4f34f88, Responder cookie: f5a8842f89bf53lc
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 172.18.1.2:500, Remote: 192. 168.1.1:500
Lifetime: Expires in 15402 seconds
Peer ike-id: 192.168.1.1
Xauth assigned IP: 0.0.0.0
Algcrithms:
Authentication shal
Encryption 3des-cbc
Pseudo random function: hmac-shal
Traffic statistics:
Input bytes 3096
Output bytes 2920
Input packets: 18
Output packets: 13
Flags: Caller notification sent
IPSec security associations: 5 created, 10 deleted
Phase 2 negotiations in progress: O
The next step is to verify that the IPsec SA has been established.The display presented on the slide
indicates that there is an IPsec SA pair using port 500, which means NAT traversal is not used
(nat-traversal would show port 4500 or another random high port number). Also for each SA, we can
verify the SPI used for both directions, as well as the lifetime (in seconds) and usage limits or lifesize
(in kilobytes).The Mon column refers to VPN monitoring status. If VPN monitoring has been enabled,
it will show u (up) or D (down).A hyphen (-) means VPN monitoring is not enabled for this SA.
Note that the IPsec SA also has a unique ID number for each SA.This ID number is the index value
used to identify each IPsec SA.View more details for a particular SA by specifying the ID value as the
index value in the show security ike security- associations command.

www.juniper.net IPsec Implementations • Chapter 6-47

Advanced Junos Security

Spoke Verification (2 of 2)

• Verify that the static routes are installed

user@srx-2> show route

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

+=Active Route, - = Last Active, *=Both

0.0.0.0/0 *[Static/SJ 03:34:23

> to 172.18.1.1 via ge-0/0/1.0
1.1.1.0/24 *[Static/ 5 J 02:00:03
>lvia sto.ol
2.2.2.0/24 *[Direct/OJ 02:06:31
> via ge-0/0/2.0
2.2.2.1/32 *[Local/OJ 02:06:31
Local via ge-0/0/2.0
3.3.3.0/24 *[Static/5 02:00:03
> via stO.O
4.4.4.0/24 *[Static/SJ 02:00:03
>lvia stO.O!
10.10.10.0/24 *[Direct/OJ 02:00:03
> via stO.O
10.10.10.2/32 *[Local/OJ 03:43:12
Local via stO.O

Verifying Routes on the Spoke Device

The next step is to verify the static routes that were created point to either the sto interface or to the
correct remote gateway IP address. As demonstrated on the slide, the routes for the networks
attached to the remote devices point to the stO interface, which indicates that this traffic will
traverse the IPsec VPN to get to those destinations (assuming the policy is configured corr,�ctly).

Chapter 6-48 • IPsec Implementations www.juniper.net

Advanced Junos Security

Hub Verification (1 of 3)
• Verify tunnel establishment
•, Verify IKE negotiation
user@srx-1> show security ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
47 172.18.3.2 UP lflef39bbal23e3d 5a7a69b5667da235 Main
45 172.18.1.2 UP lf916bf9e3ef3625 416fbfl7e960e35d Main
46 172.18.2.2 UP 806b292896f5b0d c lef23dacc3bllafe Main

•' Verify I Psec negotiation

user@srx-1> show security ipsec security-associations
Total active tunnels: 3
ID Gateway Por t Algorithm SP! Life:sec/kb Mon vsys
<131076 172 .18 .1.2 500 ESP:3des/shal bd82135 1401/ un lim root
>131076 172.18.1.2 500 ESP:3des/shal 49852da0 1401/ unlim root
<131077 172.18.2. 2 500 ESP :3des/shal e30d2 07b 1429/ unlim root
>131077 172.18 .2. 2 500 ESP:3des/shal 4dbc4b84 1429/ unlim root
<131078 172.18.3.2 500 ESP:3des/shal d974fbdc 1484/ unlim root
>131078 172 .18 .3. 2 500 ESP:3des/sha1 ebblfbfe 1484/ unlim root

Verify Tunnel Establishment on the Hub Device

Again, the place to start on the hub device is to verify that the IKE SAs have been established. You
can determine that there is an IKE SA established for all three spoke devices. Each SA has a unique
Index value and can be added to the displayed command to provide additional details about each
individual IKE SA.
The next step is to verify that there is a SA pair established for each of the three spoke devices. The
same explanation given for the spoke SAs is relevant for the hub SAs also.

www.juniper.net IPsec Implementations • Chapter 6-49

Advanced Junos Security

Hub Verification (2 of 3)

• Verify NHTB table

• The Flag column indicates the method the tunnel binding
was established
• Auto - indicates the entry was learned tl1rougl1 the
Notify_NS_NHTB_INFORM notify message during IKE Phase 1
• Static - indicates the entry was manually entered under the
stO interface

user@srx-1> show security ips_ec next-hop-tunnels

Next-hop gateway interface IPSec VPN name Flag
10.10.10.2 stO.O srxl-to-scxZ Auto
10.10.10.3 stO.O scxl-to-scx3 Auto
10.10.10.4 stO.O scxl-to-scx4 Auto

Verifying the NHTB Table on the Hub Device

Once Phase 2 is complete for all peers, ensure that routing works properly and confirm tha,t the
NHTB table is established correctly. To show the NHTB table, issue the show security ipsec
next-hop-tunnels operational command. As illustrated on the slide the next-hop gateways are
the IP addresses for the sto interfaces of all remote spoke peers. The next hop should be
associated with the correct IPsec VPN name. If no NHTB entry exists, there will be no way for the hub
device to differentiate which IPsec VPN is associated with which next hop. The flag can have one of
two options: Static or Auto. Static means that the NHTB has been manually configured in the
stO. o interface configurations, which is required if the peer is not a device running the Ju nos OS.
Auto means that the NHTB has not been configured, but the entry has been automatically
populated into the table during Phase 2 negotiations between two Junos OS-based devices.
Note, there will not be an NHTB table on any of the spoke sites, because from a spoke's perspective,
the sto interface is still a point-to-point link with only one IPsec VPN binding.

Chapter 6-50 • IPsec Implementations www.juniper.net

Advanced Junos Security

H111b Verification (3 of 3)
• Verify that the static routes are installed
user@srx-1> show route

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

+ = Active Route, - = Last Active, * = Both

1.1.1.0/24 *[Direct/OJ 02:17:16

> via ge-0/0/2.0
1.1.1.1/32 *[Local/OJ 02:17:16
Local via ge-0/0/2.0
2.2.2.0/24 *[Static/SJ 02:10:25
!> to 10.10.10.2 via stO.O
3.3.3.0/24 *[Static/SJ 02:10:25
!> to 10.10.10.3 via stO.O
4.4.4.0/24 *[Static/SJ 02:10:25
!> to 10.10.10.4 via stO.O
10.10.10.0/24 *[Direct/OJ 03:36:46
> via stO.O
10.10.10.1/32 *[Local/OJ 03:36:46
Local via stO.0

���1t;i[�'l:, I'.:,,-; "

rNet"1ort", 1nc.At1tigjtt, ...,..,,.d :·:::·: :, •
, ,z.iL"2�=·=�"--�-"'
JUrl!�
« -

h��
Worldwide Education Services ,,,..,,, 1un,p" net J s1

Verifying that the Static Routes on the Hub Device

In order for the NHTB to be used, the static routes need to also reference the spoke peer sto IP
address. Note that the next hop is the remote peer stO IP address and all three remote routes point
to sto. o as the outgoing interface.

www.juniper.net IPsec Implementations • Chapter 6-51

Advanced Junos Security

Auto VPN

• Auto VPN Overview

• Reduced administrative overhead when creating Hub-and­
Spoke VPNs
• Single hub configuration
• Supports OSPF and BGP

Auto VPN Overview

Auto VPN allows configuration of a hub-and-spoke VPN, with an advantage of adding new spokes
with little administrative overhead. Auto VPN uses a single configuration on the hub which can be
used to connect all current and future spokes. As well as easily adding new spokes, auto Vl?N
reduces the chances of system downtime because the configuration does not need to be changed
on the hub.
Authentication is handled by a digital certificate policy. Point-to-Multipoint interfaces are used to
apply all spoke connections to a single, logical interface within a VPN. The spokes are treated as
dynamic, dial-up clients presenting a valid certificate.
Currently both OSPF and BGP are supported when using Auto VPN. Dynamic routing updates are
propagated throughout the network. Static routes may also be used, but this will require routes to be
created for each spoke on the hub, negating the advantages of a single hub configuration.

Chapter 6-52 • IPsec Implementations www.juniper.net

Advanced Junos Security

Au1to VPN Hub Configuration (1 of 2)

• Auto VPN Hub Configuration Elements

·• CA Root Certificate and Local Certificate
·• Multipoint stO Interface
,, Single IKE Proposal and Policy
,, Single IKE Gateway per VPN with Common ID
,, Single IPSec Proposal. Policy and VPN
,, Dynamic Routing Protocol

Auto VPN Hub Configuration Elements

The slide lists the elements configured on the hub.

www.juniper.net IPsec Implementations • Chapter 6-53

Advanced Junes Security

Auto VPN Hub Configuration {2 of 2)

[edit security ike]
user@srx-1# �how
gateway gateway (
ike-policy policy;
dynamic ( � � �
distinguished-name
wildcard O=<company>,OU=<department>;

ike-user-type group-ike-id;

local-identity distinguished-name;
external-interface interface;

[edit security ipsec]

user@srx-1# show
vpn name (
bind-interface interface;
ike
gateway gateway;
ipsec-policy policy;

Auto VPN Hub Configuration

The slide shows an example of the IKE and IPsec configuration on the hub.

Chapter 6-54 • IPsec Implementations www.juniper.net

Advanced Junos Security

Auto VPN Stub Configuration (1 of 2)

• Auto VPN Stub Configuration Elements

�CA Root Certificate and Local Certificate with Common ID
O
Multipoint stO Interface
O Single IKE Proposal and Policy to Match Hub
O Single IKE Gateway per VPN with ID to Match Hub
O Single IPSec Proposal, Policy and VPN to Match Hub
•• Dynamic Routing Protocol

Auto VPN Stub Configuration Elements

The slide lists the elements configured on the stub.

www.juniper.net IPsec Implementations • Chapter 6-55

Advanced Junos Security

Auto VPN Stub Configuration (2 of 2)

[edit security ike]

user@srx-2# show
gateway gateway I
ike-policy policy;
address hub-address;
local-identity distinguished-name;
remote-identity distinguished-name O=<compan y>,OU=<department>;
external-interface interface;

[edit secu rity ipsec]

user@srx-2# show
vpn name {
bind-interface interface;
ike I
gateway gateway;
ipsec-policy policy;

Auto VPN Stub Configuration

The slide shows an example of the IKE and IPsec configuration on the stub.

Chapter 6-56 • IPsec Implementations www.juniper.net

Advanced Ju nos Security

Summary
• In this content, we:
41 Differentiated and configured standard point-to-point VPN
tunnels and hub-and-spoke VPNs
41 Monitored the operations of the various IPsec VPN
implementations
•
1
Described public key cryptography for certificates

1'1etwo:i..;11tacAJtr!g1>t,,....., • . ; ,," ff' �TuQs-· 'Worl'ilwideEducalionServices

"'� � -�-
wwwjun,pe,net J 57

We Discussed:
Differentiating and configuring standard point-to-point VPN tunnels and hub-and-spoke
VPNs;
Monitoring the operations of various IPsec VPN implementations; and
Public key cryptography for certificates.

www.juniper.net IPsec Implementations • Chapter 6-57

Advanced Ju nos Security

Review Questions

1. What is the primary role of PKI?

2. In a hub-and-spoke VPN scenario, when is it
required that you manually configure static entries
in the NHTB table?

Review Questions
1.

2.

Chapter 6-58 • IPsec Implementations www.juniper.net

Advanced Ju nos Security

Hub-and-Spoke IPsec VPNs Lab

• Configure and verify a hub-and-spoke VPN.

« �c'"a"�%�"
Net..,orl", 1n .. All riJ!l)ts,.,•rv•d �• �(JQjpef'i1:Worldwide Educatlo n Services '"'" Jun,pe, net I ss
A-�-..-c�lwu-

Hub-and-Spoke IPsec VPNs Lab

The slide provides the objective for this lab.

www.juniper.net IPsec Implementations • Chapter 6-59

Advanced Junos Security

Answers to Review Questions

1.
The primary role of PKI is establishing digital identities that can be trusted.

2.
It is only required for you to manually configure the entries for the NHTB table when the remote device is
not running the Junos OS.

Chapter 6-60 • IPsec Implementations www.juniper.net

Acronym List

3G.................................................................................... third-generation
AGL...........................................................•..................... access control list
ADSL................................................................... asymmetric digital subscriber line
AFTR.................................................................... Address Family Transition Router
AH............................................................................... authentication header
ALG.......................................................................... Application Layer Gateway
ARP......................................................................... Address Resolution Protocol
ASC........................................................................... application system cache
BFD............................................................ Bidirectional Forwarding Detection protocol
BGP ........................................................................... Border Gateway Protocol
CA................................................................................. certificate authority
CCC............................................................................... circuit cross-connect
CDMA..................................................................... Code Division Multiple Access
CE..................................................................................... customer edge
CFM ........................................................................common form-factor module
CGN ................................................................................. carrier-grade NAT
CHAP ........................................................ Challenge Handshake Authentication Protocol
CLI .............................................................................command-line interface
CMTS .................•................................................ cable modem termination system
Cos.................................................................................... class of service
CP....................................................................................... Central Point
CPE....................................................................... customer premises equipment
CPP............................................................................ Control Plane Processor
cps ............................................................................ connections per second
CRL............................................................................ certificate revocation list
dcd.............................................................................. device control process
DCE........•••.••..................................................... data circuit-terminating equipment
DDoS ....................................................................... distributed denial of service
DER ....•••.••.•.•.........................................................Distinguished Encoding Rules
DFA...................................................................... :deterministic finite automation
DHCP .......•••..•................................................... Dynamic Host Configuration Protocol
DLCI ...................................................................... data-link connection identifier
ON ................................................................................ distinguished name
DNS ............................................................................. Domain Name System
DOCSIS..................................................... Data over Cable System Interface Specifications
DoS................................................................................... denial of service
DPD ...............................................................................dead peer detection
DSCP .....•............ ..••..•••.•••...••.•....•..•....••.•.• ...................... DiffServ code point
DSLAM........................................................... digital subscriber line access multiplexer
OS-Lite .................................................................................. dual-stack lite
DTE......................•.•......•.•.......................................... data terminal equipment
DVMRP.......................................................... Distance Vector Multicast Routing Protocol
ESD..........................••....•..•.••.•......•.......•..................... electrostatic discharge
ESP...................................................................... Encapsulating Security Payload
EV-DO......................................................................... Evolution-Data Optimized
FBF..............................................................................filter-based forwarding
FQDN ....................................................................... fully qualified domain name
GB.......................................•.••••....••••..................................... gigabyte
GDOI..................................................................... Group Domain of Interpretation
GPIM.......................................................... Gigabit-Backplane Physical Interface Module
GRE .................................•....•.•••••..•••••..•................generic routing encapsulation
GSM............................................................ Global System for Mobile Communications
GUI..........................................••.•..•..••........................graphical user interface
HA.....................................................................................high availability
HSPA ...................................................................••... High-Speed Packet Access

www.juniper.net Acronym List • ACR-1

HTTP ...................••.•......•.......................................... Hypertext Transfer Protocol
HTTPS .....................••••....................... Hypertext Transfer Protocol over Secure Sockets Layer
ICMP .................................................................. Internet Control Message Protocol
IDP ....................................................................Intrusion Detection and Prevention
IEEE .........................................................Institute of Electrical and Electronics Engineers
IETF ...................••...••.•••••..................................... Internet Engineering Task Force
IGMP ................................................................Internet Group Management Protocol
IKE .....................•...•...••.•............................................. Internet Key Exchange
IOC .................................................................................. inpuVoutput card
IPS ......................................................................... Intrusion Prevention System
IPsec ........•...••........................................................................ IP Security
1Pv4 ..............•....................................................................... IP version 4
1Pv6 ........•••••••....................................................................... IP version 6
ISO ...........................................................International Organization for Standardization
ISP .........•.•••••.............................................................Internet service provider
JNCP .............................................................. Juniper Networks Certification Program
KB .........•••••••..........................................................................kilobytes
Kbps ............................................................................... kilobits per second
KEK .......••..•.•.................................................•••.•••.••........key encryption key
LAG ............................................................................. link aggregation group
LBT ..............................................................................load-balancing thread
LDAP ................................................................Lightweight Directory Access Protocol
LSA ............................................................................link-state advertisement
LSYS ....•••.•••..•.............................................•..•.•..••.............. logical system
MAC .............................................................................. media access control
MB ......•.•.••••.•.............................................•.•........................m,�gabytes
MD5 ........•.......................................................................Message Digest 5
MGCP .............•.••.................................................. Media Gateway Control Protocol
Mini-PIM ....................................................••.•.....Mini-Physical Interface Module (PLM)
MSDP ......•..•......................................................Multicast Source Discovery Protocol
MSS ........•••••••............................................................. maximum segrnent size
MTU .........................................................................maximum transmission unit
NAT ........•.•••••......................................................... Network Address Translation
NAT-T ...............................................................Network Address Translation-Traversal
N HTB .......•.•.••••............................................................ next-hop tunne·I binding
NP ................................................................................. Network Processor
NPC ........•••.•••............................................................ Network Processing Card
NPU ............................................................................Network Processing Unit
NSPC ......••.•...•.................................................Network and Services Processing Card
OSI.........••.••...•..................................................... Open Systems Interconnection
OSPF ........•.••.•.............................................................Open Shortest Path First
PAT ..........•.................................................................Port Address Translation
PCM ............•................................................................pulse code modulation
PE ..........•.••.•.......................................................•..............provider edge
PEM .............................................................................Privacy-Enha ced Mail
PFE .......................................................................... Packet Forwarding Engine
PFS .........•......•.•.........................................................Perfect Forwarcl Secrecy
PIM .......................................................................... Physical Interface Module
PIM ......................................................................Protocol Independent IVlulticast
PKI....................••.......••.•............................................public key infrastructure
PoE ...............................................................................Power over Ethernet
POT ...................•..••••.•••••.............................................packet-ordering thread
POTS .........................................................................plain old telephone service
PPP ...................••.••••.•••.•............................................. Point-to-Point Protocol
PPPoA ...............•••................................................. Point-to-Point Protocol over ATM
pps ................•.•••••••..•••••................................................packets per second
PPTP ......................•.••..........................................Point-to-Point Tunneling Protocol
QoS ......................••.••••••................................................... quality of service
RDP ......................•.•...................................................•.....Remote Desktop
RE ...................•..••.•..•••••................................................... Routing Engine

ACR-2 • Acronym List www.juniper.net

regex................................................................................ regular expression
reth................................................................................ redundant Ethernet
RIB........................................................................... Routing Information Base
RP................................................................................... rendezvous point
RPF............................................................................ reverse path forwarding
rsh ...................................................................................... remote shell
RTSP....................................................................... Real-Time Streaming Protocol
SA................................................................................. security association
SAP..................................................................... Session Announcement Protocol
SCB............................................................................... Switch Control Board
SCEP................................................................Simple Certificate Enrollment Protocol
SCM ............................................................................ SRX Clustering Module
SDP........................................................................ Session Description Protocol
SHA1 - ..........................................................................Secure Hash Algorithm 1
SHDSL ....................................................................... symmetric high-speed DSL
SI ................................................................................... system integrator
SIP ........................................................................... Session Initiation Protocol
SNMP.............................................................. Simple Network Management Protocol
SoHo........................................................................... small office/home office
SPC............................................................................ services processing card
SPI ............................................................................ security parameter index
SPU............................................................................ Services Processing Unit
SQL......................................................................... Structured Query Language
SRE........................................................................ Services and Routing Engine
SSL.............................................................................. Secure Sockets Layer
STRM ................................................................. Security Threat Response Manager
STUN ................................................................... Session Traversal Utilities for NAT
SYSIOC....................................................................... System Input/Output Card
TDM .......................................................................... time-division multiplexing
TEK................................................................................. traffic integrity key
TFTP........................................................................ Trivial File Transfer Protocol
UAC.............................................................................. Unified Access Control
UDP ...............•..•........................................................ User Datagram Protocol
UMTS .........................................................universal mobile telecommunications system
UTM ........................................................................ Unified Threat Management
UUID.......................................................................... universal unique identifier
VCI ............................................................................ virtual channel identifier
VDSL............................................................... very-high-bit-rate digital subscriber line
VIP ......................................................................................... virtual IP
VLAN...................................................................................... virtual LAN
VoIP ..................................................................................... voice over IP
VPLS.......................................................................... virtual private LAN service
VPN.............................................................................. virtual private network
VR....................................................................................... virtual router
VRRP .................................................................Virtual Router Redundancy Protocol
WINS.....................................................................Windows Internet Name Service
XAUTH.......................................................................... extended authentication

www.juniper.net Acronym List • ACR-3

ACR-4 • Acronym List www.juniper.net
,�dvanced Junos Security
1.2.b

Student Guide-Volume 2

Jun1Pec NETWORKS
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 Student Guide, Revision 12.b
Copyright© 2013 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision 10.a-March 2011
Revision 12.a-June 2012
Revision 12.b-June 2013
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.1.X44-D10.4. Juniper Networks assumEis 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

Chapter 7: Enterprise IPsec Technologies: Group and Dynamic VPNs ......................7-1

Group VPN Overview ........................................................... 7-3
GDOI Protocol .................................................................7-8
Group VPN Configuration and Monitoring .........................................7-16
Dynamic VPN Overview ........................................................7-31
Dynamic VPN Implementation ..................................................7-38
Configuring Group VPNs Lab ....................................................7-64

Chapt1�r 8: IPsec VPN Case Studies and Solutions ......................................8-1

Routing over VPNs .............................................................8-3
IPsec with Overlapping Addresses ...............................................8-14
Dynamic Gateway IP Addresses .................................................8-28
Enterprise VPN Deployment Tips and Tricks .......................................8-40
Implementing Advanced IPsec VPN Solutions Lab ..................................8-4 7

Chapt1!r 9: TroubleshootingJunos Security ............................................9-1

Troubleshooting Methodology ...................................................9-3
Troubleshooting Tools .........................................................9-13
Identifying IPsec Issues ........................................................9-38
Performing Security Troubleshooting Techniques Lab ...............................9-51

Appendix A: SRX Series Hardware and Interfaces ........................................A-1

Branch SRX Platform Overview ...................................................A-3
High-End SRX Platform Overview ................................................A-12
SRX Traffic Flow and Distribution ................................................A-22
SRX Interfaces ...............................................................A-35

Acronym List ..................... . ................ ............................ ACR-1

www.juniper.net Contents • iii

iv • Contents www.juniper.net
Course Overview

This three-day course, which is designed to build off of the currentJunos Security (JSEC) offering,
delves deeper into Junos security. Through demonstrations and hands-on labs, you will gain
experience in configuring and monitoring the advanced Junos OS security features with advanced
coverage of IPsec deployments, virtualization, AppSecure, advanced Network Address Translation
(NAT) deployments, and Layer 2 security. This course uses Juniper Networks SRX Series Services
Gateways for the hands-on component. This course is based on Junos OS Release 12.1X44-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 1Pv6 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

Day1
Chapter 1: Course Introduction
Chapter 2: AppSecure
Implementing AppSecure Lab
Chapter 3: Junos Layer 2 Packet Handling and Security Features
Implementing Layer 2 Security Lab
Chapter 4: Virtualization
Implementing Junos Virtual Routing Lab

Day2
Chapter 5: Advanced NAT Concepts
Advanced NAT Implementations Lab
Chapter 6: IPsec Implementations
Hub-and-Spoke IPsec VPNs Lab

Day3
Chapter 7: Enterprise IPsec Technologies: Group and Dynamic VPNs
Configuring Group VPNs Lab
Chapter 8: IPsec VPN Case Studies and Solutions
Implementing Advanced IPsec VPN Solutions Lab
Chapter 9: Troubleshooting Junos Security
Performing Security Troubleshooting Techniques Lab
Appendix A: SRX Series Hardware and Interfaces

www.juniper.net Course Agenda • vii

Document Conventions

CLI and GUI Text

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

Style Description Usage Example

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

Courier New Console text:

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

Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distingllish text
that is input versus text that is simply displayed.

Style Description Usage Example

Normal CL! No distinguishing variant. Physical interface:fxpO,

Enabled
Normal GUI
View configuration history by clicking
Configuration > History.

CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config _ ini in the Filename field.

Defined and Undefined Syntax Variables

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

Style Description Usage Example

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

assigned.
GUI Variable Click my-peers in the dialog.

CLI Undefined Text where the variable's value is Type set policy policy-name.
the user's discretion or text where
ping 10.0.�
the variable's value as shown in
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.

viii • Document Conventions www.juniper.net

Additional Information

Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net;training/education/.

About This Publication

The Advanced Junos Security Student Guide was developed and tested using software Release
12.1X44-D10.4. Previous and later versions of software might behave differently so you should
always consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to [email protected].

Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to http://www.juniper.net;techpubs/.
Locate the specific software or hardware release and title you need, and choose the
format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.

Juniper Networks Support

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

www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net
Advanced Junos Security

Chapter 7: Enterprise IPsec Technologies: Group

and Dynamic VPNs
Advanced Junos Security

Objectives
• After successfully completing this content, you will be
able to:
• Describe, implement, and monitor group VPNs in an
enterprise environment
• Describe, implement, and monitor dynamic VPNs in an
enterprise environment

We Will Discuss:
The description, implementation, and monitoring of group virtual private networks
(VPNs) in an enterprise environment; and
The description, implementation, and monitoring of dynamic VPNs in an enterprise
environment.

Chapter 7-2 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Agenda: Enterprise IPsec Technologies:

Group and Dynamic VPNs

� Group VPN Overview

• GDOI Protocol
• Group VPN Configuration and Monitoring
• Dynamic VPN Overview
• Dynamic VPN Implementation

Group VPN Overview

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -3

Advanced Junos Security

Group VPN Overview

• Group VPN overview

• New category of VPN which eliminates the need for
point-to-point SAs
• Provides branch-to-branch communication without
branch-to-branch tunnels
• Clientjserver architecture
• Each client maintains a IKE Phase 1 SA to the server
• Entire group shares a single Phase 2 SA
• Hardware and software requirements
• Junos OS Release 10.2R2 or later
• Junos OS devices: SRX100. SRX210, SRX220, SRX240,
SRX650, and J Series Services Routers

Group VPN Overview

A group VPN is a new category of VPN that eliminates the need for point-to-point VPN tunnels in a
mesh architecture. The group VPN is built on standards-based technologies that integrate routing
and encryption together in the network. Secure group members are managed through the Group
Domain Of Interpretation (GDOI) standard.
Traditional IP Security (IPsec) VPN deployments tackle the problem of securing traffic between
gateways in the network by creating an overlay network based on the use of point-to-point tunnels.
Traffic carried over these tunnels is normally encrypted and authenticated in order to provide data
integrity and confidentiality. The group VPN solution takes a different approach by disassociating the
encryption and authentication problem from the transport. By doing this, GDOl-based solutions can
provide a way to encrypt branch-to-branch communications without the need to configure
branch-to-branch tunnels.
A common device distributes keys and policies to all registered and authenticated member devices.
By distributing policies from a centralized point and by sharing the same group security association
(SA) (the entire group has a single Phase 2 IPsec SA) with authenticated group members, key
distribution and management are greatly simplified.
Group VPN is a client server architecture. All members have a unique Phase! Internet Key Exchange
(IKE) SA with the central device. Hence, if there are n members there will be a total of n Phase 1 IKE
SAs. However the entire group shares a single Phase 2 SA.

Chapter 7 -4 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net

Advanced Junos Security

Hardware and Software Requirements

The group VPN feature set is supported on branch SRX Series Services Gateways and J Series Services
Routers working in standalone mode. The following list displays the supported devices and minimum
software versions required:
Branch Juniper Networks SRX Series Services Gateways (SRX100, SRX210, SRX220,
SRX240, and SRX650);
J Series Services Routers; and
Junos OS Release 10.2R2 or later.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -5

Advanced Junes Security

Group VPN Advantages

• Advantages over traditional IPsec VPN technology
• Scalability
• Any-to-any member connectivity on a large scale
• Maintains only one Phase 2 SA
• Duplicates the IP header to preserve the source and
destination addresses
• Allows Cos and traffic-engineering settings to be maintained
• Uses underlying IP routing infrastructure
• Seamlessly integrates with multicast networks
• Multicast replication issues are avoided

�!l:�'!"Jll'IJI\'f?;�· Jl:.J(liw- Worldwide Education Services www ;,n.pe, net I s

�A:;;;;t�- -

Group VPN Advantages

Group VPNs were created to address limitations and issues with traditional IPsec VPNs. A group VPN
offer instantaneous large-scale any-to-any IP connectivity using a group IPsec security
paradigm-which allows the group VPN to provide full mesh connectivity using a single group IPsec SA
for all devices in the group. This enables group members to decrypt traffic that was encrypted by any
other group member without individual point-to-point tunnels connecting them.
One important difference, between group VPNs and traditional VPNs, is that the external IP header in
a group VPN is an exact copy of the IP header of the original packet within the Encapsulating Security
Payload (ESP) header versus the external IP header in a traditional VPN, which contains the IP
addresses of the VPN gateways. This process preserves the IP source and destination addresses
during the IPsec encryption and encapsulation process. Therefore, a group VPN integrates very well
with features such as class of service (CoS) and traffic-engineering.
Because a group VPN copies the IP header, it can take advantage of underlying IP VPN routing
infrastructure and does not require an overlay routing control plane. Group VPNs also seamlessly
integrate with multicast infrastructures without the multicast replication issues typically seen in
traditional tunnel-based IPsec solutions. Traditional point-to-point IPsec tunneling solutions suffer
from multicast replication issues because multicast replication must be performed before tunnel
encapsulation and encryption at the IPsec customer edge (CE) router closest to the multicast source.
Multicast replication cannot be performed in the provider network because encapsulated multicast
packets appear to the core network as unicast data.

Chapter 7-6 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Group VPN Limitations

• Features and functionality that are not currently

supported with group VPNs:
• Non-default routing instances
• Chassis cluster
•Server clusters (co-operative key servers)
• Does not allow for simultaneous group membership with two
identical key servers
• Route-based group VPN
• Public Internet-based deployment
• Will not work in NAT environments(requires publicly mutable
address)
•SNMP
• J-Web interface for configuration and monitoring

Group VPN Limitations

As with any new feature set, there are some limitations and features that are not yet supported as of
the Ju nos OS 12.1R1.9 version. The slide outlines the features and functionality that is not currently
supported when using a group VPN.
A group VPN must be configured in main instance. It is not supported in a non-default
routing instances.
A group VPN is not supported in a chassis cluster environment.
There is no support for co-operative key servers where two key servers maintain a group
membership state between them and members can simultaneously register to both key
servers.
Route-based group VPN is not available.
A group VPN requires globally routable addresses even for hosts behind a VPN Gateway.
Hence, the group VPN solution will not work over the Internet or in NAT environments.
Simple Network Management Protocol (SNMP) in not currently available with group
VPNs.
Group VPN configuration and monitoring is not available through the J-Web interface_

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7- 7

Advanced Junos Security

Agenda: Enterprise IPsec Technologies:

Group and Dynamic VPNs

• Group VPN Overview

7GDOI Protocol
• Group VPN Configuration and Monitoring
• Dynamic VPN Overview
• Dynamic VPN Implementation

GDOI Protocol
This slide highlights the topic we discuss next.

Chapter 7 -8 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net

Advanced Junos Security

New IPsec Concepts

• GDOI standard
• Defined in RFC 354 7
• Introduces two new encryption keys
• KEK - used to secure the control plane
• TEK - used to secure the data plane

GDOI Standard
The GDOI protocol is described in RFC 3547 and is used to distribute a set of cryptographic keys and
policies to a group of devices. The communication in the GDOI protocol is protected by a IKE Phase 1
key between each member and the server. GDOI introduces two different encryption keys:
Key encr yption key (KEK), used to secure the control plane; and
Traffic integrity key (TEK), used to secure the data plane.
As with standard IPsec, all keys have a lifetime and have to be re-keyed. The keys distributed through
GDOI are group keys and are used by the entire group.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-9
Advanced Junos Security

Group VPN Device Roles

• Device roles in a group VPN

• Key server
• A device used to create and maintain the group VPN control plane
• Defines policies. encryption protocols. rekey timers. and other VPN
properties
• Distributes VPN properties to group members
• Group member
• A device responsible for encryption and decryption of data traffic
• Only configured with IKE Phase 1 parameters and key server group
information

Group VPN Device Roles

In a group VPN there a two types of devices, key servers and group members. A key server is a device
used for creating and maintaining the group VPN control plane. All encryption policies, such as
interesting traffic, encryption protocols, security associations, re key timers, and so on, are centrally
defined on the key server and are pushed down to all group members at registration time. Group
members authenticate with the key server using IKE Phase 1 and then download the encryption
policies and keys required for group VPN operation. The key server is also responsible for refreshing
and distributing the keys. Unlike traditional IPsec, interesting traffic is defined on the key server and
is downloaded to every group member, whether or not the group member owns that network.
A group member is a device that is responsible for the actual encryption and decryption of data
traffic. A group member is only configured with IKE Phase 1 parameters and the key server and
group information. As mentioned before, encryption policies are defined centrally on the key server
and downloaded to the group member at the time of registration. Based on these downloaded
policies, the group member decides whether traffic needs to be encrypted or decrypted and what
keys to use.

Chapter 7-10 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

IP Header Preservation

• Duplicates the IP header information

• Encapsulates the encrypted packet with the original
IP header information
• Allows protected packets to be routed though existing routing
infrastructure
• Allows multicast replication to be off loaded to the provider network

--- ------

The IP Header
In traditional IPsec, tunnel endpoint addresses are used as the new packet source and destination
addresses. The packet is then routed over the IP infrastructure, using the encrypting gateway source
IP address and the decrypting gateway destination IP address. In the case of a group VPN, IPsec
protected data packets encapsulate the original source and destination packet addresses of the
host in the outer IP header to preserve the IP address. The biggest advantage of tunnel header
preservation is the ability to route encrypted packets using the underlying network routing
infrastructure. As explained earlier, because tunnel header preservation is combined with group SAs,
multicast replication can be offloaded to the provider network. Because every group member shares
the same SA, the IPsec router closest to the multicast source does not need to replicate packets to
all its peers, and is no longer subject to multicast replication issues seen in traditional IPsec
solutions.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-11
Advanced Junes Security

Group VPN SAs

• Group SAs
• All members communicate using a common encryption
policy and shared SA
• Reduces resource load on IPsec routers
• Server-to-member communication
• Pull (initial registration request)
• Members request policy and SA from key server (UDP port 848)
• Unicast push (rekey method)
• Server generates a rekey message and sends a copy to members
• Member sends a ACK back to server
• Multicast push (rekey method)
• Server generates a rekey message and sends a copy to a
pre-defined multicast address
• Members joined to multicast group receive rekey message

GroupSAs
Unlike traditional IPsec encryption solutions, a group VPN uses the concept of a group SA. All
members in the group VPN group can communicate with each other using a common encryption
policy and a shared SA. With a common encryption policy and a shared SA, there is no need to
negotiate IPsec between group members; this reduces the resource load on the IPsec routers.
Traditional group member scalability (number of tunnels and associated SAs) concerns are limited
and usually do not apply to group VPN group members.

Server-to-Member Communication
The server-to-member communication configuration is not mandatory and if not defined it implies
that for rekey the members will pull the SA information from the key server. This pull message is
protected over the IKE SA. The key server is not only responsible for generating keys, but also for
refreshing and distributing keys to the group members. A group VPN supports two kinds of rekey
messages unicast and multicast. Whenever the server-to-member communication is defined for a
group, a KEK is established for each group. All other (push) rekey messages are protected over KEK
SAs.
Continued on the next page.

Chapter 7-12 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security
Server-to-Member Communication (contd.)
There are three rekey methods associated with group VPNs:
1. Pull Method: In the pull method the group member requests the group SA and policy
from the key server. This request is protected over the IKE SA. For the PULL method no
KEK is required.
2. Unicast Push Method: In the unicast re key process, a key server generates a rekey
message and sends multiple copies of the message, one copy to each group member.
The message that the key server sends is protected over KEK. Upon receiving the re key
message, a group member sends an ACK message to the key server. This ACK
mechanism not only ensures that the list of active group members on the key server is
current, but also ensures that the rekey message is sent only to active group members.
A key server can be configured to retransmit a rekey packet to overcome transient
defects in the network. If a group member does not acknowledge three consecutive
rekeys (retransmissions are considered part of the rekey), the key server removes the
group member from its active group member database and stops sending rekey
messages to that group member.
3. Multicast Push Method: In the multicast rekey process, a key server generates a rekey
message and sends one copy of the message to a multicast group address that is
predefined in the configuration. The message that key server sends is protected over
KEK. Each group member joins the multicast group at registration time, so each group
member receives a copy of the rekey message. Unlike unicast rekey, multicast rekey
does not have an ACK mechanism. The key server does not maintain a list of active
group members. Multicast rekey uses the same low CPU overhead whether there is one
group member in the group or a few thousand. Just like the unicast rekey method, the
key server can be configured to retransmit a multicast rekey packet to overcome
transient network defects.
Note that if the group member does not receive the new key before the one currently in use expires,
it will initiate another pull (for example if the rekey message to the member is lost in transit).

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-13
Advanced Junos Security

Server to Member Sample Configurations

• Unicast
[edit security group-vpn server]
user@srx# show group -l server-member-communication
communica ion- e unicas ;
retransmission-period 30;
number-of-retransmission 3;
encryption-algorithm aes-256-cbc;
sig-hash-algorithm shal;
• Multicast
[edit security group-vpn server]
user@srx# show rou rou -2 server-member-communication
ommunication-t e mu ticast;
multicast-group 226.l.l.l;
multicast-outgoing-interface lo0.0;
encryption-algorithm aes-256-cbc;
sig-hash-algorithm shal;
[edit]
user@srx# show protocols pim
rp {
local {
address 100.0.0.100;
}
interface all {
mode sparse;

Unicast Configuration Sample

In the configuration for server-to-member communication we need to define the communication type
as unicast and define parameters for encryption algorithm, hash algorithm, retransmission period
and number of retransmissions. The key server will re-transmit SA and TEK information if it does not
receive an acknowledgement from the member. The retransmission-period defines the time
between each re-transmission and the number-of-retransmission defines the number of
re-transmissions after which the server marks the member dead, if it did not receive an
acknowledgement.

Multicast Configuration Sample

In a multicast scenarios, you define the communication type asmul ticast and define parameters
for encryption algorithm, hash algorithm, multicast group and multicast outgoing interface. As there
are no acknowledgments for multicast rekey there is no point in configuring retransmission interval
and threshold. It is a good idea to configure the key server as the rendezvous point (RP) for the
multicast group. It is important to note that the VPN configuration covers all the Internet Group
Management Protocol (IGMP) joins and leaves, therefore IGMP does not have to be explicitly
configured.

Chapter 7-14 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Redundancy Options

• Redundancy
•VRRP
• Two key servers with identical group VPN configuration
• Members must peer to the VIP address
• HA (chassis cluster) and co-operative key servers might be
supported in future versions

Redundancy Options
As mentioned earlier, the Junos OS group VPN solution does not support chassis clusters or
co-operative key servers. The current solution to redundancy, both at the key server as well as the
group member is to use Virtual Router Redundancy Protocol (VRRP). For key server redundancy, the
design needs to include two key servers each having the same configuration for the group VPN. For
the server-address definitions under the group VPN server configurations, we must provide the VRRP
virtual IP (VIP) address and not the IP address of the individual interfaces.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-15
Advanced Junos Security

Agenda: Enterprise IPsec Technologies:

Group and Dynamic VPNs

• Group VPN Overview

• GDOI Protocol
�Group VPN Configuration and Monitoring
III
Dynamic VPN Overview
• Dynamic VPN Implementation

Group VPN Configuration and Monitoring

This slide highlights the topic we discuss next.

Chapter 7-16 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Configuration Example Topology

• Branch 1
(2220/24
ember1
�
loO - 192.168.1.2
�2 1
� 1721840/30

• Configuration example
• All VPNs establish using loopback addresses
• All devices are in a single OSPF area
• Configurations and verification commands \Nill be from the
perspective of srx-1 (server) and srx-2 (member)
• Zone configuration is not covered

Configuration Example
The diagram on this slide serves as the basis for the various configuration mode and operational
mode examples that follow. There is a single OSPF area which is handling all routing.
The goal of this network is to provide IPsec group VPN connectivity between all branch sites and the
key server. These VPNs will encrypt and transport traffic between branches.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -17
Advanced Junos Security

v
Key Serer Requirements

• Key server configuration is done under the [edit

security group-vpn server] hierarchy
•IKE SA parameters to each of the members
•IPsec proposal for the group
• Group configuration
• Group ID
• I KE gateways that are part of the group
• Policy for interesting traffic
• Server-member communication (optional. but recommended)

Key Server Configuration Requirements

The slide illustrates the configured elements required on a key server.

Chapter 7-18 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Key Server Configuration (1 of 3)

[edit secucity gcoup-vpn secvec]
usec@scx-1# show ike
pcoposal secv-pcop {
authentication-met hod pce-shaced-keys;
dh-gcoup grnup2;
authentication-algocithm shal;
enccyption-algocithm 3des-cbc;

policy secv-p ol {
mode main;
pcoposals secv-pcop;
pce-shaced-key ascii-text "$9$ 9cYLt0 IylMNdsEcds2 4DjCtu"; ## SECRET-DATA

gateway scxl-to-scx 2 {
ike-policy secv-pol;
addcess 192.168.1.2; • Configuring IKE
gateway scxl-to-scx 3 { • Define the proposal
ike-policy secv-pol;
addcess 192.168.1.3; • Define the policy
• Configure the gateways
• Include the IKE policy
• Define the remote gateway address

Key Server IKE Configuration Example

In this section we define the IKE proposal, IKE policy and gateway definitions for each of the
members. As the slide illustrates, there is nothing special about the IKE configuration, except that it
is configured under the [edit security group-vpn server] hierarchy. When defining the
IKE proposal, it is acceptable to use the pre-defined proposal set. In the example on the slide, the
proposal is manually configured. As demonstrated, it is possible to use the same IKE policy for each
peer gateway configuration.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-19
Advanced Junos Security

Key Server Configuration (2 of 3)

[edit security group-vpn server]

user@srx-1# show ipsec
proposal group-prop (
authentication-algorithm hmac-shal-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 3600;

• Configuring IPsec
• The proposal must be user defined
• Specify authentication
• Define encryption
• lndicateSA lifetime

-�- Jun1Pe(
�"�= ·--
-� m-"
WorldwideEducationServlces wwo•jun,pe,net I 20

Key Server IPsec Configuration Example

On the slide, we define the IPsec proposal that is used by the group. A group may have one or more
IPsec SA's and each of these SAs will have only one IPsec proposal. You must manually define the
IPsec proposal when using group VPNs. The pre-defined proposal sets are not supported.

Chapter 7-20 • Enterprise !Psec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Key Server Configuration (3 of 3)

[edit security group-vpn ser ver]
user@srx-1# show group groupl ipsec-sa group-sa {
gr oup-id 1; orooosal arouo-oroo;
ike-gateway srxl-to-srx2; match-policy dynamicl {
ike-gateway srxl-to-srx3; sour c e 2.2.2.0/24;
anti-replay-time-window 100; destination 3.3.3.0/24;
server-address 192.168.1.1; source-port O;
server-member-commun ication { destination-port 0;
communication-type unicast; protocol O;
retransmission-period 30; }
number-of-retransm ission 3; match-policy dynamic2 {
encryption-algorithm aes-256-cbc; source 3.3.3.0/24;
siq-hash-alqorithm shal; destination 2 .2.2.0/24;
source-port 0;
destination-port 0;
protocol 0;
J

• Group configuration
• Specify group name and assign an ID number
• Assign IKE gateways and server address
• Define policies for interesting traffic
• Add server to member communication properties (optional)

Key Server Group Configuration Example

The next step is to define the group parameters. On the slide, we define the group ID, the members
of the group, the IP address of the key server, and all SA parameters. Each SA contains an IPsec
proposal as well as a policy for encrypting and decrypting interesting traffic. A group needs a
minimum of one SA definition. Utilizing a single SA is the most common deployment.Within each SA
hierarchy, we can define multiple policies for interesting traffic. Each SA corresponds to a single TEK
for the group. If you define n SA's then the group will haven TEK's
In the configuration example on the slide, the group is defined with the group-id 1 whose
members are "srx2" and "srx3". The anti-replay-time-window has been defined for 100
seconds. This value can be between 60 and 360 seconds. The key server IP address is configured as
192.168.1.1,which is the loopback IP address. A single SA is configured for this group. This means a
single key will be used for the encryption and decryption of traffic between all members of this group.
Within the SA definition the IPsec proposal group-prop is specified to be used for the group. Next,
the policies have been configured to govern the selection of interesting traffic for encryption and
decryption.
In the match policy configuration, traffic from 2.2.2.0/24 to 3.3.3.0/24 as well as traffic from
3.3.3.0/24 to 2.2.2.0/24 will be encrypted and decrypted. Of course return traffic that matches a
session will be encrypted and decrypted also. All the traffic in the example will be encrypted and
decrypted by the same TEK.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-21
Advanced Junos Security

Group Member Configuration (1 of 3)

[edit security group-vpn member]
usec@srx-2# show ike
proposal propl {
authentication-method pre-shared- keys;
dh-group group2;
authentication-algorithm shal;
encryptio n-algorithm 3des-cbc;

policy poll {
mode main;
proposals pcopl;
pee-shared-key ascii- text "$9$QQUM3/tlRSM87u087-V4oz36"; ## SECRET-DATA

gateway scx2-to-scxl {
ike-policy poll; • Configuring IKE
address 192.168.l.1;
local-address 192.168.1.2; • Define the proposal
• Define the policy
• Configure the gateway to the server
• Include the IKE policy
• Define the remote gateway address
• Specifythe local address

Group Member IKE Configuration Example

The configuration on each group member is minimal. You add configuration under the [edit
security group-vpn member] hierarchy. Define the IKE parameters for the remote key server.
The proposal and policy parameters need to match in order for the SA to be negotiated. The gateway
also needs to be configured, including the IKE policy, gateway IP address and if needed, a local
address. In this example, because we are using the loopback interface as the local gateway, the local
address configuration is required.

Chapter 7-22 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Group Member Configuration (2 of 3)

[edit security group-vpn member]

user@srx-2# show ipsec
vpn vpnl {
ike-gateway srx2-to-srxl;
group-vpn-external-interface loO.O;
group 1;

• IPsec configuration
• Define IKE gateway
• Specify external interface
• Specify the group number to which this member belongs

Group Member IPsec Configuration Example

Next, you configure the VPN group. First you must give the VPN group a name and specify the
gateway to use. You must also define the external interface to be used. Use the
group-vpn-external-interface option to specify the interface you will use to connect to the
key server. The last required piece of configuration is the group to which this member belongs. In the
example, the group ID is 1.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -23
Advanced Junos Security

Group Member Configuration (3 of 3)

[edit security]
user@srx-2# show policies
from-zone untrust to-zone trust
policy scopel {
match {
source-address any;
destination-address any;
application any;
\
then {
permit {
tunnel
ipsec-group-vpn vpnl;

• Policy configuration
from-zone trust to-zone untrust
• Define match criteria
policy scopel {
match {
(must be super-set of
source-address any;
destination-addres s any; server dynamic policy)
application any;
I
then {
• Specify group VPN
permit {
tunnel
tunnel
ipsec-group-vpn vpnl;
I
l-

Group Member Policy Configuration Example

The scope policies need to be defined manually. A scope policy is a policy that is associated with a
group VPN. It maps to a dynamic policy that is received from the key server. It is important to note
that in a group VPN the policies to identify interesting traffic are defined on the key server. The
dynamic policy is pushed to the group member only once the TEK is established. The scope policy is
always a super-set of the dynamic policy. For example, if we define the source and destinations on
the key server as 2.2.2.0/22 and 3.3.3.0/22 we cannot define 2.2.2.0/24 and 3.3.3.0/24 as
source and destination in the scope policy.

Chapter 7-24 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Key Server Verification

• Server SA verification
• IKE
user@srx-1> show security group-vpn server ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
52 192.168.1.2 UP 68ca616e944920f8 9aad23f7bb080be9 Main
53 192.168.1.3 UP c580d2b738e5a4f6 c8d8e7f52cla8c64 Main

• IPsec
user@srx-1> show security group-vpn server ipsec security-associations
Group: groupl, Group Id: 1
Total IPsec SAs: 1
IPsec SA Jl.lgor ithm SPI Lifetime
group-sa ESP: 3 des/sha1 de9a0f46 3534

• KEK
user@srx-1> show security group-vpn server kek security-associations
Index Remote Address State Initiator cookie Responder cookie Groupid
51 0.0.0.0 UP f8bf0e2e04d345ef e7b9d0a99e4f93c0 1

Key Server SA Verification

The IKE SA's (one for each group member) and group IPsec SA can be viewed on the key server using
the operational mode commands displayed on the slide. The KEK SA can also be viewed using the
third operational mode command displayed on the slide.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-25
Advanced Junes Security

Group Member Verification (1 of 3)

• Member SA verification
• IKE
user@srx-2> show security group-vpn member ike security-associations
Index Re mote Addcess State Initiatoc cookie Respondec cookie Mode
53 192.168.1.1 UP 4f3 4e1 16548791c8 86flf9336a9917e6 Main

• IPsec
usec@scx-2> show security group-vpn member ipsec sec u rity-associations
Total active tunnels: 1
ID secvec Poet Algocith m SPI Life: sec/kb Gid vsys
>133955594 192.168.1.1 848 ESP:3 des/shal 4cf2c37f 3583/ unlim 1 coot
<133955594 192.168.1.1 848 ESP:3 des/shal 4cf2c37f 3583/ unlim 1 coot

• KEK
usec@scx-2> show security group-vpn member kek security-associations
Index Remote Addcess State Initiatoc cookie Respondec cookie Gcoupid
54 192.168.1.1 UP d06917c3e183c755 86337e2549ed47b6 1

--��;�· ,#im Worlc!wideEducationSel\iices w•mjun,pe,net J 26

Group Member SA Verification

The IKE SA (one for the key server) and group IPsec SA can be viewed on group VPN members using
the operational mode commands displayed on the slide. The KEK SA can also be viewed using the
third operational mode command displayed on the slide.

Chapter 7-26 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Group Member Verification (2 of 3)

user@srx-2> show security dynamic-policies
From zone: untrust, To zone: trust
Policy: scopel-0001, State: enabled, Index: 1048581, Scope Policy : 5, Sequence number: 1
Source address es:
N/A: 2.2.2.0/24
Destination addresses:
N/A: 3.3.3.0/24
Applications: Unknown, Unknown([0-0]->[0-0]/0)
Action: permit, tunnel
From zone: trust, To zone: untrust
Policy: scopel-0001, State: enabled, Index: 1048582, scope Policy: 6, sequence number: 1
Source addresses:
N/A: 2.2.2.0/24
Destination addresses:
N/A: 3.3.3.0/24
Applications: Unknown, Unknown([0-0]->[0-0]/0)
Action: permit, tunnel
From zone: untrust, To zone: trust
Policy: scopel-0002, State: enabled, Index: 2097157, Scope Policy: 5, Sequence number: 2
Source address es:
N/A: 3.3.3.0/24
Destination addresses:
N/Jl.: 2.2.2.0/24
Applications: Unknown, Unknown([0-0] ->[0-0]/0)
Action: permit, tunnel
From zone: trust, To zone: untrust
Policy: scopel-0002, State: enabled, Index: 2097158, Scope Policy: 6, Sequence number: 2
Source addresses:
N/A: 3.3.3.0/24
Destination addresses:
N/A: 2.2.2.0/24
Applications: Unknown, Unknown([O-OJ->[0-0]/0)
-
Action: permit, tunnel
• ,t-".,S'-"111¥""1,.;i!S' �=0 ""'

,a. J.mirt&i4'i..;w.,,i,;;Jlr.;:;.rutr�;rf;.IV<!d, Jl\JflB(f;¥iH!i:lwide Education Services

-�-J- ���� ww" 1un ip er not J 27

Group Member Dynamic Policy Verification

The dynamic policies that were received from the key server can be viewed using the command
illustrated on the slide. Remember these policies are never configured on the group member and are
distributed by the key server.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -27
Advanced Junos Security

Group Member Verification (3 of 3)

usec@scx-2> show security flow session
Session ID: 1186, Policy name: N/A, Timeout: N/A, Valid
In: 3.3.3.2/19698 --> 2.2.2.2/50047;esp, If: fe-0/0/2.0, Pkts: 0, Bytes: O
Session ID: 1189, Policy name: N/A, Timeout: N/A, Valid
In: 0.0.0.0/19698 --> 0.0.0.0/50047;esp, If: loO.O, Pkts: 0, Bytes: 0
Session ID: 1197, Policy name: sco pel-0002/2097157, Timeout: 1752, Valid
In: 3.3.3.2/49363 --> 2.2.2.2/23;tcp, If: fe-0/0/2.0, Pkts: 49, Bytes: 2728
Out: 2.2.2.2/23 --> 3.3.3.2/49363;tcp, If: fe-0/0/7.0, Pkts: 37, Bytes: 2280
Session ID: 1199, Policy name: N/A, Timeout: N/A, Valid
In: 3.3.3.2/0 --> 2.2.2.2/0;e sp, If: loO.O, Pkts: O, Bytes: 0
Total sessions: 5

user@srx-3> show security flow session

session ID: 1548, Policy name: N/A, Timeout: N/A, Valid

I Decryption side I
In: 2.2.2.2/0 --> 3.3.3.2/0;esp, If: loO.O, Pkts: 0, Bytes: 0
Session ID: 1565, Policy name: N/A, Timeout: N/A, Valid
In: 0.0.0.0/19698 --> 0.0.0.0/50047;esp, If: loO.O, Pkts: 0, Bytes:
Session ID: 1571, Policy name: sco pel-0002/2097157, Timeout: 1536, Valid
In: 3.3.3.2/49363 --> 2.2.2.2/23;tcp, If: fe-0/0/7.0, Pkts: 49, Bytes: 2728
Out: 2.2.2.2/23 --> 3.3.3.2/49363;tcp, If: loO.O, Pkts: 37, Bytes: 2280
Session ID: 1578, Policy name: N/A, Timeout: N/A, Valid
In: 2.2.2.2/19698 --> 3.3.3.2/50047;esp, If: ge-0/0/1.0, Pkts: 0, Bytes:
Total sessions: 5

Group Member Encryption and Decryption Data Path

The entire group VPN data path is handled by the group members. Once the IPsec SA's and TEK are
up and distributed to all group members, the key server distributes policy to each member to
determine which traffic is interesting traffic. The policies distributed to each member are exactly the
same, however, the from-zone to-zone combination to which this policy applies depends on the
from-zone to-zone pairing in the scope policy defined on the group member. The following section
explains the group VPN data path in two sections-encrypting side data path and decrypting side
data path. The data path for simple unicast traffic such as a Telnet session is walked through. This is
an example of a Telnet session originated on host 3.3.3.2 destined to host 2.2.2.2. It is important to
note that the traffic will never traverse the key server in our example. In some cases it might, but the
path selection is purely based on routing.

Encrypting Side Data Path:

1. A Telnet session is initialized from 3.3.3.2 to 2.2.2.2.
2. The initial SYN packet reaches "srx-2" on the trust zone.
3. The device does a policy lookup from the trust to the untrust zone. The route
points to interface fe-0/0/2.0 (interface in the untrust zone).
4. The packets are examined and match the dynamic policy pushed down from the key
server.
5. Three sessions are created.
Continued on the next page.

Chapter 7-28 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junes Security
Group Member Encryption and Decryption Data Path (contd.)
6. Session ID 1197 is the plain text session created for the Telnet traffic.
7. Session ID 1186 is called the tunnel session. It is used for decrypting any traffic
received from 3.3.3.2 through the tunnel. This session is tied to the IPsec SA and SPI.
8. Session id 1199 is called a shadow tunnel session. It is used to drop any IPsec traffic
which does not belong to the corresponding SPI.
9. The packet is then encrypted and the inner source and destination IP is copied to the
outer header and then sent to the next hop router using the interface fe-0/0/2.
10. The reverse packet is matched using session 1186.
Decrypting Side Data Path:
1. For the Telnet session from 3.3.3.2 to 2.2.2.2, the encrypted packet will arrive on the
untrust interface (ge-0/0/1.0) on "sr x -3".
2. This packet will match the 0.0.0.0/xxxxx -> 0.0.0.0/xxxxx session created for the IPsec
SA and SPI after the key server pushed down the policy (ID 1565).
3. Three new sessions similar to the encrypting side are created.
4. Session 15 71 is for the plain-text traffic. Session 157 8 is the tunnel session and
session 1548 is the shadow tunnel session
5. The traffic will get decrypted and sent to the host 2.2.2.2. The reverse traffic will match
session 1578 and get encrypted.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-29
Advanced Junos Security

Advanced Configuration Options

• Advanced options
• Co-location
• Allows device to act as server and member
• Defined under the [edit security group-vpn
co-location] hierarchy
• Anti-replay options
• Based on pseudo time
• Can be turned off by s pecifying no-anti-replay
• Activation time delay
• Configure a delay timer for activating a group VPN

Advanced Group VPN Options

There may be scenarios where the key server may want to be a member of another group. We can
define both member and server configurations on a single SRX chassis. To enable this cooperation
we need to define the member and server configurations under the security group-vpn
co-location hierarchy. You then configure the member and server properties that are required
for each.
A group VPN provides anti-replay protection like a traditional VPN. However anti-replay protection in a
group VPN is based on time (pseudo-time) and not sequence numbers (like traditional VPNs). The
key server is responsible for establishing and maintaining the pseudo-time for a group. The key
server must also keep pseudo-time synchronized on all group members through rekey updates.
Every group member includes its pseudo-time as a time stamp in the data packets. A receiving VPN
gateway then compares the time stamp of the received packet with the group member reference
pseudo-time clock maintained for the group. If the packet arrives too late, it is dropped. We can
define the time window by changing the anti-replay timer. The anti-replay time window may be
between 60 and 360 seconds. Anti-replay is enabled by default and can be disabled by setting
no-anti-replay under the group configuration.
We can also configure a delay timer for activating a group-vpn by adjusting the
activation-time-delay delay- time option under the group hierarchy.

Chapter 7-30 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Agenda: Enterprise IPsec Technologies:

Group and Dynamic VPNs

• Group VPN Overview

• GDOI Protocol
• Group VPN Configuration and Monitoring
�Dynamic VPN Overview
• Dynamic VPN Implementation

Dynamic VPN Overview

The slide highlights the topic we discuss next.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-31
Advanced Junos Security

Dynamic VPN Overview

• Dynamic VPN overview

• Simplifies IPsec access for remote clients
• Authenticated users can simply download the Junos Pulse
client from the remote access server
• Client connects using HTTP or HTTPS to the remote access
server
• Hardware and software requirements
• Junos OS Release 9.5 or later (depending on platform)
• Junos OS devices: SRX100, SRX210, SRX220, SRX240, and
SRX650
• Client software supported: Windows XP. Vista, or Windows 7

-�,,�< ,-, �,
����;".',i!J!fJ:;;...,�Md. -· - '::,.,-

Dynamic VPN Overview

Juniper Worldwide Education Services """'"'jun,pe,net J 32

Remote access VPNs, sometimes called dialup VPNs, have been supported in ScreenOS and by the
Junos OS for some time. Traditional remote access VPNs require client software to establish a VPN.
Installing and distributing the client software to all remote devices becomes a challenge. End-to-site
VPN tunnels are particularly helpful to remote users such as telecommuters because a single tunnel
enables access to all of the resources on a network-the users do not need to configure individual
access settings to each application and server.
The dynamic VPN feature available on SRX devices allows administrators to provide IPsec access to
an SRX gateway while providing a simple way to distribute the client software through the use of a
web portal. The remote client connects to the SRX device through Hypertext Transfer Protocol (HTIP)
or Hypertext Transfer Protocol over Secure Sockets Layer (HTIPS). This enables the transfer of the
Junos Pulse client software.
Continued on the next page.

Chapter 7 -32 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security
Hardware and Software Requirements
There have been many enhancements and changes in behavior regarding the Junos OS
implementations of dynamic VPNs. The features and requirements outlined during this chapter are
specific to the 12.1R1.9 Junos OS release. You will want to refer to the specific documentation for
other Junos OS versions, regarding feature support and requirements.
Dynamic IPsec VPNs are supported on the following devices, which have the Dynamic VPN Client
License installed:
SRX100 (Junos 10.0 and above)
SRX210 (Junos 9.5 and above)
SRX220 (Junos 10.3 and above)
SRX240 (Junos 9.5 and above)
SRX650 (Junos 10.2 and above)
The remote access client software is supported on the following operating systems:
WindowsXP
Windows Vista
Windows 7

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-33
Advanced Junes Security

Dynamic VPNs in the Junos OS

• Dynamic VPNs in the Junos OS

• The SRX device is the remote access server
• Sends the Junos Pulse software to the remote client
• A license is required for each remote client
• Each SRX services gateway device comes with two licenses
• Support for both standalone and clustered environments
• Remote client authentication can be either local or remote
(using an external RADIUS server)

Dynamic VPNs in the Junos OS

The SRX device is referred to as the remote access server because it is responsible for distributing
the VPN software to remote clients. The SRX device is also the terminating device for the IPsec
tunnel and is responsible for providing the proper configuration settings.
The dynamic VPN is a licensed feature. By default, a two user evaluation license is provided free of
cost on SRX devices, and it does not expire. In cases where there are more than two users that need
to connect concurrently, a license is required. These are available in various groups of user licensing.
For licensing information and options please refer to the specific platforms data sheet.
Branch SRX devices can be deployed in standalone or redundant configurations. Throughout this
chapter the configuration and verification commands listed represent standalone devices. However,
the same concepts apply to clustered devices.
With the Junos OS there a two options to authenticate remote users as well as assign IP address for
the remote tunnel interface. You can configure these options on the SRX device, where it handles the
authentication and IP addresses locally. Alternately, you can configure the SRX device to use a
RADIUS server to handle the authentication and IP assignment.

Chapter 7-34 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Dynamic VPN Caveats

• Requirements and caveats

• Policy based VPNs only
• Must be configured with XAUTH
• Must use preshared keys for IKE Phase 1
• Only aggressive mode can be used
• Shared or group IKE IDs can be used to configure a single
VPN that is shared by all remote clients
• Consecutive connections can not exceed the number of licenses
• Not all encryption algorithms supported
• Supports proposal-sets and custom proposals
• The same access profile should be used for both IKE and
dynamic VPN tunnels

Requirements and Caveats

The following list describes requirements and considerations when configuring dynamic VPN
tunnels:
Only policy-based VPNs are supported. Route-based VPNs are not supported with
dynamic VPN tunnels. Traffic allowed from the VPN can be controlled by pushing routes
to the remote client as part of the client's configuration.
Dynamic VPN tunnels must be configured with extended authentication (XAUTH). This
can be accomplished using local authentication or an external RADIUS server. XAUTH is
required to obtain username and password information during IPsec negotiation and to
push an IP address to the remote client. For local authentication, the IP addresses
assigned to remote clients can be drawn from a local pool. Optionally, Domain Name
System (DNS) and Windows Internet Name Service (WINS) addresses may also be
pushed to the remote client.
Only preshared keys are supported for IKE Phase 1 authentication with dynamic VPN
tunnels. The same preshared key can be used for all remote clients because a different
username and password is assigned to each remote client.
When a dynamic VPN client negotiates an AutoKey IKE tunnel with a preshared key,
aggressive mode must be used. Therefore, you must always configure aggressive mode
with dynamic VPN tunnels.
Continued on the next page.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-35
Advanced Junos Security

Requirements and Caveats (contd.)

Shared or group IKE IDs can be used to configure a single VPN that is shared by all
remote clients. When a single VPN is shared, the total number of simultaneous
connections to the gateway cannot be larger than the number of dynamic VPN licenses
installed. When configuring a shared or group IKE ID gateway, you can configure the
maximum number of connections to be larger than the number of installed dynamic
VPN licenses. However, if a new connection will exceed the number of licensed
connections, the connection will be denied.
The dynamic VPN client supports the following algorithms: MD5, SHA-1, DES, 3DES,
AES (with 96-bit, 128-bit, and 256-bit keys). The dynamic VPN client supports DH
groups 1,2, and 5. Tunnel negotiations will fail if other values are configured on the SRX
device.
Either proposal sets or custom proposals may be configured for IKE and IPsec
negotiations. If there is a list of custom proposals referenced in the IKE or IPsec policy,
only the first proposal is sent to the client and other proposals in the list are ignored.
The same access profile should be used for both IKE and dynamic VPN tunnels. This
practice avoids unpredictable behavior if the tunnel goes down unexpectedly or the
client crashes.

Chapter 7-36 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Remote Client Access

• Dynamic VPN from the remote client's perspective

• Contacts the SRX services gateway device using HTTP or
HTTPS
• Client is redirected for authentication purposes
• The SRX services gateway checks for remote access
software
• Installs the Junos Pulse software if not present
• Client system launches remote access software and a new
authentication takes place
•Anew authentication is performed using XAUTH
• IP address is assigned
• Tunnel is established

•• ¥0:-
, !no All� t•seoved. �l!Jfil!Wi:�}1:[ii�dwide Education Services ww� 1un,per net J 37

The Remote Client's Perspective

From the remote user's perspective, creating a secure VPN tunnel is very simple.The following
describes the process for a remote client to access the VPN:
1. The remote client contacts the Web portal by establishing an HTTP or HTTPS connection
to the interface on the SRX device (https://<serverhost>).
2. The remote client is redirected to the Web portal for authentication, where users are
prompted to enter their credentials.
3. Upon successful authentication, the SRX remote access server determines whether the
Junos Pulse software exists on the remote client machine. In Junos OS Release 11.1
and later, if the Pulse client does not exist on the remote client, the Pulse client is
automatically downloaded and installed when the client authenticates to the SRX
gateway. If the Pulse client exists on the client machine, you must launch the Pulse
client software manually. After the Pulse client software is launched, a new
authentication takes place.
4. Upon success authentication, the remote client downloads the latest configuration
options from the server. This ensures that the remote client always has the most recent
configuration when it attempts to build a tunnel.
5. A new authentication is performed using XAUTH. An IP address is assigned to the
remote client from a local address pool or through an external RADIUS server. Upon
successful authentication and address assignment, a tunnel is established.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -37
Advanced Junos Security

Agenda: Enterprise IPsec Technologies:

Group and Dynamic VPNs

• Group VPN Overview

• GDOI Protocol
• Group VPN Configuration and Monitoring
• Dynamic VPN Overview
7 Dynamic VPN Implementation

Dynamic VPN Implementation

The slide highlights the topic we discuss next.

Chapter 7-38 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Configuration Example Topology

Corporate
Office
-------· --- Remote
Client
1

10 10 10.0/24

''
·, 172.20.20.0/30
Remote
... ....
Client
2
.... .10

• Configuration example
, _______ _
• The Internet is using OSPF for routing
• Remote clients have a statically assigned IP address
• Configurations and verification commands will be from the
perspective of srx-1 (remote access server) and client 2
• Remote access server will be assigning the IP range for the
tunnel connections to the corporate office

Configuration Example
The diagram on the slide serves as the basis for the various configuration mode and operational
mode examples that follow. There is a single OSPF area which is configured through the core to
simulate the Internet.
The goal of this network is to provide IPsec dynamic VPN connectivity to both client 1 and client 2.
The configuration and verification commands and outputs will be from the perspective of the remote
access server and client 2. These VPNs will encrypt and transport traffic between the client devices
and the internal servers and network devices connected to the remote access server (srx-1). The
authentication and IP addressing will be configured locally on the remote access server.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -39
Advanced Junos Security

Remote Access Server Configuration

• The remote access server configuration can be

divided into four sections:
• Enabling HTTPS support
• Configuring the authentication and IP address assignment
parameters
• Configuring the VPN tunnel
• Associating VPNs users with dynamic-vpn configurations

Access Server Configuration Overview

The configuration can be divided into four sections:
1. Enabling HTIPS for Web access;
2. Configuring the authentication and IP address assignment parameters;
3. Configuring the VPN tunnel; and
4. Associating VPNs users with dynamic-vpn configuration.

Chapter 7-40 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

CcH1figuring Remote Access Server (1 of 7)

• Enable HTTPS and specify the certificate method

[edit system services]
user@srx-1# show web-management
https {
system-generate d-certificate;

• Configure the security zones

[edit security zones]
user@srx-1# show
security-zone trust
interfaces {
fe-0/0/2 .0;

security-zone untrust
interfaces {
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
ike;
https;
} ...

HTTPS Configuration
The dynamic VPN portal requires the services of the HTTPS (or HTTP) daemon, which can be enabled
under the [edit system services web-management] hierarchy. This configuration step is
only required if this service is not already enabled. If this service is already enabled for J-Web access,
no further configuration is required. In order to enable this service only for dynamic vpn access,
without allowing for J-web access on any interface, simply configure the service without specifying an
interface for J-web, as illustrated on the slide.

Configuring Security Zones

The security zone hosting the interfaces used to terminate the dynamic VPN need to allow IKE and
HTTPS host-inbound traffic in this example. Recall that adding configuration under a interface will
override whatever is configured under the zone.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-41
Advanced Junos Security

Configuring Remote Access Server (2 of 7')

• Configure the dynamic IP address pool assignments
[edit access]
user@srx-1# show address-assignment
pool dynamic-pool {
family inet {
network 10.10.10.0/24;
range dynamic-range {
low 10.10.10.129;
high 10.10.10.254;
}
xauth-attributes {
p rimary-dns 4 .2.2.2/32;
} ...
• Configure proxy-arp to allow the SRX services
gateway to respond to ARP requests for the remote
clients IP addresses
[edit]
user@srx-1# show security nat
proxy-arp {
interface fe-0/0/2.0 {
address {
10.10.10.128/32 to 10.10.10.254/32;
} ...

Configure IP Address Pool

The configuration example provides an example of configuring the pool of addresses that will be
used for the remote client VPN interfaces. Specify the network that you want to use and what the
range of addresses will be by using the low and high key words. Next, define the DNS server to be
used for resolving hostnames to IP addresses and vice versa.

Enable proxy-arp to Reach Remote Client Devices

Because the pool of addresses is within the 10.10.10.0/24 subnet, the SRX device will have to
respond to Address Resolution Protocol (ARP) requests for the addresses in the pool on bel1alf of
devices in the internal network. This can be achieved by configuringproxy-arp as shown on the
slide. This option is only needed if the configured pool belongs to one of the subnets of the
interfaces directly connected to the SRX device. Of course, if these addresses do not belong to the
networks of directly connected interfaces, other devices in the network will need a route pointing to
this pool, in order to reach the remote clients through the tunnel.

Chapter 7 -42 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Coinfiguring Remote Access Server (3 of 7)

• Configuring authentication
·• Configure user profiles
[edit access]
u ser@srx-1# show
profile dynamic-users
Advanced Junos Security

Configuring Remote Access Server (4 of 7')

[edit security]
user@srx-1# show ike
policy ike-poll {
mo e aggressive;
proposal-set standard;
pre-shared-key ascii-text "$9$a2Gjk5Qnp0I. POIEcvMaZU"; ## SECRET-DATA
I
gateway gate-dynamic {
ike-policy ike-poll;
aynarn1c l
hostnarne srx-1;
connections-limit�;
ike-user-type group-ike-id;
)
external-interface ge-0/0/1;
!xauth access-profile dynamic-users; I

• Configure IKE
• Configure a policy: must use aggressive mode
• Must use pre-shared keys as gateway authentication
• Apply the access-profile that was previously defined
• Configure the properties for dynamic IKE negotiation

Configuring IKE
Next, configure the IPsec VPN settings, which begins with specifying the IKE Phase 1 parameters. In
order to simplify the configuration the example takes advantage of the pre-defined proposals for
Phase 1 negotiations. Also notice that the mode is set to aggressive and the authentication
method is configured to use pre-shared keys. Only pre-shared keys are supported for Phase 1
authentication. However, because these VPNs use XAUTH, in most deployments it is possible to use
the same pre-shared key for all the remote clients. Of course, each client or user will have different
username and passwords assigned to use during the XAUTH phase.
Under the IKE gateway configuration, specify the connection limit and the IKE user type. The
connection limit should not be larger than the total number of licenses installed. In the example
provided the group- ike ID is used. Each client will have its own IKE ID, which is derived from the
username and group ID (srx-1).
Specify the interface to listen for connections. This interface is important both for IKE and also for
the authentication portal. The XAUTH profile determines how to authenticate the user, assign
addresses and access parameters.

Chapter 7-44 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

C<lJnfiguring Remote Access Server (5 of 7)

[edit secui:ity]
usei:@si:x-1# show ipsec
policy ipsec-poll {
pi:oposal-set standai:d;

vpn dynami c-vpn

ike (
gateway gate-dynamic;
ipsec-policy ipsec-poll;

• Configure IPsec
• Define the IPsec policy
• Create a VPN and specify the IKE gateway and IPsec policy

�r.iioe:irJ\v�rtdWideEducationServices WWWJun;pernet I 45
!'%@« -

Configuring IPsec
The IPsec policy and configuration is standard. In the example, the policy takes advantage of the
standard pre-defined proposal- set. Specify the !KE gateway to be used and indicate what
IPsec policy to use.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -45
Advanced Junos Security

Configuring Remote Access Server (6 of i')

[edit security]
user@srx-1# show dynamic-vpn
!access-profile dynamic-users;
clients {
all {
remote-protected-resources {
10.10.10.0/24;
}
remote-exceptions {
0.0.0.0/0;
l
ipsec-vpn dynami c-c,·pn;
user {
user-1;
user-2;
user-3;
} ...

• Configure the dynamic-vpn parameters

• Specify the authentication profile
• Define the list of clients and IPsec VPN to use
• Configure traffic restrictions for tunnel access

Configuring the dynamic -vpn

Now that the standard IPsec VPN configuration requirements have been configured, it is time to
move to the dynamic-vpn tunnels. Every time a user attempts to establish a dynamic-VPN
connection to the SRX gateway, the latest available VPN configuration is pushed to the remote client.
To accomplish this, there must be a way to associate the IPsec VPN configurations with client names.
The slide illustrates the configuration for this association, by declaring the authentication profile to
be used with the dynamic-vpn portal, and the list of clients using a particular IPsec VPN
configuration. This profile should be the same as the one used for XAUTH. Next, define the list of
clients along with the ipsec-vpn that is used.
As part of the dynamic VPN profile, it is necessary to configure two prefix lists, the
remote-protected-resources and the remote-exceptions. These lists allow
administrators to configure which traffic will be sent through the IPsec tunnel and which traffic will
bypass the tunnel. Traffic to a destination matching any of the prefixes under the
remote-protected-resources will be sent through the tunnel, while traffic matching any of
the prefixes in the remote-exceptions will be sent in clear-text.

Chapter 7-46 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.ju1niper.net
Advanced Junos Security

Co,nfiguring Remote Access Server (7 of 7)

• Configure security policies
[edit security]
user�lsrx-1# show policies
from-zone untrust to-zone trust
�olicy�c-vpn-pollcy"T policy everything-else (
match ( match (
source-address any; source-address anv;
destination-address any; destination-address any;
app lication any; application any;
} }
then ( then (
permit { deny;
tunnel
ipsec-vpn dynamic-vpn;
}
from-zone trust to-zone untrust {
policy�w-out (
match (
source-address any;
destination-address any;
application any;
}
then (
p ermit;

Configuring Security Policies

Traffic allowed from the VPN can be controlled by pushing some routes to the client, as part as the
client's configuration. The VPN client only supports proxy IDs which are derived from the security
policies used to map the traffic to one of the tunnels. Due to this, the security policy that is used for
remote access clients must permit all traffic.
Remote access tunnels are supported only using policy-based VPNs. Therefore, we need to configure
a security policy allowing encrypted traffic from the clients which, in the example deployment
scenario, comes from the untrust zone to the trust networks.
It is important to note that placement of this VPN security policy is critical. It needs to be placed
before more specific policies so that traffic that is intended to be sent over the VPN is processed
correctly.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-4 7
Advanced Junos Security

Using RADIUS for User Authentication

• RADIUS authentication
• Used as an alternative to local authentication
• The only XAUTH and IP address assignment method
supported prior to 10.4R1.9
[edit access]
user@srx-1# show
profile radius-dynamic-profile
authentication-order radius;
radius-server {
10 .10 .10 .3 secret "$9$pgpaOicKMXbs4yls4aZkqu01"; ## SECRET-DATA

firewall-authentication
web-authentication {
default-profile radius-dynamic-profile;

Using Radius Authentication

If, instead of using local authentication, an external RADIUS server is used to authenticate users and
perform the address assignment, the access profile must be changed to point to a RADIUS server as
shown on the slide. The rest of the configuration remains unchanged, but now the RADIUS server
must pass the IP address and other parameters assigned to the client during the IPsec negotiation.
The following standard RADIUS attributes are used for address assignment:
Framed-IP-Address
Framed-lP-Netmask
It is also possible to pass DNS and WINS servers to the client.

Chapter 7 -48 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

C<ltnfiguring Remote Client Access (1 of 7)

• Access the dynamic VPN from client

,. Establish an HTTPS session to the access server's external
interface (https://172.20.20.2)
•• Specify login details
---- - � '
�LJnlPEf:;;Worldwide Education Services .,.,., 1un1per net I 49
·�-��..:.i=lhL

Client Access to Dynamic VPNs

The first step for a remote client, when connecting to a dynamic VPN for the first time, is to send an
HTTPS request to the IP address of the external IPsec gateway interface. In the example on the slide
the initial request went to https://172.20.20.2 and the user is then redirected by the server to the
https://172.20.20.2/dynamic-vpn/ URL for authentication. Then, the remote client is prompted for a
username and password. After entering the correct information, the user clicks the Log In button
to proceed.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -49
Advanced Junos Security

Configuring Remote Client Access (2 of 7)

Launching the VPN Client

Dc.y.:uwani: to dcw.nbad.mfal..and/tt �e tofto'#«�liunh

fOUi<!'e�"'f(lf:SL\Jt,-,;ithebu'xhar.:!�e-t�,ei-e,s,9
lobmg;clVCf1
• �,;!!i.oo<.!,!!�!!!_-thetknl:tr'��-

ProrluctM'«oo: Juno:i Pulse

SortW<l,e N'ame: lns1allc:tComponentSRX.exc
SctYCI HM!C: 172.20.20.2:

- - - - - - - - - -'--�������������--'- - - - - - - - - - - -
• Download the Junos Pulse client
• Must install software if this is the first use

Downloading the Junos Pulse Client

For first time users, the next step is to download and install the Junos Pulse software. Junos Pulse
enables secure authenticated network connections to protected resources and services over LANs
and WANs. Junos Pulse is a remote access client developed to replace Access Manager, the earlier
access client called Juniper Networks Access Manager. You must uninstall Access Manage·r before
you install the Junos Pulse client. The Junos Pulse client is supported for all branch SRX devices
running Junos OS Release 10.2 and later, but must be deployed separately.
The slide shows the next step after the remote client has successfully authenticated the HTIPS
connection. A dialog box appears to prompt the client to install the Junos Pulse software. Alternately,
you can download the Ju nos Pulse software from
http://www.juniper.net;su pport/products/pulse/#sw.
After the VPN software has been installed, the user can access the VPN by either logging i11 to the
portal or by launching the VPN software directly.

Chapter 7 -50 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.j,uniper.net
Advanced Junos Security

Co,nfiguring Remote Client Access (3 of 7)

-X
PULSe

Connections � � � Acceleration
1 ]
-> INAN OpUmi2a1iM
ADd connection x

Name:
dynamic-VPN

SemrURL:

171.20.201

t,, Connect J C;;i:neo?I

..._____,.. ,,.____ Ctose
GMOJ.��._

• The Junos Pulse connection parameters

•• Type should be set as firevvall
•• Server URL is set to the IP address of access server external
interface
rNeiwor1<,, In� Alt�res.Md. Jl:dfl� ��!Wtide Education Services "'"'"' 1uniper nei 1 51
.-......,�"' ,,. '--tr"

,.: -

Using Junos Pulse

The process and steps used for Junos Pulse are outlined in the next few slides.
1. Launch Junos Pulse client from Start>All Programs>Juniper
Networks>Junos Pulse, and click on the plus ( +) symbol to add a connection.
2. From the Connection Type drop-down menu choose Firewall, enter the name of
the connection, and the IP address of the external interface of the SRX device.
3. Click Add.
4. Click Connect under the dynamic-VPN connection.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-51
Advanced Junos Security

Configuring Remote Client Access (4 of 7')

Connect to: dynamic-VPN

You are about to authenticate to an untrusted
server. There are problems with the .site's
security certfficate'

This certificate or 0-r.e cf1he certificates in

the certificate chain rs not time valid,

Th7C\:!rtifir;a!§ qr Cl)rtiflq,{e C:hJin !5

oasea:on an untn1sted root

Should Pulse continue to connect?

Save settlngs

• Certificate verification warning

• Self-signed certificate
• Invalid certificate

Certificate Verification Warning

If you are using the self-signed certificate or if the certificate is invalid, an alert message is shown.
5. Click Connect if you want to continue.

Chapter 7 -52 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Co,nfiguring Remote Client Access (5 of 7)

PULSe
Connect to: dynamic-VPN

Provtd� lhe following credentials to c.cmpll?t� the connection.

User Name;
user-1

······�
Password:

[ Connect J( cancel J

• Authentication
11 Initial authentication occurs
• Client downloads latest configuration settings from server

Nolworlc,, lne.Allriahu ,.._,,,.d.

�
JLJri)l�fi
-�-rw Worldwide Education Services
,,,
www '""''" net 1 53

Authentication
The next step is authenticating with the access server:
6. Enter the username and password credentials and click Connect. At this time, the
user configuration is downloaded and the IKE SA will attempt to establish.
The Ju nos Pulse window shows the status as Connecting.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -53
Advanced Junos Security

Configuring Remote Client Access (6 of 7)

PULSe
Connect to: dynamic-VPN

Provide the following credentials to cc,mplete- ihe connedlon.

User Name:
user·I

Password:
•••••••I

cancel

• Tunnel authentication
• Second authentication will occur if connecting for the first
time
Establishes IPsec SA

Tunnel Authentication
After the initial authentication, the system must authenticate the user for IPsec tunnel access:
7. If the dynamic VPN is being accessed for the first time, the user will be prompted for
their credentials again. Enter the XAUTH username and password credentials.
Note that the first user authentication (at Step 8) is used to download the configuration and to
establish an IKE SA. The second user authentication (at this step) is used to establish the IPsec SA
and make the connection. Both user credentials used can be either the same or different based on
the configuration on the SRX device.

Chapter 7-54 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

CCJJnfiguring Remote Client Access (7 of 7)

------ ---
· ---
-X'
PULSe
File Help

J+'/IXI
-.- dynamic-VPN � [ m.conncct J

Sl'.;>1v,n URL 172.20.20.2

St3t1.:s· Connected
Cr,mp!!arF:� Meets security policies

© 2010 J1Jr,iµer Ne!w.eli;&, he.

A! riQ:nts reser.;ed. Close

• Verify connection status

·• Connected
·• Disconnected
.���\iftir.i\'ii:,'r;J�;; ideEducationServices ww�Jun1pernet J ss

Verify Connection Status

If the user credentials are accepted then the connection is established. The status of the connection
shows as Connected.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -55
Advanced Junos Security

Verifying Remote Client Access (1 of 2)

,-:-- C:\WINOOWS\,ystem321cmd.exe 1!151£1

tlwrnet ,nl,,pter ,Jun lJU-r N4·tin11•k A�1ent U 1rtu4l Ad,,�•te1··

l!orirwclHH1 ·.i1t�r tf it OMS: 1;11ff 1x • :
IP Ad<lrt!', '" . . . . . . . . . . . . : HLULHi.129
S11h1wt M,,·,k . . . . . . . . . • . : 255.25').2� r,.l't
JP l'Mdr1"s;. . . . . . • . . . . : fe80:: r,:85ff:ft•7f:eh8'1z8
Def,mlt Gctt.eu.\y . • • . . • . . . ;

• Verify tunnel address

• Use Windows ipconfig utility

Verify Tunnel Address

To verify the connection, go to command prompt and type ipconfig. Look for the Juniper Network
Agent Virtual Adapter. This adapter is required to successfully access protected resources. The IP
address will also be displayed for this adapter.

Chapter 7-56 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

VE�rifying Remote Client Access (2 of 2)

• Verify network reachability from client

• Access a device in the protected network through the
dynamic IPsec VPN tunnel

"' =·�- �=
-=- -- - .
JL}Q� Worldwide Education Services
0 � f

@• er Neiwcrks� lnt:.AJl rlgttf,: reseMd. './ ":.� ;,,;,� WWW Jun IP er not I 57

Verify Access to the Protected Network

Access to the protected network can be verified a number of ways. In the example provided, an FTP
session is established to one of the protected devices behind the SRX gateway.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-57
Advanced Junos Security

Verifying Remote Access Server (1 of 3)

• Verify SAs
• Verify IKE SA establishment
user@srx-1> show security ike security-associations
Index Remot e A ddress State Initiator cookie Responder cookie Mode
2 172.20.20.10 UP 6d83fdedd6f8dl12 c9cd00c371966139 Aggressive

• Verify IPsec SA
user@srx-1> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/k b M on vsys
<133955593 172.20.20.10 500 ESP:aes-128/shal 6a115bf6 3553/ 449993 - root
>133955593 172.20.20.10 500 ESP:aes-128/shal c52ac98 8 3553/ 449993 - ro ot

Verify the SAs

Dynamic VPN clients use IPsec tunnels and, therefore, can be monitored using the same commands
used to monitor site-to-site or dialup JPsec tunnels. In particular, the show security ike
security-associations command lists all SAs in the system and their status. Similarly, the
show security ipsec security-associations command displays the status of the
Phase 2 SAs.

Chapter 7-58 • Enterprise JPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

VE&rifying Remote Access Server (2 of 3)

• Display dynamic VPN user information

• Display user connections and parameters
user@srx-1> show security dynamic-vpn users
User: user-1 , Number of connections: 1
Remote IP: 172.20.20.10
IPSEC VPN: dynamic-vpn
IKE gateway: gate-dynamic
IKE ID : user-lsrx-1
IKE Lifetime: 28800
IPSEC Lifetime: 3600
Status: CONNECTED

• Display additional user information

user@srx-1> show security ike active-peer
Remote Address Port Peer IKE-ID XAUTH username Assigned IP
172.20.20.10 500 user-lsrx-1 user-1 10.10.10.129

Display the User Information

The show security dynamic-vpn users command can be used to display the number of
concurrent connections for each connected user, and the negotiated parameters for that user.
Additionally, the show security ike active-peer command can be used to display in a
tabular form, the list of all connected users, their remote IP addresses and the address assigned to
them using XAUTH.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-59
Advanced Junos Security

Verifying Remote Access Server (3 of 3)

• Display access server information

• View current client version
user@srx-1> show security dynamic-vpn client version
Junos Pulse 2.0.3.11013

• Display license information

user@srx-1> show system license usage
Licenses Licenses Licenses Expiry
Feature name used installed needed
jctynamic-vpn ------------ 1 25 0 permanent!
·ax· ·4�11
� �--w-l�a·n-- -a-p ------------�O�----------�z ----------�O..----p-e-rmanen
- t
logical- system O 1 0 permanent

Display Access Server Information

To view the current version of the Junos Pulse software, use the show security dynam:Lc-vpn
client version command.
All devices ship with a two-user dynamic VPN license. More licenses can be purchased, up to a
certain maximum determined by each platform. The show system license command can be
used to display the number of licenses installed and currently used.
As previously mentioned, client connections will be rejected when the number of licenses used
reaches the maximum allowed. When users disconnect, the licenses are released so only the
maximum number of simultaneous users is enforced (not the total number of configured clients).

Chapter 7-60 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

J.\"'eb and Remote Access Portal Isolation

BothJ-Web and
Dynamic VPN J-Web access dynamic VPN
HTTP(S) Request access only only access enabled
HTTP(S) request to the User is redirected User is redirected User is redirected to
/URL to the dynamic to the J-Web login the dynamic VPN
VPN portal page portal
HTTP(S) request to the Dynamic VPN "Page Not Found" User is redirected to
/URL/dynamic-vpn portal is shown is returned the dynamic VPN
portal
HTTP(S) request to the "Page Not Found" User is redirected User is redirected to
/URL/management-URL is returned to the J-Web login the J-Web login page
page

• Coexistence of J-Web and dynamic VPNs

• Page displayed depends on the URL and access server
settings
• Destination URLs become critical when accessing both
J-Web and dynamic VPNs on the same interface

Coexistence of J-Web and Dynamic VPNs

Both J-Web and the portal used to authenticate dynamic VPN users leverage the same HTIP server
infrastructure, configurable under the [edit system services web-management]
hierarchy. All interfaces listed under the interface section will answer HTIP or HTIPS requests (or
both, based on the configuration). It is possible to disable J-Web access on the interfaces used for
dynamic-vpn access. In releases prior to 10.4, to configure the dynamic VPN feature, it was
mandatory to add the IKE listener interface to the list of management interfaces for HTIPS. In Junos
10.4, every interface used for dynamic-vpn access will automatically accept HTIP and HTIPS
connections to the dynamic VPN portal. If an interface is used for dynamic-vpn access (that is, if
an interface is configured under the IKE listener interfaces in an IPsec VPN profile used for
dynamic-vpn access) and that interface is not configured for web-management access, only
access to the dynamic-vpn portal will be allowed, essentially disabling J-Web access on that
interface.
Because an interface can be configured for dynamic-vpn access by adding it to the IKE listener
interfaces, web-management access or both, access to the dynamic-vpn portal will depend on
which interface a request comes from and how that interface is configured. The table on the slide
summarizes the different combinations.

The management-url configuration option can used to specify the URL used to access the
management interface (J-Web) when a particular interface is used both for dynamic VPNs and Web
management. When the management-url is configured, a request to
http(s)://<interface-address>/<management-url> will, instead, present the management interface.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -61
Advanced Junos Security

Summary
• In this content, we:
• Described, implemented, and monitored group VPNs in an
enterprise environment
• Described, implemented, and monitored dynamic VPNs in
an enterprise environment

We Discussed:
The description, implementation, and monitoring of group VPNs in an enterpri,,e
environment; and
The description, implementation, and monitoring of dynamic VPNs in an enterprise
environment.

Chapter 7-62 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Junos Security

Re,view Questions

1. In a group IPsec VPN network, which device is

responsible for distributing the policies?
2. What are the two options that can be used for
authenticating remote clients in a dynamic VPN
configuration?
3. What are the two methods for the remote client to
download the Junos Pulse software?

oriii oi'Altr�
•
4.

Review Questions
�IJr;)I "'9 "'

··�
��
:WorldwideEducationServices
- -
.,.,.,,unipernet 1 63

1.

2.

3.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7 -63
Advanced Junos Security

Configuring Group VPNs Lab

• Implement a group VPN within your pod.

-41\l '"r"
f1
��rldwid�EducatlonServlces wwwJ

Configuring Group VPNs Lab

The slide provides the objective for this lab.

Chapter 7 -64 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
Advanced Ju nos Security
Answers to Review Questions
1.
The key server is the device responsible for sending the policies out to all group members.
2.
The two options for authentication for remote clients of a dynamic VPN are local and RADIUS.
3.
The remote client ,viii be prompted to download the Junos Pulse software after successfully authenticating an
HTTPS request to the external IPsec interface of the configured SRJC remote access server. Alternately, the
remote client can download the Junos Pulse software from
http://\V\V\v.juniper.net/support/products/pulse/#s,v.

www.juniper.net Enterprise IPsec Technologies: Group and Dynamic VPNs • Chapter 7-65
Advanced Junos Security

Chapter 7 -66 • Enterprise IPsec Technologies: Group and Dynamic VPNs www.juniper.net
JUnlf2;�[
Advanced Junos Security

Chapter 8: IPsec VPN Case Studies and Solutions

Advanced Junos Security

Objectives

• After successfully completing this content, you will be

able to:
• Configure OSPF over GRE over IPsec VPNs
• Configure IPsec between sites with overlapping IP addresses
• Configure an IPsec VPN using the hostname as the IKE ID
• Describe some IPsec VPN tips and tricks for the enterpri�;e
environment

We Will Discuss:
Configuring OSPF over generic routing encapsulation (GRE) over IP Security (IF'sec)
virtual private network (VPN) tunnels;
Configuring IPsec between sites with overlapping addresses;
Configuring an IPsec VPN using the hostname as the Internet Key Exchange (11-<E) ID;
and
Some IPsec VPN tips and tricks for the enterprise environment.

Chapter 8-2 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

A1�enda: IPsec VPN Case Studies and

Sc•lutions

7 IRouting over VPNs

• IPsec with Overlapping Addresses
• Dynamic Gateway IP Addresses
• Enterprise VPN Deployment Tips and Tricks

Routing over VPNs

The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-3

Advanced Junes Security

Case Study (1 of 3)

Case Study
In this case study, Ultimate Music Inc. has purchased Mom-N-Pop Music Shop. Both networks are
currently running OSPF and each network has a single area.
Management in Ultimate Music Inc. wants to establish internal communication with Mom-M-Pop
Music Shop immediately.

Chapter 8-4 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junes Security

Case Study (2 of 3)

• Ultimate Music Inc. has purchased Mom-N-Pop Music

Shop
·• A migration team has been formed
• Botl1 networks are running OSPF area O
• Both networks have a connection to the Internet with a static
publically routable address
• No overlapping addresses exist between these two networks
·• The IT manager at Ultimate Music Inc. does not want to
spend additional money at this time
·• Traffic through the Internet has to be protected because
sensitive corporate proprietary information is being shared

�d '.�)J(il�fW��®tideEducationServices "ww1un,perne1 Is

Case Study: Migration Team

Immediately following the acquisition, a migration team is formed to look at all facets of combining
the two companies, including their OSPF networks.
The team must provide a secure method of sharing sensitive internal information. The initial
discussion was about establishing a direct connection from the corporate office to the office of
Mom-N-Pop Music Shop. This solution is too costly and the migration team has been asked to find a
different solution without spending additional money. Whatever the solution is, it must be quickly
implemented.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-5

Advanced Junos Security

Case Study (3 of 3)
------
.,,..... -UltimateMusiclnc- ....._
/
/ ..........

. ·� "

\\ . .
-J:i-.· ·•-.
"."'"/ ""· . ,....., "'""1
(/��·. .. --"��]
}-L:
'<. __
-·
d)_.-/�/�:
-
,
-
/,

QJ�
osPFNooO

- - - -
·
C a-:.
.1. / Mom-N-Pop bl
.
,!__
A
Mus1cShop
� §I

1\ /j El
-�
', . ,./..J:] OSPFArea�//
' �Q /
"
...... ___ ..,..,
bJ /

Case Study: Migration Topology

The migration team decided to implement an IPsec VPN tunnel between the two sites over the
existing Internet connections. This solution allows all internal communication from site-to-site to be
encrypted and secure.
Because both networks are already running OSPF in area 0, it was decided that to route be,tween
these two sites, each site will need to establish an OSPF peering relationship with the other.
The migration team researched the configuration requirements and found that the Mom-N-Pop
Music Shop gateway device does not support OSPF directly over the VPN tunnel. After furt�1er
investigation the team found that they can use GRE to avoid this problem, by tunneling OSPI= through
the GRE tunnel which is established over the IPsec tunnel. The migration team completed their
research and presented their final proposal. They proposed connecting the sites with IPsec to secure
the traffic and to run GRE over the top of the IPsec tunnel which will allow them to establish an OSPF
peering between the sites. This setup will allow OSPF to view all network routes as part of the same
area 0. Because this solution does not cost any additional money and will ensure that internal traffic
is protected, the proposal was approved.
Note that the use of GRE requires additional packet overhead. Because of this requirement, packet
fragmentation might increase. To combat this problem, be sure your network can handle tt1e extra
overhead by adjusting link maximum transmission unit (MTU) values or by adjusting the TCP
maximum segment size (MSS) values within your network. We discuss TCP MSS later in this chapter.

Chapter 8-6 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

O!;PF over GRE over IPsec

• OSPF over GRE over IPsec requirements
• General requirements
• Only route based VPNs are supported
• No overlapping addresses
• Protocol OSPF has to be enabled on the G RE interface under the
proper zone hierarchy
• Add the G RE interface to OSPF area O
• Case Study requirements
• Both networks need to remain in OSPF area O
• IPsec connection is point-to-point
• G RE is used because other vendor might not support OSPF directly
over IPsec
• All internal traffic must be allowed to pass between sites through
the IPsec tunnel
• lnternet traffic should exit each network through their own Internet
connection
".

Requirements
GRE and OSPF are only supported with route-based IPsec VPNs. When merging two networks, it is
important that there are not any overlapping network addresses. Overlapping network addresses will
cause routing problems between the two networks. We will discuss how to handle overlapping
network addresses later in this chapter. It is also important when using routing protocols that you
enable the protocol on the interfaces within the zone configuration. Because OSPF will be signaled
over the GRE tunnel you must configure the GRE interface under OSPF.
For the purposes of this case study, both OSPF networks need to remain in area 0. The IPsec VPN
must be a point-to-point VPN and allow all internal traffic through. Internet traffic should exit each
site directly to their Internet service provider (ISP).

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-7

Advanced Junos Security

OSPF over GRE over IPsec

Configuration (1 of 4)

• Preliminary configuration steps

• Configure the site-to-site route based VPN parameters
• Add IKE to the gateway interface under the proper zone
configuration
• Create policies
• Allow the internal traffic in and out of the VPN
• Allow internet traffic to exit through the un trust zone
• Block traffic from the un trust zone to your protected zone
(trust)
• Add a static route on the gateway devices with next-hop of
external neighbor
• Export this route into OSPF

Preliminary Configuration
The configuration examples provided in the next few pages demonstrate the unique configuration
steps needed to enable OSPF over GRE over IPsec tunnels. The topics outlined on this slide, are not
going to be explicitly defined with examples in this section. These configuration steps will sHrve as
the foundation for this case study.

Chapter 8-8 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

O!;PF over GRE over IPsec

Cc)nflguratlon (2 of 4)
[edit]
user@Corporate-Gateway# show interfaces stO
unit O {
family inet {
address 10.0.0.1/30;

[edit]
user@Corporate-Gateway# show interfaces gr-0/0/0
unit O {
tunnel {
source 10.0.0.1;
destination 10.0.0.2;

family inet {
address 10.1.0.1/30;

• Interface configuration
• Must configure the stO interface
• IP address should be on the same network for both sto interfaces
• Configure the gr-0/0/0 interface
• Specify the source and destination addresses of the tunnel and
assign an IP address and network to the interface

Interface Configuration
Because this is a route-based IPsec VPN, you must configure the stO interface. If the GRE tunnel will
be using the stO interface as the source and destination, the interface addresses for both sides of
the IPsec tunnel should be in the same network. Being on the same network is not required, but
makes it much simpler when configuring. You must also configure the gr-0/0/0 interface, which is
the interface used to signal the GRE tunnel. When configuring this interface, the source and
destination addresses of the tunnel must be specified. Additionally, you must specify an IP address
to be used as the source of packets entering the GRE tunnel.
In the example displayed on the slide, the source and destination of the GRE tunnel are the IP
address of the stO interfaces. The IP address for the tunnel is also defined.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-9

Advanced Ju nos Security

OSPF over GRE over IPsec

Configuration (3 of 4)
[edit security zones)
user@Corporate-Gateway# show security-zone trust

host-inbound-traffic
protocols {
ospf;

interfaces {
ge-0/0/2. 0;
ge-0/0/3.0;
ge-6/0/0.0;
loO .O;
I gr-01010. o;
• Configure the security zone
• Add the gr-0/0/0 interface to the appropriate zone
• Enable the OSPF protocol for the gr-0/0/0 interface
• OSPF can be added for the entire zone of for the specific interface

Security Zone Configuration

You must add the gr-0/0/0 interface to the appropriate security zone. In the example on the slide,
the interface has been added to the trust security zone. Because this zone is the internal zone,
the OSPF protocol has been allowed for the entire zone, which applies to all interfaces within this
zone.

Chapter 8-10 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

O!;PF over GRE over IPsec

C<>nfiguration (4 of 4)

[edit prntocols]
usec@Cocpocate-Gateway# show ospf
acea 0.0.0.0 {
intecface ge-0/0/3.0;
intecface ge-0/0/2.0;
intecface lo0.0;
intecface ge-6/0/0.0;
!
intecface gc-0/0/0.0;

• Configure OSPF
• Add the gr-0/0/0 interface and proper unit to the
protocols ospf area O hierarchy

•r Network>, Inc.All rlthh ,.,......

..
---�--
JLJ(rl��Worldwide Education Services
..
w•sw 1unlper net 1 11

OSPF Configuration
As mentioned earlier the gr-0/0/0 interface must be added to the OSPF protocol configuration. This
addition allows a neighborship to establish through the tunnel to the remote GRE interface.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-11

Advanced Ju nos Security

OSPF over GRE over IPsec

Verification (1 of 2)

• Verify OSPF
• Review interfaces in OSPF
user@Corporate-Gateway> show ospf interface
Interface State Area DR ID BDR ID Nbrs
ge-0/0/2.0 DR 0. O. O. 0 192.168.1.6 1 92.168 .1.2 1
ge-0/0/3.0 DR 0. 0. 0. 0 192.168.1.6 192.168.1.1 1
ge-6/0/0.0 DR 0.0. o. 0 192.168.1.6 192.168.1.3 1
!gr-0/0/0.0 PtToPt 0. 0. o. 0 0. 0. 0. 0 0. 0. 0. o 1
loO. 0 DR 0. 0. o. 0 192.168.1.6 0. o. 0. o 0

• Verify OSPF neighbors

user@Corporate-Gateway> show ospf neighbor
Address Interface State ID Pri Dead
10.20.20.6 ge-0/0/2.0 Full 192.168.1.2 128 31
10.20.20.2 ge -0/0/3.0 Full 192.168 .1.1 128 39
10.20.20.10 ge-6/0/0.0 Full 192.168.1. 3 128 39
110.1.0.2 gr-0/0/0.0 Full 192.168.2.4 128 38

Verifying OSPF
Once the two ends of the GRE tunnel can communicate, the GRE interface becomes an operational
OSPF interface. You can view it using the show commands displayed on the slide.

Chapter 8-12 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

O!•PF over GRE over IPsec

Veirification (2 of 2)

• Contiguous area O
• Type 1 LSAs are exchanged through the tunnels
OSPF database, Area 0. 0. 0. o
Type ID Adv R tr: Seq Age Opt Cksum Len
Router: 192 .168 .1.1 192.168.1.1 Ox80000069 1732 Ox22 Ox38b3 72
Router: 192 .168 .1.2 192.168.1.2 Ox80000057 82 Ox22 Ox199f 72
Router: 192 .168 .1.3 192.168. 1.3 Ox8000006d 1201 Ox22 Ox3036 96
Router: 192 .168 .1. 4 192.168. l.4 Ox8000003a 1104 Ox22 Oxefcf 72
Router: 192.168 .1. 5 192 .168.1.5 Ox80000046 1810 Ox22 Ox6411 72
Router: "192.168 .1. 6 192.168. l.6 Ox800000a5 386 Ox22 Oxec31 96
Router: �.
.�- ux r
Router: 192 .168 .2. 2 192.168.2.2 Ox800000d 6 1869 72
Router: 192 .168 .2.3 192.168.2.3 Ox8000005f 1869 72
Router: 192.168.2.4 192.168.2.4 Ox80000004 2260 108

,. OSPF routes are now present for the remote site

inet.0: 40 destinations, 43 r:outes (40 active, holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.10.10.0/30 * [OSPF/10] 01:45:17, metric 2
> via gr-0/0/0.0
10.10.10.4/30 * [OSPF/10] 01:45:17, metric 2
> via gr-0/0/0.0
10.10.10.8/30 * [OSPF/10] 01:45:17, metr:ic 66
> via gr-0/0/0 .0

JUfilL�iifS�ideEducationServices ""'"'""'P""'' 1 13

Contiguous Area O
Once the neighbor is established using GRE over the IPsec tunnel, all link-state advertisements
(LSAs) are processed and routes to each company are installed into the routing table.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-13

Advanced Junos Security

Agenda: IPsec VPN Case Studies and

Solutions

• Routing over VPNs

7 IPsec with Overlapping Addresses
• Dynamic Gateway IP Addresses
• Enterprise VPN Deployment Tips and Tricks

IPsec with Overlapping Addresses

The slide highlights the topic we discuss next.

Chapter 8-14 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

IPsec with Overlapping Addresses Overview

• NAT with I Psec overview
• A IPsec VPN can implement NAT with either route based or
policy based VPNs
• Overlapping address between sites is problematic
• Basic routing rules apply
• Implementing NAT resolves this issue
• Static NAT performs the translation function on the source IP and
destination IP of all traffic destined for the remote network
• The route-based VPN approach is ideal because of the
"virtual" stO network interface

,� -x== > '<"

JUfTIIPer Worldwide Education Services ""'" juniper net
@ r Ne!wor!G, lne,Jlll rfthlnesen,ed.
'�,-
,!"'
-·- ..
I 15

Using NAT with IPsec

With corporate mergers, branch office consolidations, and partner collaborations being
commonplace, often a company must create a VPN to another site with the same private addressing
scheme as its IP network. Because both networks use the same internal IP addressing, it is not
possible to simply build a tunnel between the two sites. However, if the tunnel endpoints on both
sides are Junos security devices, it is possible to configure a tunnel between these sites with an
advanced configuration using Network Address Translation (NAT). NAT can be implemented with
either route-based VPNs or with policy-based VPNs.
It is important to understand this basic routing dilemma. If a host is attached to a network, say
10.0.0.0/24, and the other device on the remote end is attached to a network using the same IP
address subnet, it is not possible to build a tunnel and route the traffic to the other device without
some sort of address translation, because all packets are routed based on the destination IP
address. Before routing occurs, a determination must be made as to whether the destination IP is on
the same (local) network or not. If the destination IP is on the same network, say 10.0.0.10, the
destination device is found using Address Resolution Protocol (ARP). However, if the destination IP
resides on a different network, the packet is sent to the next-hop router based on the device's
routing table.
Continued on the next page.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-15

Advanced Junos Security

Using NAT with IPsec (contd.)

Because both the local and remote networks share the same IP addressing scheme, the packets will
be handled locally and will never be routed to the VPN tunnel. To avoid this situation, we can perform
static NAT on the source IP and destination IP addresses of all traffic destined for the remote
network at the other end of the tunnel. For this reason, a route-based approach to IPsec VPIJs makes
sense, because the creation of a "virtual" network interface on each device using the stO interface is
required.
It is important to note that both the source and the destination addresses are translated as the
packet traverses the VPN tunnel to the end host. Thus, the SRX devices at each end of the tunnel
must contact each other using a newly created IP network. This scenario can introduce some
administrative issues with certain applications, so keep this situation in mind when migrating two
networks with overlapping subnets.
In the case study shown in this section, the SRX devices are configured for static NAT on the stO
interface.

Chapter 8-16 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

Ci11se Study (1 of 3)

Case Study
In this case study Ultimate Music Inc. has purchased Mom-N-Pop Music Shop. Both networks are
currently running OSPF and each network has a single area.
Management in Ultimate Music Inc. wants to establish internal communication with Mom-N-Pop
Music Shop immediately.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-17

Advanced Ju nos Security

Case Study (2 of 3)

• Ultimate Music Inc. has purchased Mom-N-Pop Music

Shop
• A migration team has been formed
• Both networks have a connection to the Internet with a statically
assigned public IP address
• Both networks are using the same network addresses
• The IT manager at Ultimate Music Inc. does not want to
spend additional money at this time
• This migration needs to be completed quickly
• Traffic through the Internet has to be protected because
sensitive corporate proprietary information is being shared

Case Study: Migration Team

Immediately following the acquisition, a migration team is formed to look at all facets of combining
the two companies.
The team must provide a secure method of sharing sensitive internal information. The initial
discussion was about changing the IP address space used in the Mom-N-Pop Music Shop network.
This solution would take too much time and the migration team has been asked to find a different
solution. Whatever the solution is, it must be quickly implemented.

Chapter 8-18 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

Case Study (3 of 3)
--- --: - - --- -......
/
- Ult1mateMus1clnc. -
/ ......._
n '
\
�bJ

/· d � 7=-- ' \
/1:J
I o> ''\_
I, QI
',EJ� /�! &-A ·i ---� - -
'
........ __ '[ � // ·�I
/ r� / ,
OSPF Area O u,

�kJ \
EI

- - - - El \
..,:;

_ /
I / Mom-N-Pop
Mus1cShop
TI · - \
�
\ /. El )
-
\, -� CT3PFAf:o/

' bJ /
����-�---·
�j ,ij:lJU�
........ ___
_ !P�_ �rldwideEclucationServices .,,,.,1un,pern,l 1 19

Case Study: Migration Topology

The migration team decided to implement an IPsec VPN tunnel between the two sites over the
existing Internet connections. This solution allows all internal communication from site-to-site to be
encrypted and secure.
Because both networks are currently using the same network addresses, the migration team has
decided that they also need to implement some method of NAT. They must define additional
networks to be used when translating addresses. The migration team identified two networks to be
used. Users from the Ultimate Music site will use the 10.10.10.0/24 network to reach devices in the
Mom-N-Pop Music Shop site. Users from the Mom-N-Pop Music Shop site will use the 10.10.20.0/24
network to reach devices in the Ultimate Music site.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-19

Advanced Junos Security

IPsec with Overlapping Addresses

• Case Study Requirements
• Both networks need to maintain current IP address
• NAT requirements
• Must handle 1 to 1 translation
• Must be bidirectional translation
• Must allow connection requests from either site
• IPsec connection is point-to-point
• All internal traffic must be allowed to pass between sites
through the IPsec tunnel
• Internet traffic should exit each network through their own
Internet connection

Case Study Requirements

This slide outlines the migration requirements. We will be using static NAT to address the NAT
requirements in this case study. Static NAT defines a one-to-one mapping from one IP subnet to
another IP subnet. The mapping includes destination IP address translation in one direction and
source IP address translation in the reverse direction. From the NAT device, the original destination
address is the virtual host IP address while the mapped-to address is the real host IP address. Static
NAT allows connections to be originated from either side of the network, but translation is limited to
one-to-one or between blocks of addresses of the same size.

Chapter 8-20 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

IP:sec with Overlapping Address

C<l•nfiguration (1 of 5)

• Preliminary configuration steps

• Configure the site-to-site route based VPN parameters
• Add IKE to the gateway interface under the proper zone
configuration
• Create policies
• Allow the internal traffic in and out of the VPN
• Allow internet traffic to exit through the un trust zone
• Block traffic from the un trust zone to your protected zone
( trust)
• Add a static default route on the gateway devices with
next-hop of their ISP
• Export this route into OSPF

Preliminary Configuration
The configuration examples provided in the next few pages demonstrate the unique configuration
steps needed to enable static NAT with IPsec tunnels. The topics outlined on this slide are not going
to be explicitly defined with examples in this section. These configuration steps will serve as the
foundation for this case study.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-21

Advanced Junos Security

IPsec with Overlapping Address

Configuration (2 of 5)

• Ultimate Music Inc. gateway NAT configuration

• Indicate incoming interface
• Specify the incoming packets destination address
• Specify the prefix range to translate destination to
[edit se curity natl
user@Corporate-Gat eway# show
static {
rule-set static-nat
from inter fa ce!st 0.0; I
rule translate-overlapping-addresses
matc ___
h { ��������� �
� __,.__,._,.. --, ----.
!destination- address 10.10.20.0 /24;

then { �
! t_a_t�ic- -- n-a-t�p-re
�s_ � .� �0�/�2�4;- -,
- �f�i -x.....,..1�0.- 2�0�.�20

Ultimate Music Gateway's NAT Configuration

The first step to configuring static NAT is to specify the matching traffic. In the example, the NAT rule
will match traffic coming in the stO interface. The next step is to create the rule with the match
criteria. When configuring the NAT rule it is important to keep in mind what direction you are
translating the traffic. For traffic that is coming into interface stO from the IPsec tunnel, the packet
will be destined to a device in the 10.10.20.0/24 network and will match the NAT rule and then be
translated to the real network address on the 10.20.20.0/24 network. Outgoing traffic will be
destined to the remote 10.10.10.0/24 network, sourced from the 10.20.20.0/24 network and will
match the rule in the reverse order, so instead of matching the destination, it will match tM source
and change it to the correct address in the 10.10.20.0/24 network. The configuration for tile
Mom-N-Pop Music Shop gateway is very similar to the configuration on the slide, except the
destination-address should be the network being translated to.

Chapter 8-22 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

IPsec with Overlapping Address

Cc•nfiguration (3 of 5)

• Flouting for remote network

• Create a static route for the remote network and set the
next-hop to the stO interface

[edit couting-options]
usec@Cocpocate-Gateway# show
static (

coute 10.10.10.0/24 next-hop stO.O;

coute 0.0.0.0/0 next-hop 66.124.30.1;

Static Routes
A route entry must be in the routing table to reach the remote Mom-N-Pop Music Shop network. This
slide demonstrates the static route configured on the Ultimate Music gateway to reach the remote
network. You might also note that a static default route is configured to send Internet traffic to the
ISP.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-23

Advanced Junos Security

IPsec with Overlapping Address

Configuration (4 of 5)

• Zone address books

• Zone trust
[edit secucity zones]
usec@Cocpocate-Gateway# show security-zone trust address-book
addcess internal-nets 10.20.20.0/24;
addcess internal-loo 192.168 .1.0/24;
addcess-set ultimate-music {
addcess internal-nets;
addcess internal-loO;

• Zone vpn
[edit secucity zones]
usec@Cocpocate-Gateway# show security-zone� address-book
addcess mom-n-pop-int-net 10.10.10.0/24;
addcess mom-n-pop-int-loO 192.168.2.0/24;
addcess mom-n-pop-stO 10.0.0.0/30;
addcess-set mom-n-pop {
addcess mom-n-pop-int-net;
addcess mom-n-pop-int-loO;
addcess mom-n-pop-stO;

Zone Address Books

When configuring the address books within their zones, it is important to correctly define the
appropriate network addresses. Within the zone that terminates the IPsec tunnel, the remote
network's address book entry needs to be defined as the translated network. As demonstrated on
the slide in the example configuration, the defined network for the Mom-N-Pop Music shop is
10.10.10.0/24. That will be the source address of the packets leaving the IPsec tunnel for 1traffic
being sent from a device in that site. These address book entries are used as matching criterion
when creating the policies, which are illustrated next.

Chapter 8-24 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

IPsec with Overlapping Address

Cc•nfiguration (5 of 5)

• Policy configuration
• Policy for trust zone to vpn zone
[edit secucity policies fcom-zone trust to-zone vpn]
usec@Cocpocate-Gateway# show policy,,ecure-traffic
match (
soucce-addcess ultimate-music;
destination-addcess mom-n-pop;
application any;
)
then (
pecmit;

• Policy for vpn zone to trust zone

[edit secucity policies fcom-zone vpn to-zone trust]
usec@Cocpocate-Gateway# show policy from-mom-n�
match (
soucce-addcess mom-n-pop;
destination-addcess ultimate-music;
application any;
}
then (
pecmit;

Policy Configuration
The slide provides an example of what the policy configuration should look like when allowing traffic
in and out of your protected (trust) zone.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-25

Advanced Junos Security

IPsec with Overlapping Address

Verification (1 of 2)

• Static NAT statistics

• Verify configured parameters
• View translation hits
user@Corporate-Gateway> show security nat static rule all
Tota 1 static-nat rules: 1

Static NJl.T rule: translate-overlapping-addresses Rule-set: static-nat

Rule-Id 1
Rule position 1
From interface stO .0
Destination addresses 10.10.20.0
Host addresses 10.20.20.0
Netmask 24
Host routing-instance N/A
Translat ion hits 2162

Verifying Static NAT

The command shown on the slide can be used to review the static NAT rules defined on the· local
device. The command will also display the number of times the rule has been used to translate
addresses.

Chapter 8-26 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

IPsec with Overlapping Address

VEtrification (2 of 2)

• Verify flow details

• Session 4 54 6 are packets sourced from remote site
• Session 4 54 7 are packets sourced from local site

L
u::>er@Corporate-Gateway> show security flow session

,ssion IO: 4546, Policy name: from-mom-n-pop/8, Timeout: 4, Valid

In: 10.10.10.2/6 --> 10.10.20.2/1382;icmp, If: st O.O, Pkts: 1, Bytes: 84

L
Out: 10.20.20.2/1382 --> 10.10.10.2/6;icmp, If: ge-0/0/3.0, Pkts: 1, Bytes: 84

,ssion ID: 4547, Policy name: secure-tr affic/5, Timeout: 4, Valid

In: 10.20.20.2/226 --> 10.10.10.2/38703;�7mp, If: ge-0/0/3.0, :kts: 1, B�tes: 84
Out._ 10.10.10.2/38703 --> 10.10.20.2/226,icmp, If.. stO.O, Pkts. 1, Bytes. 84
Tota.L sessions: .L..;

Verify Flow Details

The command illustrated on the slide can be used to see current flow details for sessions that have
been created on the local device. The output is displaying the flow details for two ping sessions. One
session is generated from a device within the local network destined to a device in the remote
network (Session ID: 4547). The second session is in the reverse order (Session ID:
4546).

www.juniper.net !Psec VPN Case StudiP.s and Solutions • Chapter 8-27

Advanced Junos Security

Agenda: IPsec VPN Case Studies and

Solutions

• Routing over VPNs

• IPsec with Overlapping Addresses
7 Dynamic Gateway IP Addresses
• Enterprise VPN Deployment Tips and Tricks

Dynamic Gateway IP Addresses

This slide highlights the topic we discuss next.

Chapter 8-28 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

D)rnamic Gateway IP Address

• Overview
• Many ISPs dynamically assign IP addresses to customers
using DHCP
• This situation becomes problematic when trying to establish a VPN
tunnel to an IP address tl1at is not statically assigned
• Gateway devices can use a hostname as their IKE ID
• This ability allows IKE to negotiate and verify identities using the
hostname instead of the IP address

Dynamic Gateway Overview

Many ISPs dynamically assign addresses to their customers from a pool of public addresses that
they own using Dynamic Host Configuration Protocol (DHCP). This dynamic assignment can be
problematic when trying to create an IPsec tunnel to a remote site with a dynamically assigned IP
address. If you were to use their IP address as the remote gateway address on the local device and it
changed due to the renewal process, this change could cause substantial Joss of valuable traffic. It
could also cause some frustration trying to troubleshoot the !Psec VPN that was previously working.
As an alternative to using the IP address to verify the remote device's identity you can use the
hostname as the IKE ID.

www.juniper.net !Psec VPN Case Studies and Solutions • Chapter 8-29

Advanced Junos Security

,.,,.,.... -- ---..

Case Study
In this case study Ultimate Music Inc. has purchased Mom-N-Pop Music Shop. Both networks are
currently running OSPF and each network has a single area.
Management in Ultimate Music Inc. wants to establish internal communication with Mom-M-Pop
Music Shop immediately.

Chapter 8-30 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

Ci1se Study (2 of 3)
• Ultimate Music Inc. has purchased Mom-N-Pop Music
Shop
• A migration team has been formed
• The gateway device at Ultimate Media Inc. has a statically assigned
public address
• The gateway device at Mom-N-Pop Music Shop is receiving a
dynamically assigned IP address from their provider
• No overlapping addresses exist between these two networks
• The IT manager at Ultimate Music Inc. does not want to
spend additional money at this time
• This migration needs to be completed quickly
• Traffic through the Internet has to be protected because
sensitive corporate proprietary information is being shared

z �*""
.;:JIJtlCil8�!r
'l -.�

efWOM,llt"-Allrt�1tM<d, ' WoildlititleEducationSeivices """'IUniperne\ I 31

'M'�-�--- ··=

Case Study: Migration Team

Immediately following the acquisition, a migration team is formed to look at all facets of combining
the two companies.
The team must provide a secure method of sharing sensitive internal information. The initial
discussion was about creating an IPsec tunnel between the sties and creating a static route to the
remote network on each gateway device. The migration team found that the Mom-N-Pop Music
Shop's ISP is dynamically assigning their public IP address. The migration team contacted the ISP to
discuss the possibility of assigning a static IP address and were told that it would cost additional
money. The migration team is not allowed to spend any additional money at this time. The migration
team has been asked to find a different solution. Whatever the solution is, it must be quickly
implemented and at no additional cost to the company.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-31

Advanced Junos Security

Case Study (3 of 3)

IP Address
dynamically
assigned

Case Study: Migration Topology

The migration team decided to implement an IPsec VPN tunnel between the two sites over the
existing Internet connections. This solution allows all internal communication from site-to-site to be
encrypted and secure.
Because the gateway device at the Mom-N-Pop Music Shop is receiving their public IP address
dynamically, the migration team has decided to use the hostname option as the IKE ID foi- this
device.

Chapter 8-32 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

o,,namic Gateway IP Address

• Case Study Requirements

• IPsec connection is point-to-point
• The IKE identity on the Mom-N-Pop Music Shop gateway
device must use the hostname option
• All internal traffic must be allowed to pass between sites
through the IPsec tunnel
• For the purpose of this example. a route based VPN is used
• Internet traffic should exit each network through their own
Internet connection

Case Study Requirements

The slide outlines the network requirements for the case study.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-33

Advanced Junos Security

Dynamic Gateway IP Address

Configuration (1 of 4)

• Interface configuration
• Standard s to configuration on both sides
[edit interfaces]
user@rnorn-pop-gateway# show stO
unit O {
family inet {
address 10.0.0.2/30;

• External facing interface is configured to allow DHCP from

the provider (Mom-N-Pop gateway)
[edit interfaces]
user@rnorn-pop-gateway# show ge-0/0/2
unit O {
farn ily inet
dhcp;

Interface Configuration
For the purposes of this case study, the IPsec VPN is a route-based VPN. The slide demonstrates the
interface configuration for the stO interface as well as the Mom-N-Pop Music Shop's external
interface. As mentioned earlier, this interface is receiving its IP address dynamically from their ISP.

Chapter 8-34 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

D)rnamic Gateway IP Address

C«J•nfiguration (2 of 4)

• Zone configuration
• External facing interface must allow DHCP and IKE within
the appropriate zone (Mom-N-Pop gateway)

[edit secucity zones]

usec@mom-pop-gateway# show security-zone untrust
intecfaces {
ge-O IO /2 . O (
host-inbound-tcaffic {
system-secvices {
ike;
dhcp;

Zone Configuration
The slide demonstrates the external interface configuration under the external zone (untrust). As
the example illustrates, you have to ensure that IKE and DHCP are configured as
host-inbound-traffic on the external interface.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-35

Advanced Junos Security

Dynamic Gateway IP Address

Configuration (3 of 4)

• IKE configuration (Mom-N-Pop gateway)

• Policy mode must be aggressive
• Define the hostname under local-identity hierarchy

[edit security i ke]

user@mom-pop-gateway# �how
policy ike-pol-1 {
jmode aqgressive; I
proposal-set standard;
pre-shared-key ascii-text "$9$ 6st6CpOhSeX7VlR7VwYZG69A"; ## SECRET-DA1:A

gateway gate-1 {
ike-policy ike-pol-1;
address 66.124.30.5;
local-identity hostname "[email protected]";
ex erna -in er ace ge-

Mom-N-Pop's IKE Configuration

To use the hostname option, you must define the mode as aggressive. The hostname is
defined within the gateway hierarchy by specifying local-identity. The example on the slide
sets the IKE ID for this device to srxl@srx. juniper. net. The rest of the IPsec configuration
follows the standard rules for configuration.

Chapter 8-36 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

D1,namic Gateway IP Address

Cc•nfiguration (4 of 4)

• 11-<.E configuration (Ultimate Music gateway)

• Policy mode must be aggressive
• Instead of specifying the IP address for the remote gateway,
specify the hostname

[edit secucity ike]

usec@C ocpocate-Gateway# =how
policy ike-pol-1 {
I
mode a99cess1ve; I
pc oposal-set standacd;
pce-shaced-key ascii-text "$9$6st6CpOhSeX7VlR7VwYZG69A"; ## SECRET-DATA

gateway gate-1 {
ike- olic ike- ol-1;
dynamic hostname "srxl@srx. juniper. net";
externa -inter ace ge-

-��!i��fit'f�·jLJf;l wri:WorldwideEclucationServices www1un,pernet 1 37

��L

Ultimate Music's IKE Configuration

It is required that the mode be the same for both sides of the IPsec tunnel, so you must set the mode
for Ultimate Music's IKE policy to aggressive. Instead of using the address option to specify the
trusted peer, the dynamic hostname option is used. The remote device's hostname is defined under
the dynamic hostname option.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-37

Advanced Junos Security

Dynamic Gateway IP Address

Verification (1 of 2)

• Verify DHCP information

• Display IP address
• Verify lease time
• Review other options
usec@mom-pop-gateway> show system services dhcp client

Logical Intecface name ge-0/0/2 .0

Hacdwace addcess OO:ld:b5:0e:27:82
Client status bound
77 .128.30.10 I
disa bled
obtained at 2011-02-12 01:35:06 UTC
expices at 2011-02-13 01:35:06 UTC

DHCP options:
Name: secvec-identifier, Value: 77.128.30.1
Code: 1, Type: ip-addcess, Value: 255.255.255.0
Name: coutec, Value: [ 77.128.30.1]
Name: name-secvec, Value: [ 77.128.30.1 ]

Review DHCP Information

The command on the slide can be used to review the current DHCP client information on the gateway
device. The output contains information about the current IP address lease including the IP address
that has been assigned by the ISP.

Chapter 8-38 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

D}rnamic Gateway IP Address

VE�rification (2 of 2)

• Verify SAs
• IKE SA
usec@mom-pop-gateway> show security ike security-associations
Index Remote Address State Initiator cookie Responder cooki e Mode
11 66.124.30.5 UP 66d07f0757497fd8 41424860ea4fa944 Aggressive

IPsecSA
usec@mom-pop-gateway> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Poet Algorithm SPI Life:sec/kb Mon vsys
<131073 66.124.30.5 500 ESP :3des/shal e747c73a 2797/ u nlim coot
>131073 66.124.30.5 500 ESP:3des/shal a8669f0e 2797/ unlim coot

Verifying SAs
The slide serves as verification that both the IKE and IPsec security associations (SAs) have been
negotiated correctly using the hostname configuration.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-39

Advanced Junos Security

Agenda: IPsec VPN Case Studies and

Solutions

• Routing over VPNs

• IPsec with Overlapping Addresses
• Dynamic Gateway IP Addresses
7 Enterprise VPN Deployment Tips and Tricks

Enterprise VPN Deployment Tips and Tricks

The slide highlights the topic we discuss next.

Chapter 8-40 • IPsec VPN Case Studies and Solutions www.juniper.net

Advaneed Junos Security

En1terprise Tips and Tricks (1 of 3)

• Using tcp-mss can eliminate fragmentation of TCP

traffic across tunnel
• Negotiated in 3-way handshake
• Limits the maximum segment size
• Prevents excessive packet fragmentation
• Packetfragmentation increases demand on device resources
• A tcp-mss value of 1350 is a recommended starting point
for Ethernet-based networks with a MTU of 1500 or greater
• Value might need to be altered depending on additional overl1ead
user@srxA# show security flow
tcp-mss {
ipsec-vpn {
mss 1350;

Using tcp-mss Configuration Option

Using the tcp-mss option can eliminate fragmentation of TCP traffic across IPsec tunnels. The TCP
MSS is negotiated as part of the TCP 3-way handshake. It limits the maximum size of TCP segments
to better fit the MTU limits on a network. This limiting is especially important for VPN traffic, because
the IPsec encapsulation overhead along with the IP and frame overhead can cause the resulting
Encapsulating Security Payload (ESP) packet to exceed the MTU of the physical interface, causing
fragmentation. Fragmentation increases bandwidth and demand for device resources and is always
best when avoided. Note that the value of 1350 is a recommended starting point for most
Ethernet-based networks with an MTU of 1500 or greater. The Junos default value is 1320 bytes.
This value might need to be altered if any device in the path has a lower MTU, or if any added
overhead exists such as with Point-to-Point Protocol (PPP), Frame Relay, and so forth. As a general
rule, you might need to experiment with different tcp-mss values to obtain optimal performance.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-41

Advanced Junos Security

Enterprise Tips and Tricks (2 of 3)

• MTU Settings
• Path MTU discovery
• Enabled by default at the system level
• Can be disabled using the no-path-mtu-discovery option at
the system internet-options hierarchy
• SRX services gateway device will try to send ICMP error type 3 code
4 packet to the sending device
• ICM P error message contains the correct MTU to be used by the
sending device
• Interface MTU configuration
• MTU can be increased or decreased at the interface level
depending on network requirements(MTU range is based on
interface type)

MTU Settings
Path MTU discovery is enabled by default on devices running the Junos operating system and can be
disabled by configuring the no-path-mtu-discovery option under the system
internet-options hierarchy. When a Junos device receives a packet that it is not able to
forward because it exceeds the MTU of the next-hop network and the packet has the do-not-fragment
(DF) bit set, the Junos device is required to return an Internet Control Message Protocol (ICIVIP)
Destination Unreachable message to the source of the packet, with the code indicating
fragmentation needed and DF bit is set (ICMP error type 3 code 4 packet). The reporting device must
also indicate the correct MTU to be used by the sending device with the ICMP error messag;es being
sent.

MTU Configuration on Interfaces

The interface's MTU can be manually configured for a specific interface. The available MTU values
depend on the specific interface type. By increasing the MTU, the system is allowed to forward larger
packet sizes than are allowed by default.

Chapter 8-42 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

En1terprise Tips and Tricks (3 of 3)

• Tunnel endpoints and dynamic routing

• Typically a default route is preferred to reach the tunnel
endpoints
• Dynamic routing causes tunnel endpoints to be reachable
through the tunnel
• Dynamic routes for tunnel endpoints are more specific than the
default route
• Creates a route recursion problem. which causes the tunnel to be
torn down
• Process repeats itself as traffic for the tunnel endpoints now
prefers the default route again
• Configure static routes with a /32 netrnask for the tunnel
endpoints

Enabling Dynamic Routing on Tunnel Interfaces

When enabling dynamic routing on tunnel interfaces, IPsec or GRE, you must be aware of possible
recursion problems. Recursion problems typically occur when a very broad route, such as a default
route, is in use to reach the tunnel endpoints. This method of reaching the endpoints works well until
the tunnel interfaces are placed in a dynamic routing protocol, such as OSPF. Once the dynamic
routing protocol forms an adjacency across the tunnel, the specific routing information for the tunnel
endpoints is learned through the tunnel. Now, the devices that are housing the tunnel endpoints
begin sending traffic that is destined for the tunnel endpoints through the tunnel. This behavior
creates a route recursion problem, which results in the tunnel being torn down and the dynamic
routing protocol adjacency being lost. Once the tunnel has been torn down, the preferred route to the
tunnel endpoints is through the default route again, which causes the process to repeat itself. This
behavior results in a flapping tunnel and intermittent connectivity.
To overcome this route recursion problem, the devices that are housing the tunnel endpoints must
have specific routing information that does not become less preferred once the dynamic routing
protocol forms an adjacency over the tunnel. We recommend that you configure static routes that
use a /32 netmask on both devices that allows reachability to the tunnel endpoints. Then, these
static routes must direct the traffic that is destined for the tunnel endpoints through another physical
interface, typically the same interface that the default route is using. This configuration ensures that
traffic that is destined for the tunnel endpoints does not use the tunnel. Then, the dynamic routing
protocol adjacency can form over the tunnel.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-43

Advanced Junos Security

Zone Considerations

• Creating unique zone for VPN traffic

• Used with route-based IPsec VPNs
• Allows the creation of policies specifically for the VPN traffic
• Create deny policies to block individual host

Unique Zone for IPsec VPN Traffic

Creating a unique zone for tunnel traffic allows you to create a set of policies specifically for VPN
traffic while maintaining separation of policies for non-VPN traffic. Using this approach also allows
you greater flexibility in denying specific traffic access to the VPN.

Chapter 8-44 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junos Security

Summary
• In this content, we:
• Configured OSPF over GRE over IPsec VPNs
• Configured IPsec between sites with overlapping IP
addresses
• Configured an IPsec VPN using the hostname as the IKE ID
• Described some IPsec VPN tips and tricks for the enterprise
environment

We Discussed:
Configuring OSPF over GRE over IPsec VPN tunnels;
Configuring IPsec between sites with overlapping addresses;
Configuring an IPsec VPN using the hostname as the IKE ID; and
Some IPsec VPN tips and tricks for the enterprise environment.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-45

Advanced Junos Security

Review Questions

1. In the OSPF over GRE over IPsec VPN case study,

why was GRE required?
2. When using static NAT, which addresses get
translated as traffic traverses the device?
3. What solution can be used when you need to create
a IPsec VPN to a device that does not have a static
IP address?

Review Questions
1.

2.

3.

Chapter 8-46 • IPsec VPN Case Studies and Solutions www.juniper.net

Advanced Junes Security

lm1plementing Advanced IPsec VPN

Sc:i•lutions Lab

• Establish a site-to-site IPsec VPN.

• Enable OSPF over GRE over the IPsec VPN.
• Enable static NAT and IPsec VPN to overcome
overlapping address spaces.

.�
£:�mlftLJffilPef'. WorldwideEducationServices www,un,oernet 1 47
��;;_:,� w

Implementing Advanced IPsec VPN Solutions Lab

The slide provides the objectives for this lab.

www.juniper.net IPsec VPN Case Studies and Solutions • Chapter 8-47

Advanced Junos Security

Answers to Review Questions

1.
GRE was needed because the remote device did not support OSPF directly over the IPsec tunnel. This need
is still somewhat common ,vith interoperability scenarios.
2.

Static NAT translates both the source address and destination address.
3.
You can use the hostname as the IKE ID. The hostname will be used to verify the device's identity.

Chapter 8-48 • IPsec VPN Case Studies and Solutions www.juniper.net

JUntf2y�[
Advanced Junos Security

Chapter 9: Troubleshooting Junos Security

Advanced Junos Security

Objectives

• After successfully completing this content, you will be

able to:
• Utilize a troubleshooting methodology in problem resoluti1on
• Configure logs, traces and packet captures
• Analyze traffic flows
• Identify common IPsec issues

We Will Discuss:
A troubleshooting. methodology;
Logging, traceoptions and packet capture configurations
Traffic flow analysis; and
Common IP Security (IPsec) issues and their identification.

Chapter 9-2 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

A1tenda: TroubleshootingJunos Security

� Troubleshooting Methodology
• Troubleshooting Tools
• Identifying I Psec Issues

{ti;;"" �- (w=m.,;;·�""�0v)F
-�
etN.i..�. ln,:!Mt�111$·M<i, Ul:.lfilmffWol'ldwil:le Education Services ""''" Jun;per net I 3
� """ -::...._�s--

Troubleshooting Methodology
The slide lists the topics we will discuss. We discuss the highlighted topic first.

www.juniper.net Troubleshooting Ju nos Security • Chapter 9-3

Advanced Junos Security

Troubleshooting Overview
• Troubleshooting:
• The ability to identify the root cause of a problem impacting
the network
• The ability to identify the root cause of any deviation from
the normal or expected behavior of a network

Troubleshooting Defined
The purpose of troubleshooting is to identify the root cause of an issue.
Frequently, troubleshooting is thought of only as it applies to tracking down the root cause of a
clearly identifiable problem, generally in terms of the impact it has on a network or a user's ability to
use the network. In reality, it can extend beyond that simple definition to include searching for the
root cause of any deviation from the normal or expected behavior.
When problems do occur, or when the behavior of a network varies from the normal or expected
behavior, identifying the root cause becomes necessary to resolve the issue and eliminate the
negative impact. Additionally, in a production network, doing so in a manner that introduces the least
disruption possible is important.

Chapter 9-4 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

A IProcess .. Based Methodology

• Process-based methodology:
• Learnable
• Repeatable
• Can be used when dealing within any of these elements of a
device running the Junos OS:
• Chassis
• Control plane
• Interfaces and circuits
• Data plane

J.Jl:Jf;'l�
-sc � s_,fil,V»=°"*©°fo �

Nel,.olk>;fllmAll[f�>t• ,,,.,t; ��-rldwideEclucationServices ""'"Junlpernel Is

�'-"")�--d&,caM »�

A Process-Based Methodology
The art of troubleshooting, is not an art at alL But rather a learnable, repeatable, process-based
methodology.
Two individuals working with the same sets of tools and a common symptom might approach the act
of fault analysis in completely different ways. For example, one person might always start with visual
inspection while another opts to begin with interface loopback tests. In the end, stating that one
approach is better than another is difficult, assuming that both individuals arrive at a similar
conclusion, in a similar amount of time with similar levels of disruption.
Although many different approaches to troubleshooting exist, certain fundamental elements are
involved in any sound troubleshooting methodology. Experienced technical engineers likely already
employ many of these techniques, intentionally or otherwise.

www.juniper.net T roubleshooting Junos Security • Chapter 9-5

Advanced Junos Security

Getting to the Solution

• Troubleshooting steps:
• Define success
• Isolate the component preventing success
- Define
Success
]

• Characterize
• Hypothesize
• Predict
• Test and experiment
• Identify a solution - Identify
Solution
J

• Implement the solution Implement

J
Solution

The Troubleshooting Process

Although the scientific method provides a good basis to construct a repeatable methodical
approach, it can be expanded to better fit our needs for troubleshooting.
Some significant differences exist between the need for scientific explanation and troubleshooting.
First, scientists must maintain complete objectivity about the outcome of their process where we
have a known desired outcome. Incorporating this difference into our troubleshooting mod,�I
becomes the first step.
Next, scientists are also dealing with an infinite number of variables, whereas we are dealing with a
finite number of inputs that can interfere with success.
Finally, once we have identified the input that is the root cause of the problem, we must also identify
a resolution and figure out how to implement the fix within a production network with minimal
impact. These important steps must also be incorporated into a troubleshooting model.
The benefit of incorporating a process-based troubleshooting methodology is a more effective and
efficient approach to resolving issues. The slide outlines the four main steps in our troubleshooting
methodology.

Chapter 9-6 • Troubleshooting Ju nos Security www.juniper.net

Advanced Junos Security

CCJ�nfiguration Errors

• Configuration:
• Most plausible in new setup or with recent changes
• Use show systern commit to check for recent changes
• Use show compare to display differences
• Remember to check all devices that could introduce a problem
• Eliminate the control plane as a possibility before focusing
on the data plane
• When configuration errors are suspected. it is OK to quickly
glance at configuration. but rely on operational mode
commands to isolate errors
• The human brain sees what it expects to see

Configuration Errors
Configuration issues are the most likely cause of problems in new setups. They are also the most
probable cause of problems within the control plane. Problems in the control plane can even occur
because changes were made to the configuration of another device within the environment.
The Junos operating system has built-in sanity checks to ensure that all configuration entries are
valid. In some cases, they can also check for completeness, such as ensuring that a referenced
policy exists. This process is different from checking for accuracy because no automated way exists
to check a configuration against intent.
It is common practice to jump directly to viewing the configuration when configuration errors are
suspected. This process is not troubleshooting! It does not guarantee that you will be one step closer
to finding the root cause of an issue. It is okay to take a quick glance at a configuration to see if the
configuration error is readily apparent. However, be wary of spending a lot of time looking at a
configuration for errors, because configurations can be quite long and complex. Any benefit to be
achieved from looking at a configuration is further frustrated because the human brain tends to see
that which it expects to see. It is a much better practice to rely on the output of operational mode
commands when trying to isolate configuration errors.

www.juniper.net Troubleshooting Junos Security • Chapter 9- 7

Advanced Junos Security

Hardware Errors

• Hardware:
• Plausible in new out-of-box setups
• Plausible if new problems show up in established networks
• Can be a delayed effect from improper handling
• Alarms, LEDs, and log files, along with operational mode
command output all prove helpful in troubleshooting
hardware issues
• Try moving the problem
• Generally eliminate hardware as a possibility before
progressing on to software

Hardware Errors
Hardware is a plausible cause of issues that appear in established environments where
configuration is not suspect. It is also possible in new setups, or anytime that hardware has been
moved or relocated-particularly if proper handling techniques were not used.
Always use appropriate handling techniques when working with hardware including proper grounding
and other electrical static discharge (ESD) precautions, because even the slightest electrical influx
can damage the fine traces used in today's electronic equipment. This damage is not always
immediately evident-but it could weaken a trace and could contribute to a future failure.
Several tools are available when troubleshooting hardware, including alarms, LEDs, various log files
and operational mode command output.
Another very useful tactic when troubleshooting hardware is to attempt to move the problem. By
relocating hardware within a device or between devices, it is often possible to identify the problem
component. Remember to take appropriate precautions when a possibility of impacting production
traffic exists.
Because hardware issues are more easily identified than software issues and more likely to occur in
established operating environments, it is generally more efficient to eliminate hardware as a root
cause before proceeding to troubleshoot software.

Chapter 9-8 • Troubleshooting Junos Security www.ju1niper.net

Advanced Junos Security

Ha1rdware Troubleshooting Flowchart

--=::::::::�····..� Display and View Alarms show chassis alarms
show chassis craft-interface

<
1'

View LED Status and

Display Craft Interface show chassis craft-interface

< Parse and View Syslogs

··········• and Act Accordingly
show log messages
show log chassisd
monitor start [messages I chassisd]

show chassis hardware

Display Interface and show chassis fpc
Hardware Status
show pfe statistics error
show interfaces terse
show interfaces interface detail
! Investigate Software Faults show log 1.o�-fi 1.e-name

I FPC = Flexible PIC Concentrator I

Hardware Troubleshooting Flowchart

The artistic aspect of troubleshooting and the myriad ways in which a modern communications
device might malfunction combine to make a definitive set of troubleshooting steps and procedures
an unobtainable goal. The purpose of the hardware troubleshooting flowchart shown on the slide is
simply to provide a set of high-level steps designed to get you started with hardware fault analysis.
Note that reasonable people might disagree on the exact ordering of the steps or the particular
command-line interface (CU) commands that could be used to help isolate a hardware failure (for
example, some might prefer the extensive option to the show interfaces command, whereas
the sample chart calls out the terse and detail options).
Note that two individuals working with the same sets of tools and a common symptom might narrow
their focus in completely different ways. For example, one person might always start with visual
inspection, whereas another opts to begin with interface loopback tests. In the end, it is hard to say
that one approach is better than another, assuming that both individuals arrive at a similar
conclusion, in a similar amount of time, with similar levels of disruption. A certain degree of artistic
license that determines how a particular technician decides to approach a problem will always
remain, however the objective remains the same-narrow the focus.

www.juniper.net Troubleshooting Junos Security • Chapter 9-9

Advanced Junos Security

Software Errors

• Software
• Plausible in new setups. with recent Junos OS upgrades, or
when using new features
• View version and last Junos OS change
show version detail
show system software detail
file list /var/sw/pkg detail I match rollback
• Check online resources for known issues
• Check release notes
www.juniper.net;techpubs/software/junos/
• Searcl1 using keyword search-requires login
www.juniper.net;support (link: Junos Defect Search)

Software Errors
Like configuration issues, software issues are not as likely to cause random failures in established
functional environments. They are more likely to appear with changes, either to the operating
system, or with the utilization of new features. Software is generally suspect once hardware has
been eliminated as a probable cause.
If software errors are suspected, check online references for known issues.
If you are not running the latest version of code, be sure to check the latest release to see if an issue
you are experiencing has been identified and resolved. If an issue is identified in the latest release,
remember to proceed using the normal upgrade procedures including testing the new code in a lab
setting specific to your environment. Bypassing proper testing in a rush to resolve an issue can lead
to different and possibly more disruptive issues.

Chapter 9-10 • Troubleshooting Junos Security www.juniper.net

Advanced Junes Security

SCJ,ftware Troubleshooting

• Troubleshooting software problems:

• First, eliminate hardware as a possible issue
• Review logs for software-related entries
• Verify required processes are running
• Move the problem:
• Can the issue be duplicated on another system using the same
version of the Junos OS?
• Can the issue be duplicated on another system using a different
version of the Junos OS?
• Core files and memory dumps might be required for
advanced troubleshooting

--•••wnmtk:asr ---·- *' 01'·

rNelworks, ln<>AII rlt!t!H•s•Md. 'ii;� JUr.llP€r1;twnrldwide Education Services """ 1un,per not [ 11
' �!"t�s»--

Troubleshooting Software Problems

Once you have eliminated configuration and hardware problems as likely causes, it is time to focus
on software. Begin by reviewing logs for software-related error messages. Also verify required
processes are running using the show system processes command.
You might be able to isolate the issue with simple testing, equivalent to the moving-the-problem
approach used with hardware. Begin by duplicating the symptoms in a nonproduction environment. If
the symptoms can be duplicated, you can test to see if the same symptoms are present in different
releases of the Junes OS.

Advanced Software Troubleshooting

In other situations, more advanced troubleshooting is required.
Today's internetworking software is exceedingly complex. As a result, equally complex bugs that
result from unforeseen circumstances can result in a fatal error within a software process. Most of
these software faults relate to illegal memory operations caused by the process attempting to read
or write data from a memory area outside the boundaries allocated for that process. In some cases,
faulty hardware, such as failing memory, can cause stack or register corruption that leads to a fatal
error in a software process. Core and log file analysis are used to determine whether hardware errors
have led to a software panic. A core file represents the set of memory locations and stack data that
was in place at the time of the fault. A copy of the binary image that left the core file (with debug
symbols included) is then run against the core file using a debugger to enable problem diagnosis by
a Juniper Networks software engineer to help isolate the root cause.

www.juniper.net Troubleshooting Junes Security • Chapter 9-11

Advanced Junos Security

Software Troubleshooting Flowchart

Hardwar e Is OK

•.•..••..•,.. Pars e and View Syslogs

and Act Accordingly
show log messages
monitor start messages

Display Running
show system processes
Processes show system connections
file show /etc/services

D etermin eWhether
show system core-dumps
�
Co
F' I ?
�-···········• co_ r_ e _F_il es
_ _AI_ e_P_r _es_e_n_ t__.
.....
file list /var/tmp/*core*
file list /var/crash/*cor,�*

lnvesdgate I nterface Faults

Software Troubleshooting Flowchart

The purpose of the software troubleshooting flowchart shown on the slide is simply to provide a set
of high-level steps designed to get you started on the path of software-related troubleshooting. Note
that as with the hardware flowchart, reasonable people might disagree on the exact ordering of the
steps or on the particulars of the CU commands that could be used to help isolate a software failure.

Chapter 9-12 • TroubleshootingJunos Security www.juniper.net

Advanced Junos Security

Ag:enda: TroubleshootingJunos Security

• Tiroubleshooting Methodology
7 Troubleshooting Tools
• Identifying IPsec Issues

�= ,.�-,,,,,._, �=
""}-'iJ JLJ!i}l��
,<

@ rNa1worl<>, rne Alf ri�lrn,;e,,,.d • ide Education Se1Vices ..,,,., 1uniper na1 J 13
-1'.::��

Troubleshooting Tools
The slide highlights the topic we discuss next.

www.juniper.net Troubleshooting Junos Security • Chapter 9-13

Advanced Junos Security

Operational show Commands

• Junos CLI show commands are usually the first tool to

use in identifying a problem
user@srx> show security ?
Possible completions:
alarms Show active security alarm information
alg Show ALG security services information
application-firewall Show security application firewall policies
application-tracking Show Application tracking information
dynamic-policies Show security firewall dynamic policies
dynamic-vpn Show Dynamic VPN Remote Access information
firewall- authentication Show firewall authentication tables, information
flow ShOW' flow information
group-vpn Show Group VPN Security information
idp ShOW' Intrusion Detection and Prevention information
ike Show Internet Key Exchange information
ipsec ShOW' IP Security information
keychain Show all protocols keych ain
log Show auditable security log infoonation
match-policies Show security match policies
monitoring Show :iecurity SPU monitori ng information
nat Show Network Address Translation information
pki Show public-key infrastructure information
policies ShOW" security firewall policies
resource- manager Show resource manager security services infoonation
screen Show screen service infonnation
softwires Show soft:wire information
user-identification Show user- identification information
utrn Show security utrn information
Show security zone information

Start with show

TheJunos CLI and its operational commands available for monitoring theJu nos security de,vice
should be your first stop in most instances of problem resolution. The slide displays the large variety
of show security commands available. To get a good start in problem resolution, use tl1e
appropriate commands to narrow down the issue. For example, the show security ik,e
security-associations and show security ipsec security associations
commands will help narrow down your focus in investigating the failure of an IPsec tunnel
negotiation. However, the show interfaces terse command might lead you down a completely
different path while investigating the same IPsec issue. We will discuss IPsec troubleshooting in
more detail later in this chapter.
Spend some time looking at the various outputs associated with the command on this slide· either in
the associated lab in this course or on your own device.

Chapter 9-14 • TroubleshootingJunos Security www.juniper.net

Advanced Junes Security

Cctntrol Plane Logging

• Configure messages log or new custom log to gather

data about control plane events:
[edit system syslog]
user@srx# show
user * {
jany emergency;!

host 10.0.0.1 {
1securityj notice;
match IDP;
source-address 192.168.0.1;

fil,� !defaul t-log-messagesi

any any;
authorization info;
!structured-data;!

• Use show log 1.og-name command to view the output

4;: "d"""°"'== fr:'efp'?i>
Jllm,c$, ln¢Alhl@ibire,e,..d. 'u -01si.Jlllf!l� �orl�ide Echu:ationServices www 1unlpernet 1 15
-'.

Control Plane Logging

All Junos devices support the logging of control plane events both locally and to a remote logging
device such as the Juniper Networks Security Threat Response Manager (STRM) device. To configure
local control plane logging, configure a filename, facility and severity. The example on the slide
shows a local file named default-log-messages. Although, you can choose any file name, the
default-log-messages file name allows the device to work in tandem with Juniper Networks
Network and Security Manager (NSM) products. The structured-data configuration option
results in labels for most fields in syslog messages.
To configure control plane logging to a remote syslog server, include the host statement as shown
on the slide. The slide also shows an example of real-time logging. You can specify a user or use the
asterisk wildcard to enable syslog messages displayed in real-time to users logged into the device.
Control plane logs are stored in the /var/ log directory and can be viewed with the show log
log-name operational mode command.

www.juniper.net Troubleshooting Junos Security • Chapter 9-15

Advanced Junos Security

Data Plane Logging

• Use the security log to send data plane logs to an

external server:
[edit security log]
user@srx# show
mo e even ; ------ Allows high-end devices to capture data plane
-
event-rate 1000; logs locally
format sd-syslog;
source-address 192.168.0.1;
stream collector! {
host {
10.0.0.1;

stream collector2
host {
10.0.0.2;
port 1514;

• Required for high-end devices; optional for branch devices

Data Plane Logging

On branch SRX devices, the Junos OS logs data plane logs locally by default. However, you can
isolate data plane events by sending them to a remote server by configuring a stream undN the
[edit security log] configuration hierarchy as shown on the slide.
On high-end SRX devices, data plane logs are not logged by default. Due to the high rate of
connections, data plane logging must be configured using a stream under the [edit security
log] hierarchy. However, you can log high-end SRX data plane events locally by configuring the
mode event option. To avoid over-utilization of the control plane, it is highly recommended to limit
local data plane logging for high-end SRX devices to 1000 logs per second as shown on the, slide.
Currently, the Junos OS supports up to two separate streams for external data plane logging.

Chapter 9-16 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

De!fault Services Logs

• Default SRX services logs

•• IPsec information logged to /var/log/kmd
•• Chassis clustering information logged to /var/log/jsrpd
•• UTM information logged to /var/log/utmd
•• IDP information logged to /var/log/idpd
use :::-@s rx> show log j srpd I match secondary
May 3 18:03:32 RG-0 hold timer, HOLD->SECONDARY
May 3 18:03:32 pushing rg_info for RG-0 with failover-cnt O, state: secondary into ss am.
Result success, error: 0
May 3 21:35:56 skipping reth creati on on RG-0 secondary node
May 3 21:36:26 RG-1 hold timer, HOLD->SECONDARY
May 3 21:36:26 pushing rg_info for RG-1 with failover-cnt 0, state: secondary into ssam.
Result success, erro r: 0
May 3 22:43:12 RG-1 SECONDARY->PRIMARY due to current primary node having O priority
May 3 22:53:18 RG-0 secondary->PRIMP..RY due to device failure
Nov 6 21:14:49 RG-0 hold timer, HOLD->SECONDARY
Nov 6 21:14:49 pu shing rg_info for RG-0 with failover-cnt O, state: secondary into ssam.
Result success, erro r: 0
Nov 6 22:04:57 secondary state: child name:ge-0/0/2, monitoring state:1, link state:
Nov 6 22:04:57 secondary state: child name:ge-5/0/2, monitoring state:1, link state:

No!.,oifts,fu.(AlFrt$11t�rM�� �� lllllfuuilf-%
�--
fl lf!�dtlwide EducationSer;lces
� -
..,,.,., 1un,per n<l I 17

Default Logs
By default, Junos security devices maintain several daemon logs representing various security
services. To save resources, many of the default logs only log a minimal amount of information. Most
of the default security services Jogs can be enhanced through the configuration of traceoptions.
The slide displays a few of the common security services daemon Jogs as well as an example output
of the j srpd Jog, which houses information regarding high availability chassis clustering.

www.juniper.net Troubleshooting Junos Security • Chapter 9-17

Advanced Junos Security

Traceoptions Overview

• Tracing is the Junos OS equivalent of debug

• Requires configuration
• Provides local and remote logging support
• Logs are written to /var/ log/ filename or a remote server
• Can enable tracing in a production network

Hear Tracing, Think Debug

Tracing is the Junos term for what other vendors sometimes call debug. In most cases, when you
enable tracing (through configuration), you create a trace file that is used to store decoded protocol
information received or sent by the Routing Engine. The Junos OS sends the tracing results to a
specified file stored in the /var /log directory or to a remote syslog server.
To enable remote logging of control plane events (we already discussed remote logging of data plane
events, which includes tracing), specify a syslog server at the [edit system tracing:
hierarchy level as shown in the following screen capture:
[edit system tracing]
user@srx# show
destination-override syslog host 1.1.1.1;
Continued on the next page.

Chapter 9-18 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security
Hear Tracing, Think Debug (contd.)
You might see a warning when using the remote syslog server option. If the syslog server is
configured properly and you have verified that the logs are being received on the server, you can
safely ignore the warning. The following is a sample warning:
[edit]
user@srx# commit
[edit protocols ospf]
I
trc.ceoptions I

wa.rning: No file specified.

commit complete
Because of the design of the Junos OS, you can enable detailed tracing in a production network
without significantly impacting performance. Even so, you should always remember to turn off
tracing once you have completed your testing to avoid unnecessary resource consumption.

www.juniper.net Troubleshooting Junos Security • Chapter 9-19

Advanced Junos Security

Traceoptions Configuration Example

• Include the traceoptions statement at the [edit

protocols protocol-name] hierarchy level
• Traceoptions is also available for other hierarchies
The protocol or function being traced
File where trace results are written
__......., (/vac/ log/ospf-tcace)

[edit protocols ospf]

user@srx# show
traceoptions {
file ospf-trace replace size 128k files 10 no-stamp no-world-readabh,;
flag event detail;
flag error detail;

Trace file options

Gan trace multiple options (fiags) to a single file-­

fiags identify what aspects of the protocol are
traced and at what level of detail

Traceoptions Configuration Example

Trace the operations of a specific protocol by including the traceoptions statement at the [edit
protocols protocol -name] hierarchy. In most cases you should be selective in what you trace
because selecting the all keyword will likely provide too much detail. The sample OSPF Protocol
stanza on the slide reflects a typical tracing configuration that provides details about OSPF events
and errors. In many cases you will want to use the detail switch with a given protocol flag for the
added information often needed in troubleshooting scenarios.
Continued on the next page.

Chapter 9-20 • Troubleshooting Junos Security www.juniper.net

Advanced Junes Security
Traceoptions Configuration Example (contd.)
The following are configuration options for tracing files:
file filename: Specifies the name of the file in which to store information.
size size: Specifies the maximum size of each trace file, in kilobytes (KB),
megabytes (MB), or gigabytes (GB). When a trace file named trace-file reaches this
size, it is renamed trace-file. o. When the trace file again reaches its maximum
size, trace-file. o is renamed trace-file. l, and trace-file is renamed
trace-file. o. This renaming scheme contin�es until the maximum number of trace
files is reached. The software then overwrites the oldest trace file. If you specify a
maximum file size, you also must specify a maximum number of trace files with the files
option. The default size is 128 KB.
files number: Specifies the maximum number of trace files. When a trace file
named trace-file reaches its maximum size, it is renamed trace-file. o, then
trace-file. 1, and so forth, until the maximum number of trace files is reached. The
software then overwrites the oldest trace file. The default is ten files.
no-stamp: Prevents timestamp information from being placed at the beginning of
each line in the trace file. By default, if you omit this option, timestamp information is
placed at the beginning of each line of the tracing output.
replace: Replaces an existing trace file if one exists. By default, if you omit this
option, tracing output is appended to an existing trace file.
readable: Allows any user to view the file.
no-world-readable: Allows only the user who configured the file to view it. This
setting is the default setting.
As mentioned on the slide, traceoptions are also available at other configuration hierarchies.
Including the traceoptions statement at the [edit interfaces interface-name]
hierarchy level allows you to trace the operations of individual interfaces. You can also trace the
operations of the interface process, which is the device-control process (dcd).
When tracing a specific interface, the specification of a trace file is not supported. The Junos kernel
does the logging in this case, so the tracing information is placed in the system's messages file. In
contrast, global interface tracing supports an archive file; by default, /var/ log/ dcd is used for
global interface tracing.

www.juniper.net Troubleshooting Junes Security • Chapter 9-21

Advanced Junos Security

Flow Traceoptions
• Use to perform detailed analysis of traffic flows
through Junos security device
• Configuration example
[edit security flow]
user@srx# show
traceo ptions {
file file-name;
flag basic-datapath;
packet-filter filter-name
source-prefix source-address/mask;
destination-prefix destination-address/mask;
source-port source-port;
destination-port destination-port;

Tracing Security Flows

When troubleshooting Junos security devices, and specifically flow-based session creation and
tear-down, security flow traceoptions deserve special coverage and consideration. By configuring a
traceoptions file that flags the basic-datapath of a flow, you can performed detailed monitoring
of flow-based processing on your Junos device. The slide shows the configuration of security flow
traceoptions complete with a packet filter to trim the file's output.
It is important to note that trace packet filters should be configured from the device's perspective. In
other words, before any Network Address Translation (NAT) translation has been applied.

Chapter 9-22 • Troubleshooting Ju nos Security www.juniper.net

Advanced Junes Security

Tr.icing a Blocked Flow (1 of 5)

• Topology Example
ge-0/0/0
.,,. -1.-1_9_2 ._168_.2_2 _4._3/_ 2_4 ___.EJ
fe-0/0/7
_____1_.1_.1_.50_/;...2_4_,@
-
: ::
�;J� __

1.1.1100 d•)iiffili44A¥J·I � Public IP 11.1.30

Private IP 192.168. 2 24.30

• Traceoptions configuration
[edit security flow traceoptions]
use r@s r:x# show
file flow"tra ce;
flag basic-datapath;
packet-filter MatchTraffic
source-prefix 1.1.1. 0/24;
destination-prefix 1.1.1.30/32;

packet-filter MatchTrafficReverse {
source-prefix 192.168.224.30/32;
destination-prefix 192.168.224.3/32;

Blocked Flow Tracing Example: Part 1

The slide displays the topology and flow traceoptions configuration we will use to demonstrate the
usefulness of flow tracing. In this scenario, a user at IP address 1.1.1.100 is sending Remote
Desktop Protocol (RDP) traffic to a remote server. T he server traffic is translated using NAT.

www.juniper.net Troubleshooting Junos Security • Chapter 9-23

Advanced Junos Security

Tracing a Blocked Flow (2 of 5)

The Junos OS captures a packet from source address 1 .1.1.10 0 (source port 5765�
destined to 1.1.1.30 port 3389. with th e protocol number six for TCP.
__J
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT:<1.1.1.100/57650->1.1.1.30/3389;6>
matched filter MatchTraffic:

The IPID of the packet shows 885. which is useful for comparing packets across
multiple capture points. (For example. viewing packet on originating device.
SRX device. and destination device to make sure the packet arrives).

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT:packet [48] ipid = 885, @422ec91e

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT:---- flow_process_pkt: (thd 1):
J
flow_ctxt type 13, conunon flag OxO, mbuf Ox422ec780
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: flow process pak fast ifl 69 in_ifp
fe-0/0/7.0

l�T_ h_ i_s p_ a_ ck
_ _et_ a
_ _niv
·_ _ e_d_ o_n�po_r t_ fe
_ _-_O_i0_;_·1._ o�. ����������������
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: fe-0/0/7.0:1.1.1.100/57650-
>1.1.1.30/3389, tcp, flag 2 syn

Blocked Flow Tracing Example: Part 2

The slide illustrates the initial logged messages of our example transaction.

Chapter 9-24 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Tr.icing a Blocked Flow(3 of 5)

I The .Junos OS performs flow lookup based on the five tuples.

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: find flow: table Ox4dd31658, hash

32955(0xffff), sa 1.1.1.100, da 1.1.1.30, sp 57650, dp 3389, proto 6, tok

I
448

No existing session is found in the table so the Junos OS begins first path process.

Feb 12 16:22:22 16:22:21.1100315:CID-O:RT: no session found, start first path.

in._tunnel - O, from_cp_flag - 0
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: flow_first_create session

I The .Junos OS first processes the destination to check if it should be translated.

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: flow-first-in-dst-nat: in <fe-

0/0/7.0>, out <N/A> dst_adr 1.1.1.30, sp 57650, dp 3389
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: chose interface fe-0/0/7.0 as
incoming nat if.

! The destination should be translated from 1.1.1.30 to 192.168.224.30.

Feb 12 16 :22:22 16:22:21.1100315:CID-0:RT:flow_first_rule_dst_xlate: packet

1.1.1.100->1.1.1.30 nsp2 0.0.0.0->192.168.224.30
G•

Blocked Flow Tracing Example: Part 3

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

www.juniper.net Troubleshooting Junos Security • Chapter 9-25

Advanced Junos Security

Tracing a Blocked Flow (4 of 5)

To determine what the destination interface and zone should be, the Junos OS
performs a route lookup. This allows the Junos OS to do a policy lookup.

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT:flow_first_routing: call

=:J
flow_route_lookup(): src_ip 1.1.1.100, x_dst_ip 192.168.224.30, in ifp re-
0/0/7.0, out ifp N/A sp 57650, dp 3389, ip_proto 6, tos O
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT:Doing DESTINATION addr route-lookup

The route lookup points out the interface ge-0/0/0.0 with a next hop that is the
destination on the attached 192.168.224.0/24 network.

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: routed (x_dst_ip 192.168.224.30)

=:J
=:J
from untrust (fe-0/0/7.0 in 0) to ge-0/0/0.0, Next-hop: 192.168.224.30

The Junos OS performs a policy lookup that shows that the destination zone on
ge-0/0/0.0 is trust. and the packet arrived on fe-0/0/7.0 in the untrust zone.

Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: policy search from zone untrust:->

zone trust
Feb 12 16:22:22 16:22:21.1100315:CID-0:RT: app O, timeout 1800s, curr ageout
20s
�1{��- "'��� mp•
":Vl:.Jf11PE:f'
so

- - erved.�,': ;";, ,
©W13Junip•rN•tw•ro, Inc. "11 rights ,.�
"�-�
Worldwide Education Services
.
WW\"'J

Blocked Flow Tracing Example: Part 4

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

Chapter 9-26 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Tr4c1cing a Blocked Flow (5 of 5)

�Junos OS drops the packet and cancels the session due to the lack of a security
��y.
Aug 12 16:22:22 16:22:21.1100315:CID-0:RT: packet d ropped, denied by policy
Aug 12 16:22:22 16:22:21.1100315:CID-0:RT: packet dropped, policy deny.
Aug 12 16:22:22 16:22:21.1100315:CID-0:RT: flow find session returns error.
Aug 12 16:22:22 16:22:21.1100315:CID-0:RT: ----- flow_process_pkt re Ox7 (fp
re -1)

Blocked Flow Tracing Example: Part 5

The slide displays the conclusion of our blocked trace example. The session is dropped due the lack
of a matching security policy.

www.juniper.net Troubleshooting Junos Security • Chapter 9-27

Advanced Junos Security

Tracing an Allowed Flow (1 of 8)

The Junos filter captures a packet from source address 1.1.1.100 (sourceport 51�103) I
destined to 1.1.1.30 por t 3389.with the protocol number six for TCP.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:<1.1.1.100/51303->1.1.1.30/3389;6>

matched filter MatchTraffic:

The IPID of the packet show s as 5015.which is useful for comparingpackets acro s
:J
multiple capture points (for example.viewing packet on the originating device, on the
SRX device .and on the destination device to make sure the packet arrives).
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:packet [48] ipid = 5015, @423d7e9e
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:---- flow_process_pkt: (thd 1):
flow_ctxt type 13, common flag OxO, rnbuf Ox423d7d00

I is
_ _ t _ a_ r_r_ive
�T_h_ _ _p_a_cke _d_ _o_n_p_o_r _t _fe_-_o;_ o_;_-_r._o _.________________________________ ::===J
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: flow process pak fast ifl 72 in_ifp
fe-0/0/7.O

Allowed Flow Tracing Example: Part 1

Using the same scenario, we will now examine the output flow trace messages from the session if it
were allowed by security policy. On the slide the first packet is received matching our traceoptions
packet filter.

Chapter 9-28 • Troubleshooting Junos Security www.ju1niper.net

AdvancedJunos Security

Tracing an Allowed Flow (2 of 8)

fAcieep:r look �t the packet shows that it is the TCP SYN packet of the connection.
�;atingthe first packet of the flow.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: fe-0/0/7.0:1.1.1.100/51303-

>1.1.1.30/3389, tcp, flag 2 syn

The .Junos OS performs a packet lookup with the previous information. where
sa = 8ource address. da =destination address, sp = so urce port. dp =destination port.
proto = protocol. and tok = token.
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: find flow: table Ox5258d7b0, hash
17008(0x ffff), sa 1.1.1.100, da 1.1.1.30, sp 51303, dp 3389, proto 6, tok
448

l The .Junos OS is unable to find an existing session and creates a new one.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: no session found, start first p ath.

in_tunnel - O, from_cp_flag - O
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: flow first create session
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: flow-first-in-dst nat: in <fe-
0/0/7.0>, out <N/A> dst adr 1.1.1.30, sp 51303, dp 3389

, ru � - =,q ,
. e!,.•!'l!S: nmAii,rft11!•"' Md ·;::;�ITT� Worldwide Education Services "w" iunlper not J 29
"�-�es �xo=x=

Allowed Flow Tracing Example: Part 2

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

www.juniper.net TroubleshootingJunos Security • Chapter 9-29

Advanced Junos Security

Tracing an Allowed Flow (3 of 8)

Before a policy lookup is performed. the Junos OS checks for destination NAT. In this
case static NAT is configured. which translates the 1.1.1.30 address to
192.168.224.30. This lookup must be performed before the route lookup. because if
there is a destination NAT translation. the Junos OS needs to perform a route lookup
on the translated destination address.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: chose intecface fe-0/0/7.0 as

incoming nat if.
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:flow_ficst cule_dst_xlate: packet
1.1.1.100->l.l.l.30 n sp2 0.0.0.0->192.168.224.30.

I TheJunos OS performs a route lookup.

�
Feb 4 16:21:02 16:21:00.187 2004:CID-0:RT:flow ficst couting: call
flow_rnute_lookup(): scc_ip 1.1.1.100, x_dst_ip 192.168.224.30, in ifp te-
0/0/7.0, out ifp N/A sp 51303, dp 3389, ip_pcoto 6, tos O
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:Doing DESTINATION addc coute-lookup
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: couted (x dst ip 192.168.224.30)
fcom untrust (fe-0/0/7.0 in 0) to ge-0/0/0.0, Next-hop: 192.168.224.30

Allowed Flow Tracing Example: Part 3

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

Chapter 9-30 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Tria1cing an Allowed Flow (4 of 8)

heJunos OS performs a policy lookup and sets the session timeout parameters.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: policy search from zone untrust->

zone trust
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: policy has timeout 900
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: app 0, timeout 1800s, curr ageout
20s

TheJunos OS displays the source NAT pool used for this session.

Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:flow-first -src-xlate: src nat

0.0.0.0(51303) to 192.168.224.30(3389) returns status 1, rule/pool id 1/2.

TheJunos OS uses DIP id 2/0. The term DIP is a legacy ScreenOS term. The log shows
that the Junos OS is translating the source from 1.1.1.100 (source port 51303) to
192.168.224.3 (source port 48810). In this example. translation is needed because
the destination host 192.168.224.30 does not know about the 1.1.1.0/24 network.
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: dip id = 2/0, 1.1.1.100/51303-
>192.168.224.3/48810

Nolwurk$,· �rl:lftt>'™"""'' Ul!JGll,Bi ti\$"' '

�C!rl�ideEducationServices """"'unipernet J 31
.J'.....>i,tL -

Allowed Flow Tracing Example: Part 4

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

www.juniper.net Troubleshooting Junos Security • Chapter 9-31

Advanced Junes Security

Tracing an Allowed Flow (5 of 8)

The Ju nos OS chooses ge-0/0/0 as the egress interface for the flow. ----i
____________J
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: choose interface ge-0/0/0_0 as
outgoing phy if
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:is_loop_pak: No loop: on ifp: ge-
0/0/0-0, addr: 192-168-224.30, rtt_idx:O

The Ju nos OS matches the flow to policy 9 and determines other services processing is
I
not applicable to this flow.
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:policy is NULL (wx/pim scenario)
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:sm flow interest check: app_id 0,
policy 9, app_svc_en O, flags Ox2. not interested
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:sm flow interest check: app_id 1,
policy 9, app_svc_en O, flags Ox2. not interested
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT:flow _first_service_lookup():
natp(Ox51ee4680): app_id, 0(0).
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: service lookup identified service 0.

Allowed Flow Tracing Example: Part 5

The slide displays the next messages and explanations in a series of flow traceoptions from our
example transaction.

Chapter 9-32 • Troubleshooting Junos Security www.juniper.net

Advanced Junes Security

Tracing an Allowed Flow (6 of 8)

• A quick hiatus to check the contents of policy ID 9

user@srx> show security policies I find "Index: 9"
Policy: Allow-RDP-Server, s tate: enabled, Index: 9, Sequence number: 1
source addresses: 1.1.1.0/24
Destination addresses: 192.168.224.30
Applications: RDP
Acti�n: permit, log

1.1.1100 • 1• # Public IP 1.1.1.30

Private IP 192.168.224.30

-fillP€f;�\,Vo�dwideEducatio11Services ww..,1unipernet i 33

Allowed Flow Tracing Example: Part 6

On the slide, we show the output for the security policy allowing our example traffic by utilizing the
policy index number obtained from the security flow trace.

www.juniper.net Troubleshooting Junos Security • Chapter 9-33

Advanced Junos Security

Tracing an Allowed Flow (7 of 8)

The Junos OS forwards the packet out the ge-0/0/0 interface. ---,
._____________,__J
Feb 4 16:21:02 16:21:00.1872004:CID-0:RT: flow-first-final check: in <fe-
0/0/7.0>, out <ge-0/0/0.0>

Next. we take a look at the reverse traffic flow. The trace shows that traffic arrives from
192.168.224.30 with a source port 3389. and is destined to our translated interface I
address 192.168.224.3 with a destination port 48810.

Feb 4 19:11:40 19:11:40.192283:CID-0:RT:<192.168.224.30/3389-

>192.168.224.3/48810;6> matched filter MatchTrafficReverse:
Feb 4 19:11:40 19:11:40.192283:CID-0:RT:packet [40] ipid = 8174, @42308b9e
Feb 4 19:11:40 19:11:40.192283:CID-0:RT:---- flow_process_pkt: (thd 1):
flow_ctxt type 13, common flag OxO, mbuf Ox42308a00
Feb 4 19:11:40 19:11:40.192283:CID-0:RT: flow process pak fast ifl 67 in_ifp
ge-0/0/0.0
Feb 4 19:11:40 19:11:40.192283:CID-0:RT: ge-0/0/0.0 :192.168.224.30/3389-
>192.168.224.3/48810, tcp, flag 10

<i)2013J•,nipe,N-ooo, lsc. ..ilrlgltls

. i
i°serv<d.'f"-•:..;;?£�
�
�>::Jt:J[lfpef:
��{""�=��--,�� "II< �.

4:,� ._,;t"',.,J�
Worfdwide Education Services
-,,,/'-
www I

Allowed Flow Tracing Example: Part 7

The slide displays the next messages and explanations in a series of flow traceoptions frorn our
example transaction.

Chapter 9-34 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Tr.acing an Allowed Flow (8 of 8)

I The Junos OS performs a hash lookup on the session and finds it in the table.

Feb 4 19:11:40 19:11:40.192283:CI0-0:RT: find flow: table Ox4dd31658, hash

44fl31(0xffff), sa 192.168.224.30, da 192.168.224.3, sp 3389, dp 48810, proto 6,
tok 384
Feb 4 19:11:40 19:11:40.192283:CID-0:RT: flow got session.
Feb 4 19:11:40 19:11:40.192283:CID-0:RT: flow!session id 12535i
Feb 4 19:11:40 19:11:40.192283:CID-0:RT: tcp seq check.

�Junos OS performs NAT translation and buffers the packet to be sent toward its
�:ination.

Aug 14 19:11:40 19:11:40.192283:CID-0:RT: post addr xlation: 1.1.1.30->1.l.1.100.

Aug 14 19:11:40 19:11:40.192283:CI0-0:RT:mbuf Ox42308aOO, exit nh Ox80010
Aug 14 19:11:40 19:11:40.192283:CI0-0:RT: ----- fl_ow_prncess_pkt re OxO (fp re 0)

Allowed Flow Tracing Example: Part 8

The slide displays the final messages and explanations in a series of flow traceoptions from our
example transaction. In this example, we see the packet is buffered for forwarding.

www.juniper.net Troubleshooting Junos Security • Chapter 9-35

Advanced Junos Security

Troubleshooting Stateful Sessions

• Questions to ask:
• Is the packet arriving on the SRX device?
• Is the packet being blocked by a screen?
• Is the packet host-inbound traffic?
• Is the session asymmetric?
• Does the packet belong to an existing session?
• Is the packet arriving on the correct interface and zone?
• Is the correct forwarding path being chosen?
• Is the correct security policy being invoked?

-�fl
• What is the action on the policy?
• Is the correct NAT rule being applied?

f: �orldwideEducatlonServlces wwwJ

Troubleshooting Flow Problems

The slide presents a list of questions you might ask if a session is not developing as expected. Most
of the questions presented can be answered by viewing a configured security flow trace.

Chapter 9-36 • Troubleshooting Junos Security www.juniper.net

Advanced Junes Security

Branch Series Packet Captures

• Branch SRX devices can perform packet capture on
transit traffic [edit fir'ewall filter capture]
user@srx# show
[edit forwarding-options] term one {
user@srx# show from {
packet-capture { source-address {
1.1.1.100/32;
file filename file-name;
maximum-capture-size 1500;
destination-address
1.1.1.30/32;
• Branch and high-end
protocol tcp;
devices can capture destination-port 3389;

traffic local to the device then {

sample;
accept;
• Filter must be applied
to interface term allow-all
then accept;

• •
JU8i'i'Je( "'""' Juniper not
@ rNe!worl<5, !no.All rljhh r.:erued
���- Worldwide
--
Education Services I 37

Transit Packet Captures

All Junos devices can collect captured packets from the control plane using themoni tor traffic
interface I save command.But branch Junes security devices possess the ability to capture
transit traffic for analysis. The slide displays the configuration and steps for capturing transit traffic.
To view the captured traffic, you can offload the files to an external server or use the tcpdump
command in the shell of your Junos device. Note that the interface name is automatically appended
to the name of the file.
user@srx% tcpdump -r -v pcap.fe-0.0.7
21:05:19.974301 In IP (tos OxcO, ttl 64, id 3464, offset 0, flags [none], proto: ESP
(50), length: 120) 192.168.224.1 > 192.168.224.3: ESP(spi=493530462,seq=Ox324)
21:05:24.979969 In IP (tos OxcO, ttl 1, id 31089, offset 0, flags [none], proto: OSPF
(89), length: 72) 192.168.224.6 > ospf-all.mcast.net: OSPFv2, Hello, length 52
Router-ID 192.168.225.1, Backbone Area, Authentication Type: none (0)

Note that the sample action can also be applied directly under an interface to capture all traffic on
a particular interface.

www.juniper.net Troubleshooting Junos Security • Chapter 9-37

Advanced Junos Security

Agenda: TroubleshootingJunos Security

• Troubleshooting Methodology
• Troubleshooting Tools
�Identifying IPsec Issues

Identifying IPsec Issues

The slide highlights the topic we discuss next.

Chapter 9-38 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

IPsec Troubleshooting Overview

• IPsec troubleshooting is common

• Vendor implementations vary
• Both sides must match and often reside in different
administrative domains
• Three primary focuses
• Phase One established?
• Phase Two established?
• Traffic flowing over the tunnel?

Q •

IPsec Troubleshooting
Troubleshooting IPsec virtual private networks (VPNs) is a common scenario. Due to the standard's
loose definitions of implementations, various vendors implement components such as negotiating
proxy IDs in different manners. A lot of values must also match on both peers. This situation can be
daunting when both endpoints reside in different administrative domains without full visibility of the
peer's configuration.

High-Level IPsec VPN Troubleshooting Methodology

To troubleshoot IPsec VPNs, once you have confirmed connectivity to the remote Internet Key
Exchange (IKE) peer, check to see that phase one is established. Next, check whether phase two is
established. Finally, ensure that traffic is able to flow through the VPN tunnel to its destination. This
page is only a high-level overview of IPsec troubleshooting. Over the next several slides, we will look
at some common issues in more detail.
For a detailed flowchart-based troubleshooting process of IPsec VPNs, check out the Juniper
Networks Knowledge Base and the following article:
http://kb.juniper.neV10100

www.juniper.net T roubleshooting Junos Security • Chapter 9-39

Advanced Junos Security

IPsec Troubleshooting Tools (1 of 2)

• Monitoring IPsec phase one negotiation
user@srx> show security ike security-associations detail
IKE peer 172.18.2.2, Index 494,
Role: Initiator, state: UP
Initiator cookie: ebc2bf704ab19695, Responder cookie: 4b5d9eb698ddf19c
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 172.18.1.2:500, Remote: 172.18.2.2:500
Lifetime: Expires in 11661 seconds
Peer ike-id: 172.18.2.2
xauth assigned IP: o.o.o.o
Algorithms:
Authentication shal
Encryption 3des-cbc
Pseudo random function: hmac-shal
Traffic statistics:
Input bytes 2916
Output bytes 4192
Input packets: 11
output packets: 27
Flags: Caller notification sent
IPSec security associations: 6 created, 2 deleted
Phase 2 negotiations in progress: 0

Phase One Negotiation

Once you have confirmed connectivity to the remote peer using Internet Control Message Protocol
(ICMP) ping or some other method, the first step to verifying your IPsec VPN is to check the status of
the phase one negotiation. The output on the slide represents the detailed output of show
security ike security-associations command. In the example, phase one ha�; been
successfully negotiated, which we can tell because the status shows as "up". The output shows the
negotiated settings and statistics of the security association (SA).

Chapter 9-40 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

IP!sec Troubleshooting Tools (2 of 2)

• Monitoring IPsec phase two negotiation

usedisrx> show security ipsec security-associations detail
Virtual-system: root
Local Gateway: 172.18.1.2, Remote Gateway: 172.18.2.2
Local Identity: ipv4 subnet(any:0,[0 .. 7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:O, [0..7]=0.0.0.0/0)
DF-bit: clear
Direct ion: inbound, S PI: d9125a63, AUX- s PI:
, VPN Monitoring: -
Hard lifetime: Exp ires in 119 0 seconds
Lifesize Remaining: Unlimited
!ioft lifetime: Expires in 562 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-shal-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64

Direction: outbound, SPI: f7baf258, AUX-SPI: 0

, VPN Monitoring: -
Hard lifetime: Expires in 1190 seconds
Lifesize Remaining: Unlimited
�ioft lifetime: Exp ires in 5 62 seconds
Mode: tunnel, Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-shal-96, Encryption: 3des-cbc
Anti-replay service: counter-based enabled, Replay window size: 64
lilmo•rki,li!it.Al!rtl!libNz,md, jwr,
-"V'�·· l�dwide Education Services
Ul!Jffl�. 'WW"-"
ww� 1un1pernet 1 41

Phase Two Negotiation

Once you have confirmed the successful phase one negotiation, you check the phase two
negotiation with the show security ipsec security-associations command. The
slides displays the detailed output of this command. In this example, phase two has successfully
negotiated.

www.juniper.net Troubleshooting Junos Security • Chapter 9-41

Advanced Junos Security

Check Your Knowledge

• What is the problem?
user@srx> show security ipsec security-associations
Total active tunnels: 1
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 192.168. 224.1 500 ESP:aes-256/shal d6393645 26/ unlim - 0
>131073 192.168. 224.1 500 ESP:aes-256/shal 153ec235 26/ unlim - 0
<131073 192.168.224.1 500 ESP:aes-256/shal f9a2db9a 3 011/ unlim - 0
>131073 192.168.224.1 500 ESP:aes-256/shal 153ec236 3011/ unlim - 0

Check Your Knowledge

What is wrong with this picture? The output on the slide shows what appears to be two identical
phase two negotiations.
More than likely, this condition occurs when the lifetime of the phase two negotiation is close to
expiration. When you have the establish-tunnels immediately configuration option
applied, the Junos OS will create a new phase two SA before the current SA expires. This behavior
minimizes the impact of your SA expiration.
Additionally, because the security associations utilize UDP port 500, we can also deduct that NAT
traversal is not negotiated between these peers.

Chapter 9-42 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

IP:sec Logging

• IPsec automatically logs to /var/log/kmd

• For more detailed logging, configure traceoptions
[edit secui:ity ipsec]
uset:&si:x# set traceoptions flag?
Possible completions:
all Ti:ace with all flags enabled
next-hop-tunnel-binding Ti:ace next-hop t unnel binding events
pa,:ket-di:ops Ti:ace packet di:ops
pa,:ket-pi:ocessing Ti:ace data packet pi:ocessing events
�:ui:1ty-assoc1at1onsl Ti:ace secui:ity association management events

[edit secui:ity ike]

usei:19si:x# set traceoptions flag ?
Poss .ible completions:
all Ti:ace evei:ything
ce:rtificates Tt:ace cei:tificate events
config Ti:ace configui:ation download pi:ocessing
da·�abase Ti:ace secui:ity associations database events
genei:al Ti:ace genei:al events
hiqh-availability Ti:ace high-availability opei:ations
�il
ne:<t-hop-tunnels
Ti:ace IKE module pt:ocessing
Tt:ace next-hop-tunnels opet:ations

<>.

IPsec VPN Logging

By default, the Junos OS logs IPsec VPN information to /var /log /krnd. However, the default
logging is limited. To troubleshoot issues with your IPsec VPN, you should enable the traceoptions
flags highlighted on the slide. To view the result, use the show log kmd command.

www.juniper.net Troubleshooting Junos Security • Chapter 9-43

Advanced Junos Security

Reading the KMD Log (1 of 5)

• Phase one and two success

Feb 8 10:41:40 Phase-1 [eespondee] done foe local=ipv4(udp:500, [0..3]=1.1.1.2)
eemote=ipv4(udp:500, [0..3]= 2.2.2.2)
Feb 8 10:41:51 Phase-2 [eespondee] done foe
pl_local=ipv4(udp:500, [0.. 3]=1.1.1.2) pl_eemote=ipv4(udp:500, [0 ..3)=2.2.2.2)
p2_local=ipv4_subnet(any:0, [ 0 .. 71 =10 .10 .10.0/ 24)
p2_eemote =ipv4_subnet(any:O, [0.. 7]=192.168.168.0/24)

• Phase one fails due to mismatched proposals

Feb 8 10:31:10 Phase-1 [eespondee] failed with eeeoe(No peoposal chosen) foe
local=unknown(any:O, [0..0]= ) eemote=ipv4(any:O, [0.. 3]=2.2.2.2)
Feb 8 10:31:10 1.1.1.2:500 (Respondee) <-> 2.2.2.2:500 { 011359c9 ddef501d -
2216ed2a bfc50f5f [-1] / OxOOOOOOOO} IP; EeeOe = No peoposal chosen (14)

Phase One and Phase Two Success

This slide and the next several slides illustrate various logs associated with common IPsec VPN
issues. The first example shows the log outputs upon successful phase one and phase two
negotiations.

Phase One Fails; Mismatched Proposals

The second example on the slide shows the log's output when phase one negotiation fails due to
mismatched phase one proposals. The local address is 1.1.1.2 and the remote peer addre,;s is
2.2.2.2. The role is that of a responder. To remedy this situation, you should confirm that the phase
one proposals match on both peers and that a tunnel policy exists.

Chapter 9-44 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Rnading the KMD Log (2 of 5)

• Phase one fails due to peer not recognized
Feb 8 10:39:40 Unable to find pha se-1 policy as remote peer:2.2.2.2 is not
recognized.
Feb 8 10:39:40 KJl1D_PM_Pl_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1
[responder] failed for pl local=ipv4(any:O, [0 ..3] =1.1.1.2)
pl_remote=ipv4 (any: 0, [0 .. 3] =2.2.2.2)
Feb 8 10:39:40 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 18983055 dbeldOaf -
a4dEd829 f9ed3bba [-1] / OxOOOOOOOO} IP; Error = No proposal chosen (14)

• Possible causes:
• Incorrect peer address
• Mismatched peer ID type
• Incorrect peer ID
• Possible resolutions:
• Confirm local device has correct peer address
• Confirm peer has IKE ID type of IP address

Phase One Fails; Peer Not Recognized

The slide shows another phase one negotiation problem. Like the previous example, we see a log
stating that no proposal was chosen. But we must look at the context around this message to
determine whether this issue is the same as the previous example. In this example, we also see the
message stating the peer is not recognized. The cause of this message could be due to an incorrect
peer address, mismatched peer ID types or an incorrect peer ID (depending on whether the IPsec
VPN is dynamic or static). To resolve this problem, make sure the local peer has the correct IP
address and that both peers have matching IKE ID types.

www.juniper.net Troubleshooting Junos Security • Chapter 9-45

Advanced Junos Security

Reading the KMD Log (3 of 5)

• Phase one fails due to invalid payload type

Feb 8 10:36:20 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { e92lleb9 b59d543c -
766a826d bdld5cal (-1] I Ox OOOOOOOO} IP; Invalid next payload type = 17
Feb 8 10:36:20 Phase-1 [res ponder ] failed with error(Invalid payload type) for
local =unknown(any:O, (0..0]=) remote=ipv4(any:O, [0 ..3] = 2.2.2.2)

• Possible causes:
• Usually a mismatched pre-shared key
• Possible resolutions:
• Confirm pre-shared keys match on both sides

Phase One Fails; Invalid Payload Type

The slide shows another example of a phase one negotiation failure. In this example, we see a
message indicating an invalid payload type. This message usually indicates a problem with IKE
packet decryption due to mismatched pre-shared keys. To remedy this situation, ensure thfl
pre-shared keys on both peers match.

Chapter 9-46 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

RE!ading the KMD Log (4 of 5)

• Phase two fails due to no proposal chosen

Feb 8 10:53:34 Phase-1 [cespondec] done foe local=ipv4(udp:500, [0.. 3]=1.1.1.2)
cemote=ipv4(udp:500, [0..3]=2.2.2.2)
Feb 8 10:53:34 1.1.1.2:500 (Respondec) <-> 2.2.2.2:500 { cd9dff36 4888d398 -
6b0d3933 f0bc8e26 [OJ / Ox1747248b} QM; EccOc = No pcoposal chosen (14)

• Possible causes:
• Usually a phase two proposal mismatch
• Possible resolutions:
• Confirm phase two proposals match on both peers

G• r Network,, lno:AII rll!h!• ,.,;;;.d, -. ·2· , JU[:) i,r�Worltiwide Educatio 11 Services """ )Un ,per net I 47

Phase Two Fails; No Proposal Chosen

In this example, we see that phase one has successfully negotiated. However, phase two negotiation
is failing due to no chosen proposal. This issue typically arises when a phase two proposal mismatch
occurs between the peers. Confirm the phase two proposals match on both peers.

www.juniper.net Troubleshooting Junos Security • Chapter 9-4 7

Advanced Junos Security

Reading the KMD Log (5 of 5)

• Phase two fails due to no proposal chosen
Feb 8 10:56:00 Phase-1 [r:esponder:] done for: local=ipv4(udp:500, [0..3]=1..1.1.2)
r:emote=ipv4(udp:500, [0..3]= 2.2.2.2)
Feb 8 10:56:00 Failed to match the peer: pr:oxy ids
p2_r:emote=ipv4_subnet(any:O, [0.. 7]=192.168.168.0/24)
p2_local=ipv4_subnet(any:O, [0..7]=10.10.20.0/24) for: the r:emote
peer::ipv4(udp:500, [O..3] =2. 2. 2.2)
Feb 8 10: 56:00 KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for: Phase--2
[r:esponder:J failed for: pl_local=ipv4(udp:500, [0..3] = 1.1.1.2)
pl_r:emote=ipv4(udp:500, [0.. 3]=2.2.2.2)
p2_local=ipv4_subnet(any:O, [0.• 7]=10.10.20.0/24)
p2_r:emote=ipv4_subnet(any:O, [0.. 7] =192.168.168.0/24)
Feb 8 10:56:00 1.1.1.2:500 (Responder:) <-> 2.2.2.2:500 { 41f638eb cc22b!Jfe -
43fd0e85 b4f619d5 [OJ I Oxc77fafcf } QM; Er:r:or: = No pr:oposal chosen (14)

• Possible causes:
• Proxy ID mismatch
• Possible resolutions:
• Confirm proxy IDs match for the peers

Phase Two Fails; No Proposal Chosen (Again)

Like the previous example, we again see that phase two has failed due to no proposal cho�;en.
However, again we have to examine the context of this log message. In this case, we also s,�e the
failure to match peer proxy IDs. We can see we received a proxy ID of remote = 192.168.168.0/24
paired with local=!0.10.20.0/24 and using a service type of any_ To resolve this issue, configure the
reverse matching proxy ID locally.
Note that by default, route-based IPsec VPNs use a proxy ID of all zeroes. If the remote peer is
specifying any other proxy ID than all zeroes, you must manually configure the appropriate proxy ID
locally.

Chapter 9-48 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

Summary
• In this content, we:
·• Presented a troubleshooting methodology
·• Configured logs, traces and packet captures
·• Analyzed traffic flows
·• Identified common IPsec issues

We Discussed:
A methodology for troubleshooting;
The configuration of logs, traces, and packet captures;
Traffic flow analysis; and
Common IPsec VPN issues.

www.juniper.net Troubleshooting Junos Security • Chapter 9-49

Advanced Junos Security

Review Questions

1. How do you debug traffic flows on a Junos security

device?
2. To what log are IPsec messages logged by default?
3. How do you narrow down the output when
configuring flow tracing?
4. How does data plane logging differ between
high-end and branch SRX devices?

W�_rldwideEducationServlces
-��- +,J
Review Questions
1.

2.

3.

4.

Chapter 9-50 • Troubleshooting Junos Security www.juniper.net

Advanced Junos Security

PEtrforming Security Troubleshooting

Te!chniques Lab

• Examine system logs specific to Junos security.

• Perform analysis of flow tracing.
• Troubleshoot an IPsec VPN.

•rNelworks, lneAllrlgb!, ,.,.,,,... JL!fTllper� frtd��e Education Services .,.,,. 1unlpernet I s1

Performing Security Troubleshooting Techniques Lab

The slide provides the objectives for this lab.

www.juniper.net Troubleshooting Junos Security • Chapter 9-51

Advanced Junos Security
Answers to Review Questions
1.
To debug flows in the Junos OS, configure a traceoptions file under the [edit security flow]
hierarchy that flags the basic-datapath option.
2.
By default, IPsec VPN log messages are logged to /var/log /kmd.
3.
To narrow down the output of security flow traceoptions, use the packet-filter option, specifying the
source and destination of the traffic flows you would like to view.
4.
By default, branch SRX devices log data plane events locally. You can, however, direct branch device data
plane logs to an external device by configuring a stream under the [edit security log J
configuration hierarchy. By default, high-end SR,'{ devices do not log data plane events locally or remotely.
You must configure a stream under the [edit security log] configuration hierarchy to send data
plane events to an external device. Additionally, you can log a high-end device's data plane events locally by
configuring the event mode option. We recommend no more than 1000 messages per second be logged
using this method.

Chapter 9-52 • Troubleshooting Junos Security www.juniper.net

JUnt�v�[
Advanced Junos Security

Appendix A: SRX Series Hardware and Interfaces

Advanced Ju nos Security

Objectives
• After successfully completing this content, you will be
able to:
• Describe the different SRX platforms
• Explain SRX hardware components and traffic flows
• Implement various SRX interface types

We Will Discuss:
The different SRX platforms;
SRX hardware components and traffic flows; and
SRX interface types.

Appendix A-2 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

A!tenda: SRX Series Hardware and

ln·terfaces
� Branch SRX Platform Overview
• High-End SRX Platform Overview
• SRX Traffic Flow and Distribution
• SRX Interfaces

�"" "W.

"'Ne!,,orks,lne.Allrl�:rost>Wd. JUnm]:WorldwideEducationServices
,:
ww•o,,n,pe,nel I 3
� " o.s®1t0e "" -

Branch SRX Platform Overview

The slide lists the topics we will discuss. We discuss the highlighted topic first

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-3

Advanced Junos Security

Current Trends
• The current trends:
• As boundaries of networks become virtual, so do the
requirements of network edge devices
• The functions of a router and a firewall are collapsing
• The network edge requires more protection
• The hardware is now more capable

���'tf.1';;4;']/l(Jn1per WorldwideEducationServices WWWJ

fL"-�- -

Current Trends
As boundaries of networks are becoming less clear, so are the requirements of network edge
devices. More and more enterprises are interconnecting themselves through an ISP's virtual cloud
by using IP. The Internet has created possibilities and opportunities for businesses and marl<ets, and
it has erased the concept of distance. With the Internet, however, came network vulnerabilities.
Traditionally, routers have been positioned on the edge of an enterprise network and provided very
basic network security such as stateless firewall filters. Network administrators became us,"d to
relying on separate firewall devices positioned within enterprise DMZs. The consolidation o·f these
functions at the network edge improves costs, reduces management overhead, and increases
operational simplicity.

Appendix A-4 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junes Security

A l\jew Perspective

• SRX Series Services Gateways

• Integrated security and network features
with robust Dynamic Services Architecture

Branch Office

·�
CTSRX210

-=- Home Office or Retail Site

G

A New Perspective
The graphic on the slide illustrates how a device with strong routing and firewall features can be
positioned at network boundaries. Remote offices can deploy SRX Series branch platforms running
the Junos OS to provide both routing and security features.
The SRX Series Services Gateway at the enterprise headquarters in this example also provides
routing and security in a high-density, modular chassis. The Dynamic Services Architecture allows
SRX Series Services Gateways to leverage new services with appropriate processing capabilities
without sacrificing overall system performance. SRX Series Services Gateways are next-generation
systems designed to meet the network and security requirements for the enterprise and service
provider infrastructure, and facilitate data center consolidation, rapid managed services
deployments, and security services aggregation.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-5

Advanced Junos Security

Branch SRX Platform Overview

• Designed for the branch office
Large Branch or
Small Office Medium Office
Regional Office

SRX100 SRX240
SRX650
�It::.•
--:_; �
SRX210

SRX220

Branch SRX Platform Overview

Branch SRX devices are designed to satisfy the needs of small, medium and large branch office
networks. The branch SRX platform provide a firewall throughput ranging from 650 Mbps to 7 Gbps,
IP Security (IPsec), virtual private network (VPN), and firewall services for small-sized and
medium-sized companies and enterprise branch and remote offices.
Whereas all SRX models contain the routing and security features of the Junos operating system,
some hardware features vary between platform models. Some models contain modular slots to
support additional media interfaces called Physical Interface Modules (PlMs). PIMs are covered in
more detail later in the chapter. Some SRX models also support Power over Ethernet (PoE). PoE ports
allow you to plug in devices that require both network connectivity and electric power, such as voice
over IP (VoIP) and IP phones and wireless access points. Base memory and high memory versions
are available for the SRX100, SRX210, SRX220, and SRX240. High memory versions are re,quired to
use Unified Threat Management (UTM) and Intrusion Prevention System (IPS) features.
The SRX100 contains eight onboard 10/lOOBASE-T Ethernet ports, and supports up to 650 Mbps
firewall throughput. It is ideal for small sites and managed telecommuters.
The SRX210 offers complete functionality and flexibility for delivering secure, reliable data and voice
services over IP, along with multiple interfaces that support WAN and LAN connectivity. It i�; ideal for
small branch offices.
Continued on the next page.

Appendix A-6 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Branch SRX Platform Overview (contd.)

The SRX210 supports up to 750 Mbps firewall throughput, and contains six onboard
10/lOOBASE-T Ethernet ports, two 10/100/lOOOBASE-T Ethernet ports, and one Mini-Physical
Interface Module (Mini-PIM) slot. The SRX210 also contains an ExpressCard slot for use with a 3G
wireless card to serve as a backup for primary interfaces.
The SRX220 offers complete functionality and flexibility for delivering secure, reliable data over IP,
along with multiple interfaces that support WAN and LAN connectivity and PoE. The SRX220
supports up to 950 Mbps firewall throughput, and contains eight 10/100/lOOOBASE-T Ethernet
ports, and two Mini-PIM slots, allowing for WAN interface redundancy between WAN PIM interfaces.
The SRX240 is designed for a medium-sized branch office network. It contains multiple interfaces
that support WAN and LAN connectivity. The SRX240 supports up to 1.5 Gbps firewall throughput,
and contains 16 10/100/lOOOBAS E T- Ethernet ports and four Mini-PIM slots.
The SRX650 is the top model of the branch SRX platform. It consolidates network infrastructure and
security applications for regional offices, large branch offices, and small to medium enterprises. The
SRX650 provides cost-effective, scalable integration of routing, security, and other mid-range
applications for these sites. The SRX650 supports up to 7 Gbps firewall throughput, and contains
four on board Gigabit Ethernet ports, and eight Gigabit-Backplane Physical Interface Module (GPIM)
slots.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A- 7

Advanced Junos Security

SRX Series Branch Platform Components

• Components:
• Multicore "System-on-a-chip" network processing unit
• PIM: Physical Interface Module
• SRE: Services and Routing Engine
• SRX650 only

SRX Branch Series

SRX Series Branch Platform Components

Juniper Networks SRX Series Services Gateways for the branch provide essential capabilities that
connect, secure, and manage workforce locations sized from handfuls to hundreds of users. By
consolidating fast, highly available switching, routing, security, and applications capabilitie�; in a
single device, enterprises can economically deliver new services, safe connectivity, and a satisfying
end user experience.
SRX Series for the branch operates with the Junes OS, the proven operating system used by core
Internet routers in all of the top 100 service providers around the world. The rigorously test,:?d
carrier-class routing features of IP version 4 (1Pv4)/IP version 6 (1Pv6), OSPF, BGP, and multicast
have been proven in over 10 years of worldwide deployments.
SRX Series Services Gateways for the branch provide perimeter security, content security, access
control, and network-wide threat visibility and control. Best-in-class firewall and VPN technologies
secure the perimeter with minimal configuration and consistent performance. By using zones and
policies, even new network administrators can configure and deploy an SRX Series branch device
quickly and securely. Policy-based VPNs support more complex security architectures that require
dynamic addressing and split tunneling. For content security, SRX Series for the branch offers a
complete suite of Unified Threat Management (UTM) services consisting of intrusion prevention
system (!PS), antivirus, antispam, Web filtering, and data loss prevention through content filtering to
protect your network from the latest content-borne threats.
Continued on the next page.

Appendix A-8 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junes Security

SRX Series Branch Platform Components (contd.)

Select models feature Content Security Accelerator for high-performance IPS and antivirus
performance. Junos security platforms for the branch integrate with other Juniper Networks security
products to deliver enterprise-wide unified access control and adaptive threat management. These
capabilities give security professionals powerful tools in the fight against cybercrime and data loss.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-9

Advanced Junos Security

Branch SRX Hardware Architecture

REG EX
Content .t. USB
Processor Multiple Core USB Hub
1 Ports
Processor
Serial
Console

Ethernet Switch

On board Mini-PIM
Interfaces Slots

"% *1!WP\c� "'°'*�-=,"'

Yl!'.Jf:111::lAt::
I

• �: _ Worldwtde Education Services

0

4}1lotal•n!Ptfl,l•wili>;moci\11 llg1!1, ..,.,,..d.

. �} �� "
_,, i

Branch SRX Hardware Architecture

The SRX100, SRX210, SRX220 and SRX240 each contain a multicore system-on-a-chip processor.
The processor provides all the functionality of Junes services, using multiple hardware threads to
perform the required control and data plane services. The serial console, USS hub and regular
expression (REGEX) content processor are connected to the multicore processor. The serial console
is used for management access to the device. The USS hub connects to the external USS ports, and
allows for attached storage. The REGEX content processor performs the functions of the content
security accelerator, used for high-performance !PS and increased express antivirus performance.
The content processor is available on the high memory versions of the SRX210, SRX220, aind
SRX240, as well as the SRX650. The onboard interfaces and PIM slots are connected to the
processor through an Ethernet switch.

Appendix A-10 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SJfXGSO Hardware
• SRX650 hardware provides additional features
• Hardware-based separation of control and data planes
• Power redundancy

Multi-use
processing slot
(future use)

Power Supply Slot O

SRX650 Rear View

SRX650 Hardware
The SRX650 provides some additional features than the other branch SRX platforms. It contains
hardware separation of the control and data plane, whereas all other branch platforms use the
system-on-a-chip architecture. The SRX650 also provides Symmetric Multiprocessing-based data
forwarding.
The SRX650 provides power supply redundancy. It supports dual AC and DC power supplies with a
redundant configuration in the chassis. The AC and DC power supplies are hot-swappable. The two
power supply slots are located on the left side on the rear of the chassis. Slot O is on the bottom, and
slot 1 is on the top.
The Services and Routing Engine (SRE) module provides processing power for security services,
routing protocol processes, and other software processes that control the services gateway
interfaces, some of the chassis components, system management, and user access to the device.
The SRE slot is located on the rear of the chassis. The bottom slot is for SREO, and the top slot is
called a multi-use processing slot, which is not yet supported as of Junos OS revision 10.4R1.9.
For more information on specific Junos security platform branch models and hardware, visit the
Juniper Networks Web site for technical publications at http://www.juniper.neVtechpubs.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-11

Advanced Ju nos Security

Agenda: SRX Series Hardware and

Interfaces

• Branch SRX Platfonn Overview

7 High-End SRX Platform Overview
• SRX Traffic Flow and Distribution
• SRX Interfaces

High-End SRX Platform Overview

The slide highlights the topic we will discuss next.

Appendix A-12 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Hiigh-End SRX Platform Overview

• Designed for the data center

SRX1400
till
SRX3400 SRX3600

SRX5600 SRX5800

-,-
JIJlilmi Wo�ideEducationServices "'""'Jun,pernet 1 13

High-End SRX Overview

The high-end SRX platform uses the Juniper dynamic services architecture to distribute data
sessions between multi-core processing resources dynamically. The dynamic services architecture
balances traffic session processing workload dynamically within a pool formed from all available
resources. The architecture enables the SRX device to deliver massive scalability, market-leading
throughput, and deterministic performance with multiple security services operating concurrently.
The high-end SRX platforms have a modular chassis design, allowing for additional processing cards
to be easily installed, adding to the resource pool, to accommodate your network's traffic growth over
time. The high-end SRX device natively integrates firewall, IPS, IPsec, denial of service (DoS) blocking
services, NAT, and quality of service (QoS), and also enables carrier-class reliability and availability.
The SRX1400 is the newest member of the market-leading SRX high-end line, and is designed for
10GB Ethernet network environments. It consolidates multiple security services and networking
functions. It features a modular design that uses common form-factor modules serviceable from the
front panel. The SRX1400 supports up to 10 Gbps firewall throughput, and is available in a choice of
built-in high-density 1 Gigabit Ethernet ports or a combination of built-in 10 Gigabit Ethernet and 1
Gigabit Ethernet ports. The appliance includes one expansion slot on the front panel, and two power
supply slots, allowing for redundancy.
Continued on the next page.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-13

Advanced Junos Security
High-End SRX Overview (contd.)
The SRX3000 platform line includes the SRX3400 and the SRX3600, and can achieve 30 Gbps
firewall throughput and covers a wide range of price/performance points by separating input/output
and network processing into separate cards. It optimizes rack space utilization by accepting
processing cards in front and rear slots. It supports high session counts and setup rates
(2.25 million simultaneous sessions and 175,000 connections per second).
The SRX5000 platform line includes the SRX5600 and the SRX5800, and can achieve 120 Gbps
firewall throughput and 30 Gbps IPS throughout, making it the highest performing security solution
in the industry. It supports high session counts and setup rates (10 million simultaneous s,essions
and 350,000 connections per second), essential for securing modern applications.

Appendix A-14 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SJtX Series High-End Platform Components

• Components:
• IOC: lnputjoutput card
• NPC: Network Processing Card
• SPC: Services Processing Card
• SCB: Switch Control Board
• RE: Routing Engine

SRX Series High-End Platform Components

The SRX Series line of high-end systems includes the following integral components:
lnputjoutput card (IOC): To provide the most flexible solution, the SRX Series employs
the same modular architecture for SPCs and IOCs. With the flexibility to install an IOC or
an SPC on a given slot, the SRX Series can be equipped to support an ideal balance
between interfaces and processing capabilities.
Network Processing Card (NPC): To ensure maximum processing performance and
flexibility, the SRX3000 line utilizes NPCs to distribute inbound and outbound traffic to
the appropriate SPCs and IOCs, to apply QoS, and to enforce DoS and distributed DoS
(DDoS) protections. In the SRX5000 line, the NPC is integrated into the IOC. Note that a
minimum of one NPC must be installed in platforms in the SRX3000 line to ensure
proper functionality.
Services Processing Card (SPC): SPCs are designed to process all available services on
the gateway. Without the need for dedicated hardware for specific services or
capabilities, no instances exist in which a piece of hardware is taxed to the limit while
other hardware is sitting idle. All the processing capabilities of the SPCs are designed to
process all configured services on the gateway. Note that a minimum of one SPC must
be installed in an SRX Series high-end system to ensure proper functionality.
Continued on the next page.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-15

Advanced Junos Security

SRX Series High-End Platform Components (contd.)

The following is a continuation of the list of integral components from the preceding page:
Switch Control Board (SCB): The SCB monitors and controls system functions and
provides the interconnections to all the IOCs within a chassis through the switch fabrics
integrated into the SCB. At least one SCB is required for the system to function. Two or
three SCBs increase capacity or provide redundancy, depending on the specific
platform.
Routing Engine (RE): The RE is an Intel-based PC platform that runs the Junos OS.
Software processes that run on the RE maintain the routing tables, manage the routing
protocols, control some chassis components, and provide the interface for system
management and user access to the device.
For more information on specific SRX Series high-end system models and hardware, visit the Juniper
Networks Web site for technical publications at
http:j
/www.juniper.net/techpubs.

Appendix A-16 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junes Security

SJtX1400 Operation Modes

• Two modes of operation

• NSPC card for the SRX1400
-- -�

• NPC + SPC from SRX3000

SRX1400 Operation Modes

The SRX1400 provides common-form-factor module (CFM) slots that can be populated with a
double-wide Network and Services Processing Card (NSPC), occupying two adjacent CFM slots. Providing
the power inside the SRX1400, the NSPC is optimized to perform all packet processing and inspection
for all available services on the platform. The dynamic services architecture manages the multiple cores
of processing power on the NSPC as one pool of resources, and dynamically allocates resources to
services as needed. The SRX1400 can use the SRX3000 Network Processing Card (NPC) and SRX3000
Services Processing Card (SPC) hardware instead of using the NSPC module, to perform the same
functions as the NSPC. The performance is the same on the SRX1400, regardless of which hardware is
used. Using the SRX3000 NPC and SRX3000 SPC in the SRX1400 requires a double-wide tray.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-17

Advanced Junos Security

SRX3000 Hardware Components

• IOCs, NPCs, and SPCs

Data Plane

,__,CFa
:.§
&'.
·o.o
c
FPGA FPGA NPU FPGA FPGA .-----
.s::::. ..______, SPIJ
.B
-�

IOC NPC SPC

Routing
Engjne

SRX3000 Hardware Components

The SRX3000 platform resets the bar in performance for enterprise and service provider
environments. Based on an innovative mid-plane design and Juniper's dynamic services
architecture, each SRX3000 can be equipped with a flexible number of input/output cards (IOCs),
NPCs, and SPCs-allowing the system to be configured to support the ideal balance of performance
and port density. The flexibility and performance of the SRX3000 line is designed to match the
specific business needs of services processing, routing and firewall performance.
The switching fabric enables the scalability of IOCs, NPCs, and SPCs. Supporting up to 320 Gbps of
data transfer, the fabric enables the realization of maximum processing and input/output capability
available in any particular configuration. This level of scalability and flexibility facilitates future
expansion and growth of the network infrastructure.
The IOC contains the onboard physical interface ports for the SRX device. Traffic coming in or going
out of the physical ports is processed by the NPC. The NPC contains the Network Processing Unit
(NPU), which connects traffic from the IOC to a given SPC. The NPU is responsible for session lookup,
QoS, Screens, and can enforce DoS and distributed denial of service (DDoS) protections. A minimum
of one NPC must be installed in an SRX3000 platform to ensure proper functionality.
Continued on the next page.

Appendix A-18 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SRX3000 Hardware Components (contd.)

The SPCs are designed to support a wide range of services enabling future support of new
capabilities without the need for service-specific hardware. Using SPCs on all services ensures that
there are no idle resources based on specific services being used-maximizing hardware utilization.
The SPC contains the Services Processing Units (SPUs), the main processors of the SRX3400 and
SRX3600. They establish and manage traffic flows and perform most of the packet processing as a
packet transits the device. Each SPU maintains a hash table for fast session lookup. The SPU
performs all flow-based processing for a packet, including application of security services,
classifiers, and traffic shapers. The Central Point (CP) is used to allocate session management to
SPUs based on load-balancing criteria. It distributes sessions in an intelligent way to avoid
occurrences in which multiple SPUs might wrongly handle the same flow. If the session exists, the
central point forwards packets for that flow to the SPU hosting the session. It also redirects packets
to the correct SPU in the event that the NPU fails to do so.
The Routing Engine runs the control plane and manages the Control Plane Processor (CPP).

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-19

Advanced Junos Security

SRXSOOO Hardware Components

• IOCs, SPCs, and SCBs

NP
..a
.Q
(1)
c
�
a.. &'.
'o.O
c
ro ..c
0
NP .B
"3!

IOC SPC
(1)
c
ro Switching Fabric Switching Fabric
a.. Second Routing
0
Routing Routing Engine for chassis
c cluster control link
+,J

0 Englne Englne redundancy only

(_)

SRX5000 Hardware Components

The SRX5000 platform provides unrivaled scalability and performance, and is also based on Juniper
Network"s dynamic services architecture. Each SRX5000 can support near linear scalability, with the
addition of SPCs, enabling a fully equipped SRX5800 to support more than 120 Gbps firewall
throughput.
Each SRX5000 can be equipped with a flexible number of IOCs. With the IOCs sharing the same
interface slot as the SPCs, the gateway can be configured as needed to support the ideal balance of
processing and input/output. With this flexibility, the SRX5800 can be configured to support more
than 400 Gigabit Ethernet ports or 44 10-Gigabit Ethernet ports.
The SRX5000 supports standard IOCs and Flex IOCs. The standard IOCs are optimized for Ethernet
density and are capable of supporting up to 40 Gigabit Ethernet or four 10-Gigabit Ethernet ports.
The IOC assembly combines packet forwarding and Ethernet interfaces on a single board, with four
10-Gbps Packet Forwarding Engines. Each Packet Forwarding Engine consists of one I-chip for
Layer 3 processing and one Layer 2 Network Processor (NP). The IOCs interface with the power
supplies and Switch Control Boards (SCBs). Flex IOCs are IOCs with two slots, which accept port
modules that add Ethernet ports to your services gateway. A Flex IOC with installed port modules
functions in the same way as a regular IOC, but allows greater flexibility in adding different types of
Ethernet ports to your services gateway. Flex IOCs have two NPUs and thus support 20 Gbps
throughput to the backplane as opposed to standard IOCs, which have four NPUs and support a
40 Gbps backplane connection. However, Flex IOCs have a greater wing capacity as opposed to
standard IOCs (4 million versus 2 million).
Continued on the next page.

Appendix A-20 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SRX5000 Hardware Components (contd.)

The NP is integrated into the IOC cards on the SRX5000 platform, and performs the same task of
session lookup, and mapping traffic from the IOC to an SPC.
The SCB transforms the chassis from a simple module enclosure into a highly effective mesh
network. The purpose of the SCB is to allow all modules in the chassis to send traffic at extremely
high bandwidth. The Routing Engine is tightly coupled with the functionality of the SCB and is the
control plane of the chassis The Routing Engine provides overall management and communications
to and from system administrators, as well as calculating route tables for routing network traffic.
Note that the SRX5800 supports three SCBs for a 2+1 redundancy scenario. You may install two
Routing Engines in an SRX5800 but the second Routing Engine is only used to provide a second
control plane link for chassis clustering. The second Routing Engine does not provide any other
control plane redundancy as of Junos OS 10.4R1.9.

The SPC processes network packets.The chassis must have at least one SPC to operate.
Performance is greatly increased when more than one SPC is installed. The addition of a new SPC
essentially results in a larger system that can perform many more tasks at a given time.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-21

Advanced Junos Security

Agenda: SRX Series Hardware and

Interfaces

• Branch SRX Platforn1 Overview

• High-End SRX Platform Overview
�SRX Traffic Flow and Distribution
• SRX Interfaces

-·--
. �Ufi1�:. ".'Vorldwide Education Services "'w"' J

SRX Traffic Flow and Distribution

The slide highlights the topic we will discuss next.

Appendix A-22 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Branch SRX Traffic Flow

Ingress
pac;ket

�
Egress
packet

Varies by platform

Branch SRX Traffic Flow

In branch SRX devices, control and data plane separation is maintained using multiple threads on
multiple cores within the processor. One hardware core is used for control plane functions. Packets
ingress the device through built-in ports or PIM ports and pass to an Ethernet switch, which acts as
the switch fabric for the device. In branch SRX devices, local switching occurs at the switch so that
the CPU or the NPU is not taxed with switched traffic. As a result, security services such as security
policy and IDP are not available with locally switched traffic. The switch performs class-of-service
(CoS) classification and traffic policing. It then passes non-locally switched packets to the processor
where security services, routing lookup, and forwarding lookup is performed. SRX branch devices
then send egress packets to the appropriate egress port by means of the switch.
Depending on the device type, the CPU might perform hardware acceleration and cryptographic
acceleration. Some branch devices are equipped with a separate regular expression (REG EX)
content processor to provide hardware-based pattern matching for Intrusion Detection and
Prevention (IDP) and antivirus acceleration.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-23

Advanced Junos Security

Physical Packet Flow (High-End Platform!.)

@Flow lookup. policing. Routing and \
and Cos device [ MGT I
management
@Services FW. VPN.
f5 Oversubscription

...
IDP. NAT. and routing
Network ;
j control Processing 1
Olngyess :: �� ::
packet : :
: :
:: ____,.......
----llo.... ____,.......
----llo.... : __,........
----llo....

I ... ... 1 ...

:: :::

0E�ess
packet
.:. :.
: Services
Input/output ..............•.....................................
Integrated in SRX5000 IOC :
•
Proce:,.sing
cards 0CoS and shaping Cards

Physical Packet Flow for High-End Security Platforms

The slide illustrates physical packet flow through a high-end security platform running the Junos OS.
The packet flow coverage includes the SRX5000 and the SRX3000 line of products.
Physical packet flow through a high-end security platform proceeds through the following sequence
of steps:
1. A packet enters the security platform through the IOC.
(Step 1.5: Oversubscription control applies at the IOC.)
2. The packet traverses the switch fabric from the IOC to the NPC. (In the SRX5000 line of
products, the NPC integrates with the IOC.) The NPC performs a flow lookup. If the
packet belongs to an existing flow, the NPC forwards the packet to the SPC as,,ociated
with the packet's session. If the flow does not currently exist, the NPC installs a new
session for the flow and assigns the flow to an SPC for processing. The NPC also
performs CoS, policing, and shaping.
3. The packet traverses the switch fabric to its associated SPC, where security processing
and forwarding or routing occurs.
4. The packet traverses the switch fabric back to an NPC where additional packet
processing such as shaping and CoS occurs.
5. The packet traverses the switch fabric to the IOC associated with the egress interface
and travels to the attached physical medium.

Appendix A-24 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SltX1400 Traffic Flow

• Oversubscription

-·
, Input/output
cards @Flow lookup. policing. @Services FW. VPN.
Olngress and Cos IDP. NAT. and routing

·-
packet ............................................................................................

Network Services
Processing Processing

0Egress
packet
-
System and
lnput;output cards
nte ated in.NSCP ;
-.....����-���-����'.��---·················I gr _

". r N'"-"OM, ln,:;AII rl$11'r.seowd, •• 1 JUrti

-.,vriJ ·;:'worldwide Education Services
== =},-==
""� ,unlper net I �5

SRX1400 Traffic Flow

The SRX1400 receives an incoming packet from either the various physical interfaces on the IOC or
System lnpuVOutput Card (SYSIOC). After the incoming packet passes through the SYSIOC, the NSPC
receives and processes the packet. The session setup is performed, and session information is
cached for subsequent packets. The packet is then forwarded back out through the outgoing port on
the egress interface.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-25

Advanced Junos Security

SRX3000 First Packet Processing Flow

1. Packet Received by NP. 2. NP sends packet to 3. CP choosesSPU. forwards pac:ketSPU
NP performs flow lookup. CP does session setup
no match is found 4.SPC forwards packet to egresi, NPU.
which forwards packet out egress port
_____
@___

SPC#1

IOC#2 NPC#2 SPC#2

SRX3000 First Packet Processing Flow

The distributed parallel processing architecture of the SRX3400 and SRX3600 includes multiple
processors to manage sessions and run security and other services processing. This architecture
provides flexibility and allows for high throughput and fast performance.
The slide shows the flow of the first packet of a session through an SRX3000 platform. A packet
arrives on the ingress interface and the IOC processes it. The NPU receives the packet from the IOC,
and performs basic sanity checks on the packet and applies some screens configured for the
interface to the packet. A session lookup is performed by the NPU. No matching session is found,
and the packet is forwarded to the CP for session creation.
The central point, located on the SPU, maintains a global session table that includes entries for all
sessions that exist across all SPUs on the device. It participates in session creation and delegates
and arbitrates session resource allocation. The CP checks its session table and determines that a
session does not exist. The CP creates a pending wing for the session and selects an SPU to be used
for the session, based on its load-balancing algorithm. A wing is a unidirectional flow of a s,:'!ssion.
Two wing flows make up one bidirectional session. The central point forwards the first packet of the
session to the selected SPU in a message telling it to set up a session locally.
For SRX3400 and SRX3600 devices, one SPU acts in concert performing its regular session
management and flow processing functions and acting as a central point in which it arbitrates
sessions and allocates resources. When an SPU performs in this manner it is said to be in combo
mode.
Continued on the next page.

Appendix A-26 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SRX3000 First Packet Processing Flow (contd.)

In combo-mode, the SPU and the central point share the same load-balancing thread (LBT) and
packet-ordering thread (POT) infrastructure.
The last step in first packet processing is that the SPU forwards the packet out to the egress NPU,
which then forwards the packet out the egress interface.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-27

Advanced Junos Security

SRX3000 Session Setup Messages

1. SPU sends insert session to CP
2. SPU sends insert session to ingress NP
3. SPU sends insert session to egress NP

8
CPa
FPGA FPGA NPU
c: SPU

IOC#1 0
(.)
SPC#1

.Q

FPGA FPGA NPU SP]

@)
IOC#2 NPC#2 SPC#2

��fJUOIPff Worlm,;ideEducatlonServlces wwwj

�--�'s.:e.:=!=-�

SRX3000 Session Setup Messages

The slides demonstrates the messages used for the SPU to set up a new session. Each SPIJ has a
session table, which contains information about its sessions. When the SPU receives a mei,sage
from the central point to set up a session, it checks its session table to ensure that a session does
not already exist for the packet. If no session exists for the packet, the SPU sets up the session
locally.
The first setup message the SPU sends is to the central point, telling it to install the session. The SPU
adds to the queue any additional packets for the flow that it might receive until the session has been
installed. The SPU maintains a session table with entries for all sessions that it establishecl and
whose packets it processes. When an SPU receives a packet from an NPU, it checks its session table
to ensure that the packet belongs to it.
The SPU then sets up the session on the ingress and egress NPUs. NPUs maintain information about
a session for packet forwarding and delivery. Session information is set up on the egress and ingress
NPUs (which sometimes are the same) so that packets can be sent directly to the SPU that manages
their flows and not to the central point for redirection.

Appendix A-28 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SFtX3000 Fast Path Processing Flow

1. Packet Received by NP. NP performs flow lookup. match is found
2. NP send packet to SPU. SPU performs fast path processing
3. Packet forwarded to egress NP
4. Packet egresses IOC physical port

@
CP

c
NPU
SPU

IOC#1
(,)
0 NPC#1 SPC#1

SPU

IOC#2 NPC#2 SPC#2

".

SRX3000 Fast Path Processing Flow

The slide shows fast path processing after a session has been established. The ingress NP receives
the packet, processes it, and finds a matching session. In the example, the Ju nos OS finds a
matching session on the assigned SPU. The NPU forwards the packet to the SPU for processing along
with the session ID. The SPU then performs fast path processing. The SPU forwards the packet to the
egress NP listed in the session table, and the packet is forwarded out the egress interface.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-29

Advanced Junos Security

SRXSOOO Traffic Flow

Ingress
Packet CP

NP
8-8
IOC SPC

8-8
Egress SPU
Packet

IOC SPC

SRX5000 Traffic Flow

The traffic flow through the SRX5000 is quite similar to the SRX3000 traffic flow. The diagram
arrows on the slide demonstrate the first packet processing through the SRX5000 compon,�nts. The
ingress NP receives the ingress packet, and performs a session lookup, to determine if a session
already exists. The NP determines that no session exists for the packet, and the NPU sends the
packet to the CP. The CP selects the SPU to set up the session for the packet, and it sends the packet
to that SPU. The SPU processes the packet and sends it to the egress NPU for transmission out the
egress interface.
Next, the session setup messages are performed. The SPU sends an insert session messa1�e to the
CP. The SPU sends an insert session message to the ingress NP. Then the SPU sends an insert
session message to the egress NP.
When a subsequent session packet enters the SRX device, fast path processing flow is then
performed. The ingress NP receives the packet, and performs a session lookup. A session match is
found. The NP sends the packet to the SPU, and the SPU performs fast path processing. The packet
is then forwarded to the egress NP, and the packet egresses the SRX device.

Appendix A-30 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Nl:t Bundling {SRXSOOO)

• By default, NPs limit the number of sessions per

interface
• A Standard IOC supports 1 million sessions (2 million wings)
per NP
• A Flex IOC supports 2 million sessions (4 million wings) per
NP
• Bundled NPs scale up the number of sessions, wings
and pps throughput supported per interface
• Packet processing is distributed across multiple NPs
• Session lookups are performed on helper NPs

� J'LJ(;llDi:> ;Jt':Jit®
r.. Worldwide
�!. � Education Services """ ,un,per net 1 31
c,-

NPs Limit the Number of Interface Sessions

NP bundling is a feature that is only supported on the SRX5000 platform. By default, the traffic from
one physical interface is always processed by one NP (unless the interface is a member of an
aggregated interface). The NP limits the number of sessions that can be performed on an interface.
Each SRX5000 standard IOC's NP also has a capacity for 1 million sessions (2 million wings). Each
SRX5000 Flex IOC's NP supports 2 million sessions (4 million wings). One interface is always tied to
one NP, and any inbound traffic on the interface is always sent to the same NP for processing.

Bundled NPs Increase Interface Performance

An NP can support one or more physical interfaces. By bundling NPs together to serve one interface,
you can increase the number of sessions, wings, and packets per second (pps) throughput on that
interface. An NP bundle enables distribution of data traffic from one interface to multiple NPs for
packet processing. A primary NP is assigned for an interface as ingress traffic is received and
distributes the packets to several other secondary NPs called helper NPs. A single NP can act as a
primary NP or a helper NP to multiple interfaces. A single NP can join only one NP bundle. Session
lookups can be forwarded to helper NPs to increase performance. On the SRX5000, NP bundling
allows a total of 16 PICs per bundle and eight different NP bundles per system. You need to reboot
the SRX device to apply the configuration changes on the bundle. An NP bundle is not supported in
the transparent mode. Link aggregation groups (LAGs) and redundant Ethernet interface LAGs in
chassis cluster implementations can coexist with NP bundling. However, neither LAGs nor redundant
Ethernet interface LAGs can overlap with or share physical links with a NP bundle.
Continued on the next page.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-31

Advanced Ju nos Security
Bundled NPs Increase Interface Performance (contd.)
While NP bundling is only supported on the SRX5600 and SRX5800 devices, you can manually alter
the default mapping IOC-to-NPC mappings on SRX3400 and SRX3600 devices. By default, the
chassis process (daemon) runs an algorithm that performs the mapping. It maps an IOC to an NPC
that has the least amount of IOCs mapped to it. To assign a specific IOC to a specific NPC, u;se the
following configuration option:
set chassis ioc-npc-connectivity ice slot-number npc (none I slot-number)
Note that this configuration option also requires a reboot of the SRX device.

Appendix A-32 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

-�
Distributed Session Lookup with NP Bundle
iNPBuncii'er

--....
Olng)"ess I I

...
packe

0Egriess
packet
IOCs SPC

NP Bundling Example
The slide demonstrates traffic flow with an NP bundle configuration on four physical interfaces.
Remember, one interface is always tied to one NP. The ingress interface forwards a packet to its
associated NP. The ingress NP becomes the master NP for the session flow. After the master NP
receives the packet, it parses the IP packet header and generates a hash value. The master NP is
aware of helper NPs to use for session lookups. The master NP looks up the helper NP using the
hash value, and then forwards the packet to the helper NP. The helper NP receives the forwarded
packet and performs the usual task of flow lookup and packet parsing. The packet then follows the
normal traffic flow through the SRX5000. The NPU sends the packet to the CP. The CP selects the
SPU to set up the session for the packet, and it sends the packet to that SPU. The SPU processes the
packet and sends it to the egress NPU for transmission out the egress interface.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-33

Advanced Junos Security

NP Bundling Configuration
[edit interface pie-set Bundlel]
user@srx# show
interface xe-1/0/0; Master NP
interface xe-1/1/0; Master NP
fpc 1 {
pie O; Master NP and helper NP to xe-1/1/0
pie l; Master NP and helper NP to xe-1/0/0

fpc 2 {
pie O; Helper NP
pie l; Helper NP

NP Bundling Configuration
The slide shows the command-line interface (CU) configuration for the NP bundle example. The
pie-set command is used to create the NP bundle. In this case, we named the NP bundle
Bundle 1. The next step is to configure interfaces to belong to the bundle. You must specify both the
FPC and PIC locations of all interfaces to be used in the NP bundle. In this case, we place both PICO
and PIC 1 of FPCs 1 and 2 in the NP bundle, but we only specify interfaces xe-1/ o / o and
xe-1/1/ o as belonging to the bundle. Only incoming traffic on interfaces xe-1/ o / o and
xe-1/1/0 are going to participate in the NP bundle. The assigned NPs for each of these interfaces
become the master NPs for the traffic flow, and all other NPs in the bundle are used as helper NPs
for the traffic flow.

Appendix A-34 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Ai,enda: SRX Series Hardware and

ln'terfaces
II
Branch SRX Platform Overview
II
High-End SRX Platform Overview
II
SRX Traffic Flow and Distribution
�:SRX Interfaces

SRX Interfaces
The slide highlights the topic we will discuss next.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-35

Advanced Junos Security

SRX Branch Mini-PIMs

• WAN Mini-Pl Ms for the Branch SRX200 platforms

• ADSL2/2+, G.SHDSL 8-wire/4-port, VDSL2+, DOCSIS 3.0,
Synch Serial, SFP, T1/E1

-
- -
-:-CJ�
�
.- C"l •

SRX210 SRX220 SRX240

(1 PIM slot) (2 PIM slots) (4 PIM slots)

SRX Branch Mini-PIMs

Branch SRX platforms offer a variety of WAN interfaces. The Mini-PIMs used for WAN lntern,et
connectivity are Ethernet, DSL, Synch Serial, T1/E1, DOCSIS3, and 3G wireless interfaces. The single
port SFP Mini-PIM also supports different transceiver types including short-wavelength for Gigabit
Ethernet connectivity over multimode fiber, long-wavelength for Gigabit Ethernet connectivity over
multimode and single-mode fiber, 100BASE-FX for Fast Ethernet connectivity over multimoc!e and
single-mode fiber, and 1000BASE-T for Gigabit Ethernet connectivity over twisted pair.
A telco or ISP provides necessary information to configure WAN Internet connectivity. The information
provided may vary amongst various providers, but there are several basic things required to properly
configure Internet access. These include but may not be limited to:

WAN interface physical settings (T1, E1, Serial or DS3 options);

Data link encapsulation settings (Point-to-Point Protocol [PPP]. Frame Relay, Cisco
HDLC);
WAN IP address, subnet mask, and default gateway;
If PPP, username and password parameters;
If Frame Relay, data-link connection identifier (DLCI), Local Management Interface (LMI)
and other Frame Relay options; and
DNS IP and also possibly domain name.
The various Mini-PlMs are designed to meet all the necessary requirements for WAN lntern,et
connectivity.

Appendix A-36 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

D!JL Interfaces

• ADSL2/2+
• Asymmetric data transfer
• Annex A and B support
• G.SHDSL
• Symmetric data transfer
• Annex A B, F. and G support
• VDSL2+
• ADSL backwards compatibility
• Annex A and M support

-·J•s,; ·-
��----- Worldwide Education Services
Ne!wor1<s.1n-. )l,ll!ltf>h,..,e,ve<!_,
.�JUnlEf!,
�- ' R- -
---c.--o,.;
"'"'"''""'Per net I 17

ADSL Interfaces
The different types of DSL interfaces available for use on the SRX210, SRX220, and SRX240 are
ADSL, G.SHDSL, and VDSL. The single-port ADSL2/2+ Mini-Pl Ms are used to provide asymmetric
digital subscriber line (ADSL) WAN connectivity. The Mini-Pl Ms support Annex A and Annex B
connection types. Annex A supports connections over plain old telephone service (POTS) and
Annex B supports connections over ISDN. The ADSL Mini-PIMs support the ADSL, ADSL2, and
ADSL2+ protocols, and allow for automatic configuration of the ADSL line by the digital subscriber
line access multiplexer (DSLAM), minimizing configuration.

G.SHDSL Interface
Symmetric high-speed DSL (SHDSL), also known as G.SHDSL, is part of the xDSL family of modem
technologies that provide faster data transmission over a single flat untwisted or twisted pair of
copper wires. The G.SHDSL interface provides the physical connection to DSL network media types
and supports SHDSL for data transfer between a single subscriber and a central office.

VDSL Interface
Very-high-bit-rate digital subscriber line (VDSL) technology is part of the xDSL family of modem
technologies, which provide faster data transmission over a single flat untwisted or twisted pair of
copper wires. The 1-Port VDSL2 supports Annex A and Annex M connections. The VDSL2 Mini-PIM
has backward compatibility with ADSL/ADSL2/ADSL2+.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-37

Advanced Junos Security

ADSL Interface Configuration

[edit]
user@srx# show interfaces
at-1/0/0 {
encapsulation atm-pvc;
atm-options {
vpi _!!_;

ds 1-options
operating-mode auto;
}
unit O {
encapsulation atm-ppp-llc;
vci 8.35;
ppp-options {
chap {
default-chap-secret "$9 $Xr I7NbDj qmfzdb2 az U.mQFnCOIWB 7 ";
local-name alidcedsl;
passive;
}
family inet {
mtu 1450;
negotiate-address;

ADSL Interface Configuration

The slide shows a Point-to-Point Protocol over ATM (PPPoA) DSL configuration. The physical iinterface
properties include encapsulation types, atm-options, and dsl-options. The available
encapsulation types are atm-pvc and ethernet-over-atm. You use the atm-options
hierarchy to configure the ATM virtual path identifier (VPI). The VPI is referenced by the virtual
channel identifier (VCI) under the logical unit. In this case, the VPI value is 8, and the VCJ value is
8.35. The first integer of the VCI value must match the VPI value.
You use the dsl-options hierarchy to configure DSL interface-specific options. The
operating-mode auto configuration statement sets the ADSL line to autonegotiate the WAN
settings with the DSL access multiplexer (DSLAM). We are using the PPP authentication protocol
Challenge Handshake Authentication Protocol (CHAP), and we specify the CHAP secret
authentication key and local-name, used to connect with the DSL provider. By default, when CHAP is
enabled on an interface, the interface always challenges its peer and responds to challeng,es from
its peer. You configure the interface not to challenge its peer, and only respond when challenged, by
including the passive statement, as shown on the slide. We autonegotiate the IP address with the
DSL provider under the protocol family inet hierarchy. The ADSL interface and G.SHDSL interfaces
are represented with the designation at in the CLI. In contrast, VDSL2 interfaces are repres.ented by
the pt designation.

Appendix A -38 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

SE!rial Interface
• �:ey features
• Configurable clock rate
• Loopback diagnostics
• Automatically selects an operational mode based on DTE or
DCEcable
[edit]
user@srx# show interfaces
se-1/0/0 (
serial-options (
clock-rate rate;
clocking-mode dcelinternallloop;

Serial Interface
The single-port synchronous serial Mini-PIM interface is available for use on the SRX210, SRX220,
and SRX240. The interface provides the physical connection to serial network media types. The
interface forwards packets for processing while performing framing and line-speed signaling. Serial
WAN links are bidirectional links, and require very few control signals. In a basic serial setup, the
data circuit-terminating equipment (DCE) is responsible for establishing, maintaining, and
terminating a connection. A modem is a typical DCE device. A serial cable connects the DCE to a
telephony network where, ultimately, a link is established with data terminal equipment (DTE). The
serial Mini-PIM automatically selects an operational mode based on which cable type (DTE or DCE) is
connected. The serial interface also can perform loopback diagnostic testing. Loopback testing
allows you to verify the connectivity of a circuit. Ethernet, Tl and El interfaces can also perform
loopback diagnostic testing.
The slide shows the serial interface configuration options. The clock-rate specifies the interface
speed. The clocking-mode can be set to dee, internal, or loop. Loop clocking mode uses
the DC E's receive clock to clock data from the DCE to the DTE. Internal clocking mode, also known as
line timing, uses an internally generated clock. DCE clocking mode and loop clocking mode use
external clocks generated by the DCE.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-39

Advanced Junos Security

T1 and E1 Interfaces

• Key features
• CSU/DSU
• Internal and external clocking
[edit]
user@srx# show interfaces
tl-0/0/0 {
dee;
encapsulation frame-relay;
tl- options {
line-encoding ami;
framing esf;

unit O {
dlci 141;

)
el-1/0/0
encapsulation cisco-hdlc;
el-options {
framing g704;

T1 and E1 Interface Key Features

A T1 interface transmits digital signals in the T -carrier system used in the United States, Japan, and
Canada, and is the basic physical layer protocol used by the Digital Signal level 1 (DS1) multiplexing
method. A T1 interface can support 24 pulse code modulation (PCM) signals, called DSO cl1annels,
using time-division multiplexing (TDM), and operates at an overall bit rate of 1.544 Mbps. �,n E1
interface transmits signals in the European digital transmission (E1) format. The E1 signal format
carries information at a rate of 2.048 Mbps and can carry 32 channels of 64 Kbps each. Tile T1/E1
PIM provides the physical connection to T1 or E1 network media types and includes an inte,grated
CSU/DSU. The PIM is available for use on the SRX210, SRX220, and SRX240.
The slide shows basic T1 and E1 interface configurations. The physical interface propertieE, include
encapsulation types, tl-options and el-options, and the option to configure DCE clocking.
You can configure different encapsulation types, including frame-relay, ppp and cisco-hdlc.
You use the tl-options and el-options hierarchies to configure T1 and E1 interface-specific
options, such as framing and line-encoding. With frame-relay configured as the encapsulation type,
you must configure the DLCI under the logical unit properties. In this case, the DLCI value is 141. This
DLCI value must match the other end of the frame-relay circuit.

Appendix A-40 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

D<>CSIS 3 ..0 Interface

• K.ey features
• Termination to CMTS
• Cos Support
• Channel bonding to allow data transfer rates of over
150 Mbps downstream
[edit]
user@srx# show interfaces
cm-1/0/0 {
unit O {
family inet
dhcp;

<>.

DOCSIS 3.0 Interface Key Features

Data over Cable System Interface Specifications (DOCSIS) define the communications and
operational interface requirements for a data-over-cable system. DOCSIS is used by cable operators
to provide Internet access over their existing cable infrastructure for both residential and business
customers. DOCSIS 3.0 is the latest interface standard allowing channel bonding to deliver higher
data transfer rates. The DOCSIS 3.0 interface provides high-speed WAN connectivity. It can be used
as a single cable modem interface for connecting to a cable modem termination system (CMTS)
network. It also supports high-speed, bidirectional data transfer over an existing cable TV system.
The configuration is similar to that of an Ethernet interface, where the logical unit is configured with
an IP address, or is configured to negotiate an IP address from the upstream provider, as shown on
the slide. The DOCSIS interface uses the designation cm on the SRX device. The interface is available
for use on the SRX210, SRX220, and SRX240.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-41

Advanced Ju nos Security

SRX650 GPIMs

• T1 and E1 GPIMs

• GPIMS Versus xPIMs

SRX650
(8 PIM slots)

T1 and E1 GPIMs
A GPIM is a network interface card that installs in the front slots of the services gateway to provide
physical connections to a LAN or a WAN. The dual-port and quad-port T1/E1 GPIMs provide the
physical connection to T1 or E1 network media types, perform framing and line-speed signaling, and
include an integrated CSU/DSU. The T1 and E1 GPIMS are available in either dual-port or quad-port
modules. The SRX650 chassis can hold GPIMs that use more than one standard slot. It could be
double-high, single-wide, which uses two standard slots vertically, or it could be double-high,
double-wide, which uses two vertical and two horizontal slots for a total of four standard slots.
Because the GPIMs communicate with the backplane at various performance levels, you must install
them in the correct slots.

GPIMs Versus xPIMs

The designation GPIM refers to the modules that have a 1 Gigabit Ethernet backplane. The GPIM
receives incoming packets from a network and transmits outgoing packets to a network. These
modules will complement the onboard Ethernet interfaces to extend the types and port counts of
network connections for the LAN or WAN. Standard GPIMs are installed in a single-high, single-wide
GPIM slot that has gigabit connectivity to the system backplane. The XPIM designation refers to the
modules that have a 10 Gigabit Ethernet backplane. The XPIM can be installed only in the 20-gigabit
GPIM slots (slot numbers 2 and 6 on the front panel). The XPIM may be a single-high, single-wide
LAN switch GPIM that uses one slot. a double-high, single-wide LAN switch GPIM that uses two
standard slots vertically, or a double-high, double-wide LAN switch GPIM that uses two standard slots
vertically and two standard slots horizontally.

Appendix A-42 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

3G, Wireless WAN Interfaces

• 3G ExpressCard for the SRX210

• CX111 Bridge
·• For use on all branch SRX Series

CX111 Cellular Bridge

3G ExpressCard
The SRX210 has the added capability to use a third-generation (3G) wireless ExpressCard as a WAN
interface. The 3G ExpressCard can either be used as a backup or a primary WAN link supporting
Evolution-Data Optimiz�d (EV-DO), Code Division Multiple Access (CDMA), universal mobile
telecommunications system (UMTS), High-Speed Packet Access (HSPA), or Global System for Mobile
Communications (GSM) standards. The 3G ExpressCard is an ideal backup option for small branch
deployments with adequate 3G coverage. The SRX210 has a built-in 3G ExpressCard slot for single
device 3G connectivity. The 3G ExpressCard ships with an external antenna for improved
performance. The 3G wireless card is used as a backup interface by using a dialer interface. Only
when the primary interface is down will the dialer interface be enabled, triggering a connection to the
3G network.

CX111 Bridge
The CX1113G Cellular Broadband Data Bridge delivers simple and flexible cellular data connectivity
for small and large branch offices. It is the industry's first all Ethernet cable plant that does not
require a coaxial cable or an antenna for installation. The 3G Bridge supports 802.3af PoE for
additional ease of installation. The 3G Bridge integrates with all branch SRX platforms.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-43

Advanced Junos Security

3G WAN Link Backup for Branch Office

-
• Maintain connectivity if Ethernet WAN link goes down
@
SRX210 SRX210 dlO l
=········
[edit]
user@srx# show interfaces
ge-0/0/ 0 {
unit O {
backup-options {
interface dlO.O;

}
cl-0/0/8
modem-options
init-command- string ATS0=2;
}
dialer-options {
pool 1 priority 100;

3G WAN Link Backup Configuration

The slide demonstrates how the SRX210 maintains Internet connectivity if the Ethernet W/J.N link
goes down. The 3G wireless card establishes a WAN connection through a dialer interface, similar to
ISDN and USS modems. A logical dialer interface dlO is used to trigger calls. The physical interface
cl-0/0/8 specifies the modem initialization commands (AT commands) and it is assigned a dialer
pool number. When traffic is sent to the dlO interface, this interface enables the physical interfaces
in the dialer pool and places calls through them. In the case of the 3G wireless interface, tl1e dialer
interface will always refer to a dialer pool with only one 3G card in it. Under the primary WAN
interface, the dialer interface dlO is specified under the backup-options hierarchy. The dialer
interface is used to terminate PPP and IP, so it holds all of the PPP and IP-related configurations.

Appendix A-44 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Backup Interface Configuration

• Dialer interface activation
[edit}
usei:@scx# show interfaces
dlO {
unit a
family inet {
negotiate-address;

dialer-options {
pool 1;
dial-stc ing !.J..J..;
activation-delay 60;
deactivation-delay 60;

cou t: ing-op tions

2:tatic {
route 0.0.0.0/0 next-hop [ dlO.O 200.0.0.2 J;

Dialer Interface Activation

The dialer interface dlO is activated after the primary WAN interface goes down. The
activation-delay and deactivation-delay configuration statements can be used to avoid
interface flaps by forcing a delay between the time the primary interface changes states and the
time the dialer interface is enabled or disabled. The activation-delay command controls the
time between the primary interface going down and the activation of the dialer interface. Similarly,
the deactivation-delay command controls the time between the recovery of the primary link
and the deactivation of the backup.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-45

Advanced Junos Security

WAN Backup with Route Monitoring

• Prefix watch-list activates the dialer interface

[edit]
user@srx# show interfaces
dlO {
unit O
family inet {
negotiate- address;

dialer-option s
pool 1;
dial-string 777;
watch-list {
10 . 0 . 0 . 0/ B;

Prefix Watch-List Activation

One drawback with the previous example is that the primary interface's status is not always a good
indicator of the network's connectivity. In some instances, when the Layer 2 protocols are not able to
detect end-to-end failures, or when multiple network hops separate the SRX210 from the remote
resources, other means to trigger a failover are desired. The slide example shows how to configure a
set of prefix watch-lists which, when they are not present in the routing table, will enable the dialer
interface. Static routes with Bidirectional Forwarding Detection protocol (BFD) monitoring or routing
protocols can be used to dynamically change the status of the routes in the routing table.

Appendix A-46 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Summary
• In this content, we:
• Described the different SRX platforms
• Explained SRX hardware components and traffic flows
• Implemented the various SRX interface types

We Discussed:
Different SRX platforms;
SRX hardware components and traffic flows; and
SRX interface types.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-4 7

Advanced Ju nos Security

Review Questions

1. What is an additional feature of the SRX650 from

other branch SRX devices?
2. What are the three data plane components of the
SRX3000 platform?
3. Which interfaces can be configured to provide
clocking?

Review Questions
1.

2.

3.

Appendix A-48 • SRX Series Hardware and Interfaces www.juniper.net

Advanced Junos Security

Answers to Review Questions

1.
The SIL'C650 provides power redundancy, and hardware-based separation of control and data planes.
2.
The three data plane components of the SRX3000 platform are IOCs, NPCs, and SPCs.
3.
The serial, Tl, and El interfaces can be configured to provide clocking.

www.juniper.net SRX Series Hardware and Interfaces • Appendix A-49

Advanced Ju nos Security

Appendix A-50 • SRX Series Hardware and Interfaces www.juniper.net

Acronym List

3G.................................................................................... third-generation
ACL................................................................................. access control list
ADSL................................................................... asymmetric digital subscriber line
AFTR.................................................................... Address Family Transition Router
AH............................................................................... authentication header
ALG.......................................................................... Application Layer Gateway
ARP......................................................................... Address Resolution Protocol
ASC........................................................................... application system cache
BFD............................................................ Bidirectional Forwarding Detection protocol
BGP ........................................................................... Border Gateway Protocol
CA.................................................................................. certificate authority
CCC..... ........................................................................... circuit cross-connect
CDMA...................................................................... Code Division Multiple Access
CE...... ................................................................................ customer edge
CFM .........................................................................common form-factor module
CGN .................................................................................. carrier-grade NAT
CHAP ........................................................ Challenge Handshake Authentication Protocol
CLI .............................................................................command-line interface
CMTS ....•.••................................................•.••...... cable modem termination system
Cos.......••••................................................•........................ class of service
CP.......••...••......................................................................... Central Point
CPE......••...••.......................................................... customer premises equipment
CPP............••...............................................•.............. Control Plane Processor
cps ....•.••.••..................................................•.•..••.••..... connections per second
CRL............................................................................ certificate revocation list
dcd .......••.••.................................................•................ device control process
DCE........•..•..................................................••... data circuit-terminating equipment
DDoS ......•....••...............................................•.......... distributed denial of service
DER ............••.••••....................................................Distinguished Encoding Rules
DFA.......•..•••••.•............................................•.........deterministic finite automation
DHCP .......................................................•........ Dynamic Host Configuration Protocol
DLCI ............•••...•......................................•.•.......... data-link connection identifier
DN ...............•................................................................ distinguished name
DNS .............•....•.......................................................... Domain Name System
DOCSIS........•••••••••.................................... Data over Cable System Interface Specifications
DoS.............•..................................................................... denial of service
DPD .......•....•.....•............................................................dead peer detection
DSCP .............................................................................. DiffServ code point
DSLAM............•.•.•.......................................... digital subscriber line access multiplexer
OS-Lite ....•...••........................................................................ dual-stack lite
DTE...........•••••..••........................................................ data terminal equipment
DVMRP.......................................................... Distance Vector Multicast Routing Protocol
ESD........•..•••.....•......................................................... electrostatic discharge
ESP...................................................................... Encapsulating Security Payload
EV-DO......•..•••.•...•....................................................... Evolution-Data Optimized
FBF..............•................................................•..•...........filter-based forwarding
FQDN ............•.••.•..................................................... fully qualified domain name
GB.....................••••.....•••.••.•.................................................... gigabyte
GDOI.............••••.•.................................................. Group Domain of Interpretation
GPIM......................•••.•••............................. Gigabit-Backplane Physical Interface Module
GRE .......................................................................generic routing encapsulation
GSM............................................................ Global System for Mobile Communications
GUI............................................................................. graphical user interface
HA.....................................................................................high availability
HSPA ...........••.•••....................................................... High-Speed Packet Access

www.juniper.net Acronym List • ACR-1

HTIP .....................•.................................................. Hypertext Transfer Protocol
HTIPS ................................................ Hypertext Transfer Protocol over Secure Sockets Layer
ICMP ..................••••....••...................................... Internet Control Message Protocol
IDP.................................................................... Intrusion Detection and Prevention
IEEE......................•....•.•...........................Institute of Electrical and Electronics Eingineers
IETF...............•.•................................................... Internet Engineering Task Force
IGMP................................................................ Internet Group Management Protocol
IKE.............................................................................. Internet Key Exchange
IOC.................................................................................. input/output card
IPS................................................................••..••... Intrusion Prevention System
IPsec.....•..••............................................................................ IP Security
1Pv4 ...................................................................................... IP version 4
1Pv6....•.••••............................................................................ IP version 6
ISO........................................................... lnternationaI Organization for Standardization
ISP.........••.................................................................. Internet service provider
JNCP ...................................................••.•••••... Juniper Networks Certification Program
KB .......................................................................................... l�ilobytes
Kbps ..................................................••••..•...................... kilobits per second
KEK.................................................................................key encryption key
LAG .......................................•..•••................................ link aggregation group
LBT .............................................................................. load-balancing thread
LDAP ....................................•.••••••..•.•............... Lightweight Directory Access Protocol
LSA ............................................................................ link-state advertisement
LSYS ......................................•••.••••.•.•................................. logica,I system
MAC.............................................................................. media access control
MB.....................................•••...•.••••.•..................................... megabytes
MD5 ....................................•........................................... Message Digest 5
MGCP ................................................................... Media Gateway Control Protocol
Mini-PIM ............................................................. Mini-Physical Interface Module (PLM)
MSDP ................................................................ Multicast Source Discovery Protocol
MSS............................................................................ maximum segment size
MTU.........................................................................maximum transmission unit
NAT ........................................................................ Network Address Translation
NAT-T...............................................................Network Address Translation-liraversal
NHTB........................................................................... next-hop tunnel binding
NP ................................................................................. Network Processor
N PC........................................................................... Network Proces�.ing Card
NPU............................................................................Network Processing Unit
NSPC...............................................................Network and Services Processing Card
OSI....................................................................... Open Systems Interconnection
OSPF...........................................................................Open Shortest F'ath First
PAT ............................................................................Port Address Translation
PCM............................................................................. pulse code modulation
PE ...................................................................................... provider edge
PEM............................................................................. Privacy-Enhanced Mail
PFE .......................................................................... Packet Forwarding Engine
PFS ............................................................................ Perfect Forward Secrecy
PIM .......................................................................... Physical Interface Module
PIM ...................................................................... Protocol Independent Multicast
PKI............................................................................. public key infrastructure
PoE ............................................................................... Power over Ethernet
POT ............................................................................. packet-ordering thread
POTS.........................................................................plain old telephone service
PPP ............................................................................. Point-to-Point Protocol
PPPoA................................................................... Point-to-Point Protocol over ATM
pps ................................................................................ packets per second
PPTP ..... ; .............................................................. Point-to-Point Tunneling Protocol
QoS .................................................................................. quality of service
RDP.................................................................................. Remote Desktop
RE .................................................................................... Routing Engine

ACR-2 • Acronym List www.juniper.net

regex ................................................................................regular expression
reth ..........................................................•••................... redundant Ethernet
RIB ....••...•.•..............................................••...............Routing Information Base
RP .......••.•.................................................••..................... rendezvous point
RPF ............................................................................ reverse path forwarding
rsh ......•...•.•..............................................•••........................remote shell
RTSP .....••................................................................Real-Time Streaming Protocol
SA .................................................................................security association
SAP ..................................................................... Session Announcement Protocol
SCB...............•...........................................•...................Switch Control Board
SCEP ........................................................•.......Simple Certificate Enrollment Protocol
SCM ......••.••.•••.••.......................................•••................ SRX Clustering Module
SDP ........................................................................ Session Description Protocol
SHA-1 .....••.••.••...•........................................••••••••••.......Secure Hash Algorithm 1
SHDSL ..........................................................••.•......... symmetric high-speed DSL
SI ...................................................................................system integrator
SIP ..............•............................................................Session Initiation Protocol
SNMP ..........................•............................•......Simple Network Management Protocol
SoHo..........................................................•................small office/home office
SPC ............................................................................services processing card
SPI ...............................................................•...•••......security parameter index
SPU ............................................................................Services Processing Unit
SQL ..................................................................•••.... Structured Query Language
SRE ........................................................................ Services and Routing Engine
SSL .............................................................................. Secure Sockets Layer
STRM .................................................................Security Threat Response Manager
STUN ...................................................................Session Traversal Utilities for NAT
SYSIOC ....................................................................... System lnpuVOutput Card
TDM ..........................................................................time-division multiplexing
TEK .........................•.......................................................traffic integrity key
TFTP ........................•............................................... Trivial File Transfer Protocol
UAC ....................••........................................................Unified Access Control
UDP ...................•••••••...•............................................. User Datagram Protocol
UMTS ....................... : .................................universal mobile telecommunications system
UTM ...................•.••.••...•..........................................Unified Threat Management
UUID ..........................................................................universal unique identifier
VCI ............................................................................ virtual channel identifier
VDSL ...............................................................very-high-bit-rate digital subscriber line
VIP ......................................................................................... virtual IP
VLAN ........................••............................................................ virtual LAN
VoIP .....................................................................................voice over IP
VPLS ........................•.................................................virtual private LAN service
VPN .........................•....................................................virtual private network
VR ..........................•............................................................virtual router
VRRP .....................•.•.........................................Virtual Router Redundancy Protocol
WINS......................................•..............................Windows Internet Name Service
XAUTH .....................••.•.................................................extended authentication

www.juniper.net Acronym List • ACR-3

ACR-4 • Acronym List www.ju1niper.net