Juniper Networking Technologies

DAY ONE: ADVPN DESIGN AND

IMPLEMENTATION

Using the AutoDiscovery VPN protocol

is a new and different approach to solving
real-world IPsec encryption problems.
Get ahead of the curve and into the lab
with this workbook full of overviews, con-
figurations, and troubleshooting samples.

By Mark Barrett, Dale Shaw, and Scott McKinnon

 DAY ONE: ADVPN DESIGN AND IMPLEMENTATION

Neither the fully-meshed nor hub-and-spoke approaches to IPsec VPNs are optimal for
modern network deployments where customers demand both the ease of provisioning
encrypted overlay security services and the optimum flow of traffic to minimize ap-
plication traffic latency. What is needed is an approach that takes the simplified provi-
sioning of hub-and-spoke with the low application latency of fully-meshed.

Spokes should have the capability to temporary build tunnels between each other on
an on-demand basis to create the most efficient forwarding path, so if a particular flow
is required, the spokes build dynamic tunnels between themselves for that communi-
cation and then clear the tunnel when idle. In this way the fully-meshed approach is
available to the network without the overhead of configuring all the necessary com-
munication paths. The hub takes care of the task of identifying whether dynamic con-
nections are required. The SRX Series employs a feature called AutoVPN to deliver this
capability, which has been shipping since Junos 12.1X44. Now AutoVPN deployments
can use the Auto Discovery VPN (ADVPN) protocol to dynamically establish spoke-to-
spoke VPN tunnels.

This Day One book will tell you why and show you how, while providing sample imple-
mentations to investigate in your lab.

IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
nn Gain an appreciation of the main issues surrounding the integration of encryption technology
into networking products.
nn Understand the need for a standards-based approach to solving network integration issues.
nn Understand Juniper’s AutoDiscovery VPN (ADVPN) solution.
nn Learn how to incorporate the ADVPN feature into a design.
nn Explore the detailed steps required to implement and tune ADVPN in your network.
nn Take architectural blueprint designs as a base template to be tailored for your specific scenario.

Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the
complete library at www.juniper.net/books.

Published by Juniper Networks Books

ISBN 978-1941441169
51800

9 781941 441169
Juniper Networking Technologies

Day One: ADVPN Design and

Implementation

By Mark Barrett, Dale Shaw, and Scott McKinnon

Chapter 1: Why ADVPN ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 2: A Standards-based Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Chapter 3: ADVPN Key Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 4: Key Configuration Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 5: Tuning Considerations for ADVPN . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 6: Management and Day-to-Day Operations. . . . . . . . . . . . . . . . . . 53

Chapter 7: Using Junos Automation to Help Manage

ADVPN Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 8: Troubleshooting ADVPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 9: Architectural Blueprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
iv

© 2015 by Juniper Networks, Inc. All rights reserved. About the Authors
Juniper Networks, Junos, Steel-Belted Radius,
NetScreen, and ScreenOS are registered trademarks of Mark Barrett
Juniper Networks, Inc. in the United States and other Mark Barrett has been working in the networking
countries. The Juniper Networks Logo, the Junos logo, industry for 28 years. He has been through many
and JunosE are trademarks of Juniper Networks, Inc. All networking technology transitions (both protocols and
other trademarks, service marks, registered trademarks, transmission techniques) from his part time University
or registered service marks are the property of their jobs, to IBM, Cisco, and the Australian Federal Police, to
respective owners. Juniper Networks assumes no his current position as a Juniper Networks Systems
responsibility for any inaccuracies in this document. Engineer. No matter the technology, Mark has main-
Juniper Networks reserves the right to change, modify, tained a keen interest in high speed networking LAN and
transfer, or otherwise revise this publication without WAN technologies and, in particular, how they need to
notice. be secured.

Published by Juniper Networks Books To the rest of the author team, thank you for your
Authors: Mark Barrett, Dale Shaw, and Scott McKinnon persistence as we all have busy day jobs that often turned
Technical Reviewers: Johan Andersson, Anubhav Garg, into our night jobs as well, to get the book completed. To
Bill Shelton the engineering team (Praveen Sathyanarayan, Anubhav
Editor in Chief: Patrick Ames Gar, Suresh Melam and, Rajendra Kandukuri) putting up
Copyeditor and Proofer: Nancy Koerbel with field SEs pestering and challenging to go the extra
Illustrator: Karen Joice mile for the first release of ADVPN through the alpha
J-Net Community Manager: Julie Wider and beta phases. To our review team (Bill Shelton, Gavin
Thirlwall, Johan Andersson) for making sure what we
ISBN: 978-1-936779-16-9 (print) wrote would be useful to people in the field. To our
Printed in the USA by Vervante Corporation. editing support team, Nancy Koerbel sorry for the
ISBN: 978-1-936779-17-6 (ebook) Australian English and Karen Joice thanks for turning
our diagrams into something nice. And finally Patrick
Version History: v1, September 2015 Ames, giving us the confidence to start the project,
2 3 4 5 6 7 8 9 10 keeping the relatively big author team on track, and
cracking the whip when we all needed a push.
This book is available in a variety of formats at:
http://www.juniper.net/dayone.
 v

About the Authors (continued)

Dale Shaw Scott McKinnon

Dale Shaw is a Systems Engineer in the Australian Federal Scott McKinnon is a Senior Product Manager in the
Government team at Juniper Networks. He has worked Juniper Networks Security and Switching Product Team
for Juniper Networks in Canberra since the beginning of (SSPT) within the Juniper Design and Innovation (JDI)
2014, helping government enterprises to design, build and group. Scott has been working with IPsec and related
manage secure IP networks. Prior to Juniper Networks, encryption technologies for over 15 years, and has
Dale spent seven years working for Alphawest and Optus experience in post-sales and pre-sales, as well as product
Business as a solutions designer and architect. In these management. He has contributed to the development of
roles Dale helped design, deploy and operate large scale IP the ADVPN capability and related technologies, like
networks carrying voice, video and data over IPsec VPNs. GDoI, from initial customer requirements through
Dale holds a number of industry certifications such as product specification and into customer trials and release.
JNCIP-ENT, JNCIP-SEC, and CCIE R&S (#24464). He holds an MBA in Technology Management from the
Open University (UK), as well as a BEng(Hons) in
I’d like to thank my co-authors, Mark Barrett and Scott Engineering from Glasgow Caledonian University(UK).
McKinnon, for making this project happen. Patrick Ames Scott manages Juniper's public sector accreditation
has been an excellent “cat herder” and Nancy Koerbel a program, where many of the ADVPN requirements
cold and clinical assassin of all of the British English we originated. He is based in Sunnyvale, California.
handed over (just kidding, Nancy, you applied a generous
quantity of polish!). Praveen Sathyanarayan is not only Scott would like to acknowledge the contributions of John
the chief designer of ADVPN itself but also provided a lot Veizades and Steve Hanna to the initial stages of what
of invaluable technical information and review along the became ADVPN and to applaud the design and execution
way -- thanks Praveen! Thanks also to Bill Shelton and by the Juniper JDI Engineering Team of Suresh Melam,
Gavin Thirlwall, from the Juniper US federal and UK Praveen Sathyanarayan, Anubhav Garg, Vineeth Kisara,
government teams, respectively, for providing inputs Rajendra Kandukuri, and Jinesh Doshi. Thanks to the
specific to their geographic contexts, and to Johan main authors, Mark and Dale, and to our reviewers Bill
Andersson and Anubhav Garg for their inputs and Shelton, Gavin Thirlwall, and Johan Andersson, and
reviews. Last but certainly not least, I would like to thank editors Patrick, Nancy, and Karen.
my wife, Katie, and my two kids, for tolerating all of my
nerdy (often late night) pursuits.
 vi

Welcome to Day One

This book is part of a growing library of Day One books, produced and
published by Juniper Networks Books.
Day One books were conceived to help you get just the information that
you need on day one. The series covers Junos OS and Juniper Networks
networking essentials with straightforward explanations, step-by-step
instructions, and practical examples that are easy to follow.
The Day One library also includes a slightly larger and longer suite of
This Week books, whose concepts and test bed examples are more
similar to a weeklong seminar.
You can obtain either series, in multiple formats:
„„ Download a free PDF edition at http://www.juniper.net/dayone.
„„ Get the ebook edition for iPhones and iPads from the iTunes Store.
Search for Juniper Networks Books.
„„ Get the ebook edition for any device that runs the Kindle app
(Android, Kindle, iPad, PC, or Mac) by opening your device’s
Kindle app and going to the Kindle Store.
„„ Purchase the paper edition at either Vervante Corporation (www.
vervante.com) for between $12-$28, depending on page length.
„„ Note that Nook, iPad, and various Android apps can also view
PDF files.

What You Need to Know Before Reading This Book

Before reading this book, you should be familiar with the basic adminis-
trative functions of the Junos operating system, including the ability to
work with operational commands and to read, understand, and change
Junos configurations. There are several books in the Day One library on
learning Junos, at www.juniper.net/dayone.
This book assumes that you, the reader, know:
„„ Basic IP networking design and operation
„„ Basic IPsec protocol implementation
„„ Basic Junos OS CLI procedures
„„ Basic SRX concepts and principles
 vii

After Reading This Book, You’ll Be Able To

„„ Gain an appreciation of the main issues surrounding the integra-
tion of encryption technology into networking products.
„„ Understand the need for a standards-based approach to solving
network integration issues.
„„ Understand Juniper’s AutoDiscovery VPN (ADVPN) solution.
„„ Learn how to incorporate the ADVPN feature into a customer
design.
„„ Explore the detailed steps required to implement and tune ADVPN
in the customer network.
„„ Apply architectural blueprint designs as a base template to be
tailored for your specific customer scenario.

Preface
IP Security, or more simply IPsec, is the Internet Engineering Task Force
(IETF’s) standard for securing the network layer in IP systems, covering
both IPv4 and IPv6. IPsec was originally defined by the IETF in 1998
and since then has been defined as an optional element for IPv4 and a
mandatory element for IPv6. IPsec has gone through a number of
iterations over the years and many additional RFCs have been defined to
augment the main elements of the protocol with new encryption algo-
rithms, authentication functions, and modes of operation.
While IPsec has been around for awhile, implementing such a protection
suite in IP networks remains a challenge. Network devices such as
routers and firewalls require the protocol to be integrated into their
operating systems to assert security policy. The security capabilities of
IPsec must be deployed in network topologies that are evolving to
support the demands of ever-newer applications and services, and the
protocol must coexist with dynamic routing protocols in order to
maintain efficient forwarding of traffic in the event of disruption. These
conflicting challenges have resulted in unfortunate compromises being
made between ease-of-design, deployment, ongoing management, and
securing the application traffic efficiently within a service oriented
network model. Until now.
 viii

Juniper Networks SRX Series of security gateway devices are a range

of network products designed to integrate security, routing, and
switching in a single Junos OS platform. IPsec is therefore a corner-
stone of any such platform.

Scope of Book
This Day One book attempts to cover the following ADVPN concepts,
and was written in such a way that you can follow along in your own
lab:
„„ Configuration
„„ Tuning
„„ Service Management
„„ Blueprints
„„ Automation
„„ Futures
Chapter 1

Why ADVPN?

This chapter details the main approaches taken by several vendors of

IPsec VPN technologies to produce, from the respective IETF RFCs,
meaningful solutions for customers to deploy in order to solve real
world encryption problems. It provides a basic summary of the
relevant RFCs, the approaches that have emerged for deployment,
and the issues with these approaches, and sets out the requirements
for a new and different approach that is fulfilled by ADVPN.

The IETF IKEv2 Peer-to-Peer Model

RFC 7296 is the specification for the Internet Key Exchange (IKE)
protocol, currently designated as version 2, (IKEv2). RFC 7296
replaces RFCs 4306 and 5996, which in turn replaced the IKEv1
RFCs, 2407, 2408, and 2409 specifications. RFC 7296 defines a
control plane protocol to be used by IPsec peers to establish the
services, cryptographic algorithms, and the keys necessary for each
to maintain the correct state.

MORE? RFC 7296 can be read here: https://tools.ietf.org/html/rfc7296.

RFC 7296 also defines a basic model whereby a system consisting of

protected subnets, tunnel endpoints, and IPsec tunnels can be
established for the purpose of protecting traffic in transit across
untrusted networks, giving rise to three main use cases.
„„ Gateway-to-Gateway
„„ Endpoint-to-Endpoint
„„ Endpoint-to-Gateway
 10 Day One: ADVPN Design and Implementation

In addition, tunnels can be established in one of two modes: tunnel or

transport. Tunnel mode is when the security gateways or protected
endpoints provide security services to the datagrams by fully encapsu-
lating them in a new IP layer, forming new addressing between the
peers. Transport mode is when only the payload of the IP packet is
protected and no additional IP layer is required.

Use Case One

In this first use case, or Security Gateway-to-Security Gateway, peers
protect traffic on behalf of connected subnets via an IP overlay model
using tunnel mode IPsec, as detailed in Figure 1.1.

Figure 1.1 Security Gateway-to-Security Gateway IPsec VPNs

NOTE Use Case One is the typical “secure router” model and it is the focus of
this book. The other two use cases are included in this chapter to
provide a complete discussion.

Use Case Two

In this use case Endpoint-to-Endpoint peers protect traffic with their
own addresses without an IP overlay model using transport mode IPsec
as detailed in Figure 1.2. This is the typical “secure host” model and is
out of scope for this book because it does not involve security gate-
ways.
 Chapter 1: Why ADVPN ? 11

Figure 1.2 Endpoint-to-Endpoint IPsec VPNs

Use Case Three

In Use Case Three, Endpoint-to-Security-Gateway peers protect traffic
from the host to the network via an IP overlay model using tunnel mode
IPsec as detailed in Figure 1.3. This is the typical “remote access model”
and again is out of scope for this book because it does not solely involve
security gateways.

Figure 1.3 Endpoint-to-Security Gateway IPsec VPNs

The Point-to-Point Model

The goal of IKEv2 is therefore to provide a dynamic means of creating
state between peers for the purpose of protecting traffic from a single
source of IP datagrams to a single sync of IP datagrams. Furthermore,
when employing the tunnel mode approach, IKEv2 implies that an
overlay routing model is introduced. Irrespective of which mode is
employed, each peer must create a point-to-point tunnel over a transit
network, causing network designers and administrators problems.
 12 Day One: ADVPN Design and Implementation

Current Approaches to the Point-to-Point Problem

Vendors have evolved two main approaches to Use Case One: fully-
meshed, and hub-and-spoke to handle the point-to-point scenario.

Fully-Meshed IPsec VPNs

Fully-meshed VPNs occur when each member of the VPN domain has
a set of tunnels defined to each and every other member of the VPN
domain. This arrangement is highly desirable from a traffic flow
perspective because all the nodes can encrypt traffic to each other in
the most efficient manner. However, this approach comes at a cost –
complexity and manageability – because the number of tunnels to be
configured and activated on a given node in a fully-meshed network is
equal to n-1 and n2-1. For example, a 100-node network would
require 9,999 tunnels to be provisioned. If n is large, then computa-
tionally, expensive nodes need to be deployed and managed to make
the mesh work, thus increasing both the capital and operational costs
associated with the network. Figure 1.4 details such a fully-meshed
network arrangement with eight peers.

Figure 1.4 Fully-Meshed IPsec VPNs

Hub-and-Spoke VPNs

To resolve the complexity and cost issues associated with fully-meshed

VPNs, hub-and-spoke VPNs have emerged. The principle here is that
all non-hub nodes, designated as spokes, create a single connection to a
hub device. Traffic is then routed to all other spokes within the
 Chapter 1: Why ADVPN ? 13

domain, via the common hub. Now configuration tasks are simpler
and the active tunnel count on a per-node basis is significantly lower,
meaning more cost-effective nodes can be deployed and managed.
As with the fully-meshed approach, there are drawbacks: the hub
requires configuration changes each and every time a node is added or
removed from the VPN domain and application latency is increased.
Also, all traffic must first leave the source node, traverse the transit
network to the hub, and then return to the sink node in a non-direct
and sub-optimal manner.

Figure 1.5 Hub-and-Spoke IPsec VPNs

A New Approach
Neither the fully-meshed nor hub-and-spoke approaches are optimal
for modern network deployments where customers demand both the
ease of provisioning encrypted overlay security services and the
optimum flow of traffic to minimize application traffic latency. Table
1.1 summarizes these approaches and evaluates their ability to meet
the requirements.

Table 1.1 Comparison of VPN Approaches

Fully-Meshed Hub-and-Spoke

Provisioning Complex Simple

Application Latency Low High

 14 Day One: ADVPN Design and Implementation

The Solution
What is needed today is an approach that takes the simplified provi-
sioning of hub-and-spoke with the low application latency of fully-
meshed.

Making the Hub Zero Touch

The hub device should be zero-touch once deployed, so that adding
and removing nodes in the VPN domain do not affect the operation of
the network. Thus network administrators can design, provision, and
manage the network more effectively, reducing cost and risk to high
availability.
The SRX Series employs a feature called AutoVPN to deliver this
capability, which has been shipping since Junos 12.1X44.

Making the Spoke-to-Spoke Connections Dynamic

Spokes should have the capability to temporary build tunnels between
themselves on an on-demand basis to create the most efficient forward-
ing path, so if a particular flow is required, the spokes build dynamic
tunnels between themselves for that communication and then clear the
tunnel when idle. In this way the fully-meshed approach is available to
the network without the overhead of configuring all the necessary
communication paths. The hub takes care of the task of identifying
whether dynamic connections are required.
The SRX provides this capability by extending the AutoVPN feature to
include support for this type of behavior with the new ADVPN feature.

Summary
Table 1.2 compares ADVPN with the fully-meshed and hub-and-spoke
approaches and evaluates them for desirability. As you can see,
ADVPN is simple to provision with low application latency, making it
highly desirable.

Table 1.2 Comparing All Approaches

Fully-Meshed Hub-and-Spoke ADVPN

Provisioning Complex Simple Simple

Chapter 2

A Standards-based Approach

There are a number of proprietary solutions that have been created

by network vendors to solve the integration of IPsec into networks,
examples include:
„„ Juniper: NetScreen Auto-Connect VPN (AC-VPN)
„„ Cisco: Dynamic Multipoint VPN (DMVPN)
„„ HP: Dynamic VPN (DVPN)
Juniper believes in open standards and has collaborated with
industry players to create a document outlining the requirements.
This document was subsequently published as RFC 7018 and was
adopted by the IETF IPsec Maintenance and Extensions (IPSECME)
Working Group as the problem statement and requirements for Auto
Discovery VPN. Juniper and others then created a solution to the
problem that was circulated as a draft RFC: draft-sathyanarayan-
ipsecme-advpn-03.

MORE? The draft RFC containing the solution is located here as it temporar-
ily awaits publication as an informational RFC: http://tools.ietf.org/
html/draft-sathyanarayan-ipsecme-advpn.
 16 Day One: ADVPN Design and Implementation

RFC 7018 Summary

RFC 7018 defines the problem space in terms of use cases and the RFC
7018 Problem Statement. The use case is a large-scale IPsec deploy-
ment operating in a fully-meshed environment covering:
„„ Gateways-to-Gateways
„„ Clients-to-Gateways
„„ Clients-to-Clients
And the main problems to solve are:
„„ Configuration Complexity
„„ Device-Level IPsec Tunnel Management

RFC 7018 Problem Statement: Use Case One

Use Case One involves an endpoint-to-endpoint VPN with direct, fast,
efficient connections for geographically local peers and with latency,
bandwidth, and costs concerns for secure voice and video, all with
trusted authentication as illustrated in Figure 2.1.

Figure 2.1 Endpoint-to-Endpoint Use Case

 Chapter 2: A Standards-based Approach 17

RFC 7018 Problem Statement: Use Case Two

Use Case Two is a gateway-to-gateway VPN, where:
„„ Multi-media application support is inefficient in a star topology
„„ There is a need to allow for cross-organization/domain support
„„ Where the gateway may have dynamic addresses
„„ Traffic forwarding policy is required
„„ Layer 3 VPNs are within IPsec tunnels
„„ Additional peer authentication is required as shown in Figure 2.2

Figure 2.2 Gateway- to-Gateway Use Case

RFC 7018 Problem Statement: Use Case Three

Use Case Three is an endpoint-to-gateway VPN that determines the
most appropriate gateway on the network and provides a seamless
connection to the most appropriate gateway on network. This is
illustrated in Figure 2.3.
 18 Day One: ADVPN Design and Implementation

Figure 2.3 Endpoint-to-Gateway Use Case

Inadequacy of Existing Solutions

The following items were identified as concerns with existing large-scale
VPN solutions for deployment:
„„ Exhaustive configurations are needed
„„ It does not scale
„„ Cannot easily work across organization boundaries
„„ Limited to capabilities of smallest domain member
„„ Star topology (also known as hub-and-spoke)
„„ Issues with dynamic addressing
„„ Concentrates load on hub devices
„„ Existing proprietary approaches
„„ No interoperability between Juniper Networks AC-VPN, Cisco
DMVPN, or HP DVPN
 Chapter 2: A Standards-based Approach 19

Gateway and Endpoint Requirements

These are the gateway and endpoint requirements coming out of the
committee:
„„ Minimize hub configuration changes when gateways/clients added
to VPN
„„ No configuration changes required on peers for direct connection
„„ Support for routing protocols
„„ Direct communication for full-mesh and dynamic full-mesh only
„„ A compromised peer must not affect the security of unrelated peers
„„ Gateways to support seamless handoff of sessions to clients
„„ Gateways to support seamless handoff of sessions to gateways
„„ Gateway and client support for NAT scenarios
„„ New IPsec SAS reportable and manageable
„„ Support for a federated model across operator boundaries (connec-
tions are made between organizations with different administrative
boundaries yet require integrated communications)
„„ Support for full-mesh, partial-mesh, and star topologies
„„ Scale for multicast support
„„ Support for easy monitoring, logging, and reporting
„„ Support for Layer 3 VPNs over IPsec tunnels
„„ Support of per-peer class of service in star and full-mesh topologies
„„ Hub cannot be a single point of failure

Solution Status
Several competing solutions to the ADVPN problem statement were
submitted to the IETF IPsec IPSECME Work Group for consideration.
No agreement was ultimately reached on which solution to take forward
as the formal IETF standard, leaving the various teams of authors the
option to publish as Informational RFCs.
This is the intended path that Juniper and co-authors from Check Point,
Orange (France Telecom), and the European Center for Information and
Communication Technologies (EICT) intend to take.
However, in the name of full disclosure, the current document is not an
IETF-approved Standards Track RFC.
 20 Day One: ADVPN Design and Implementation

Future ADVPN Developments

There are some major developments planned for the ADVPN feature
in the near future that will make it even more open and scalable.
The current implementation of ADVPN uses OSPF to propagate routes
throughout the ADVPN domain. The employment of a dynamic
routing protocol is important in the overall usability of the feature as
the resulting routes can be used to select traffic for protection by the
IPsec protocol. This greatly simplifies adds, moves, and changes to the
network as these modifications can occur without reference to the
IPsec parameters – providing a high degree of flexibility.
Dynamic routing in the SRX IPsec context does suffer from two major
downsides – a proprietary implementation over point-to-multipoint
interfaces and scalability issues when the number of nodes grows very
large.
The proprietary implementation issue is because the SRX utilizes a
proprietary payload called Next-Hop Tunnel Binding (NHTB) to
propagate interface information between SRX devices, and this is
required to run OSPF over the point-to-multipoint interface. The
result is that third party support is not possible when ADVPN is used
with OSPF.
The scalability issue is because the SRX uses OSPF for the initial
propagation of routes from spoke to hub (and vice versa), as well as for
the preferential selection of the spoke-to-spoke routes. In this context,
the scalability of the solution is effectively the scalability of the OSPF
protocol. The solution has been qualified at 512 nodes per ADVPN
domain. If there are requirements for larger scale, then an alternative
to OSPF needs to be utilized.
To address both the proprietary implementation issue and the scaling
issue, the Junos ADVPN will be enhanced to support traffic selectors as
the means of prefix propagation. Traffic selectors are proposed by the
peer on the control connection (from spoke to hub) and accepted into
the route table via a feature called auto route insertion, or ARI. When
shortcuts are required between spokes, the hub will provide the traffic
selectors to ADVPN partners and they will instantiate that these are
routes to prefer the spoke-to-spoke route over the already established
spoke-to-hub route.
Finally, note that the Junos AutoVPN feature currently supports IPv4
addressing. AutoVPN will be enhanced to support IPv6 and this will
include the ADVPN capability in a future release.
Chapter 3

ADVPN Key Concepts

The majority of ADVPN operations are in the control plane. Data

plane functions such as tunnels, encryption algorithms, and how
packets are encrypted and decrypted on the Juniper SRX platform in
the same way they have been for many years now. The additional
ADVPN control plane concepts can be narrowed down to three items:
„„ Shortcut Suggester
„„ Shortcut Partner
„„ Identity Management

Shortcut Suggester
The role of the suggester SRX, as the names implies, is to tell its peers
of a potential peer-to-peer relationship that can be formed, so the
suggester does not need to be involved in a flow. The message sent
from the suggester to the partner is called a shortcut exchange. How
does this work? A suggester is looking at transit flows – where the
flow has an ingress IPsec tunnel and an egress IPsec tunnel and both
IPsec tunnels have formed with ADVPN-capable peers. It should be
noted the suggester is only looking at flows that transit the SRX itself
– the SRX has no concept of the rest of the network topology. This
becomes an important factor in network design, something that is
covered a little later in this book. Once the suggester tells its peers of
the potential peer-to-peer relationship via the shortcut exchange, and
receives acknowledgement of the exchange, the function of the
suggester is complete.

NOTE For a shortcut to be initiated, the suggester needs to have peer rela-
tionships with the partner nodes. Hence a suggester is likely to be a
core/ hub node in the network. In many network scenarios, the
Suggester SRX will have a peer relationship with all Partner SRXs.
 22 Day One: ADVPN Design and Implementation

Shortcut Partner
The role of the Partner SRX is to listen for short exchange messages that
are sent from the suggester. Based on the Partner SRX’s local policy, it
will decide whether to take any action on this message. Assuming local
policy is met, the partner will take the information contained in the
message and form an IKE association, then an IPsec association to the
other partner peer, as outlined in the shortcut message. The partner
function continues to monitor any shortcut tunnels being created by this
method, and by policy, will tear down a tunnel when it is no longer
needed.

NOTE A partner is likely to be at the edge of the network, with static IKE/IPsec
security associations to at least one suggester node in the network.

Identity Management
The nature of ADVPN means new relationships are created on an
as-needed basis. How can each SRX trust that the dynamic peer SRX is
a node it is willing to form a relationship with? The number of potential
relationships is a n*(n-1)/2 function. As n grows beyond even a rela-
tively small number, the relationship count starts to become very large.
Fortunately, this problem was solved long ago using Public Key Infra-
structure (PKI). The draft response to RFC 7018 includes a Pre-Shared
Keys (PSK) scenario, but PSK is not implemented in the first instance of
ADVPN capabilities in the SRX. This is due to the additional infrastruc-
ture that would be required to make such a solution work (while
avoiding the undesirable approach of using a single PSK for the entire
network, making the implementation inherently unsecure). For this
reason, Identity Management in the SRX implementation requires the
use of PKI.

A Functioning Solution – Dividing the Problem in Two

Having outlined the major concepts of ADVPN, how does it come
together? As described in the draft response to RFC 7018, ADVPN is
solving the problem of how to signal in an auto discovery environment,
while keeping the environment as simple and dynamic as possible.
It soon became obvious that signaling was one key piece of the solution.
But to have a functional network once new paths are established, the
SRX needs an ability to be able to use those paths. The authors of the
draft response to RFC 7018 felt that this problem should be solved using
traditional routing protocols or explicit traffic selector definition and
hence be covered by other RFCs. In this Day One book, both are
covered.
 Chapter 3: ADVPN Key Concepts 23

IKEv2 for Signaling

As IPsec implementations have matured, the need to rectify problems in
the first implementation of IKE became pressing. The original IKE
protocol was very chatty in nature, had no standard way of handling
NAT traversal, and could not support EAP as an authentication method,
among other limitations. IKEv2 was created to solve such deficiencies.
Most modern communication protocols are designed so they are
extensible, allowing for additions to be made without a wholesale
change in the protocol, which is the same for IKEv2. ADVPN takes
advantage of IKEv2’s extensibility.

Capability Exchange
As part of the initial IKEv2 exchange, ADVPN-capable SRXs advertise
their ADVPN capabilities. The messages format is as follows:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !C!  RESERVED   !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Protocol ID  !   SPI Size    ! ADVPN Supported Message Type  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Capabilities ...                                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The capabilities can include a shortcut suggester and a shortcut partner.

It is important to note that during the IKE capabilities exchange, if the
SRX does not advertise ADVPN capability, no additional ADVPN
message processing will take place. This ensures interoperability
between ADVPN and non-ADVPN capable nodes, as non-ADVPN
nodes will not be expecting to receive ADVPN messages. Other capa-
bilities outlined in the RFC standard (Trusted Suggester, and fully
qualified domain name [FQDN] resolver) are not implemented in the
first phase of ADVPN.

Shortcut Exchange
Once a suggester node has decided there is a peer-to-peer relationship
that can be formed to optimize the network, the partner peer is informed
via a shortcut message. When this exchange is initiated, the partner acts
as a RFC 5996 responder. The format of the exchange is as follows:
HDR, SK {IDa, ADVPN_INFO, IDi,
IDr[, TSi][, TSr][, VID]} -->
<== HDR, SK {N(ADVPN_STATUS)}
 24 Day One: ADVPN Design and Implementation

The suggester expects that the shortcut request sent to the Partner will
be acknowledged.
IDa is a specific ADPVN informational element that contains the IP
address or FQDN of the peer gateway. While the address information
could have been derived from the underlying streams, this would not
have allowed for sending the FQDN. By having this specific informa-
tion element, there is complete flexibility in how to identify the partner.
The ADVPN_INFO information element provides specific information
related to the shortcut:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !C!  RESERVED   !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                        SHORTCUT Identifier                    !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Lifetime                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! R | Reserved  |  PSK Length   |          Peer Port            !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~               Pre-Shared Key (variable length)                ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              Peer Description (variable length)               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The key information sent to the partners includes:

1. Lifetime: Length of time for which the security association should
be established.
2. Peer Port: Used to indicate that the peer node you will be talking
to is behind a NAT device, and what port should be used to establish
communications.
3. Role: What the peer will do on receiving this shortcut message.
The suggester decides one peer should initiate the shortcut
connection, and the other peer should respond to the connection.
The initiator is responsible for starting the IKEv2 session, while the
responder waits for the initiator to establish the connection.
4. Pre-Shared Key: A mechanism to distribute pre-shared keys to
each of the peers. As mentioned earlier in the first implementation of
ADVPN on SRX, this option is not available.
5. Peer Description: This is used for logging and debugging
purposes.
 Chapter 3: ADVPN Key Concepts 25

The IDi (IKE Initiator) and IDr (IKE responder) and TSi (traffic
selector initiator) and TSr (traffic selector responder) parameters are
the same as what would be used in a non-ADPVN IKEv2 exchange.
Finally, once the data element has been sent, a status message from the
partner is used to ascertain what the partner has done with the short-
cut request.
                    1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !C!  RESERVED   !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Protocol ID  !   SPI Size    !  ADVPN Status Message Type    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SHORTCUT Identifier                    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !F|C|E|    Reserved             |            RCODE              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                           Timeout                             !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields corresponding to the first four octets are defined (as de-
scribed) in RFC 5996; the remaining fields are defined as follows:
„„ Protocol ID (1 octet) must be zero, as specified in RFC 5996.
„„ SPI Size (1 octet) must be zero, in conformance with RFC 5996.
„„ ADVPN Status Message Type (2 octets) SHORTCUT Identifier -
the 32-bit field from the SHORTCUT_INFO notification.
„„ F (1 bit) - Fatal. Set if this notification means that the SHORT-
CUT no longer exists.
„„ C (1 bit) - Critical. Set if the peer must understand this RCODE,
or else delete the shortcut if the F bit is not set.
„„ E (1 bit) - Error. Indicates an error condition (rather than a policy
change).
„„ RCODE (2 octets) - a 16-bit result code field described below.
„„ Timeout - this 32-bit field indicates the maximum number of
seconds that the shortcut service is not available by the peer.
There are two possible RCODES that are sent in the status message:

Value Description

0 SHORTCUT_ACK

3 TEMPORARILY_DISABLING_SHORTCUT
 26 Day One: ADVPN Design and Implementation

Note that only a subset of messages has been implemented from the draft
standard. If the partner accepts the shortcut suggestion, an RCODE of 0
will be returned. If the partner rejects the shortcut suggestion, an RCODE
of 3 will be returned.

Traditional Routing for Reachability

Once the SRX has created new network paths by acting on shortcut sugges-
tions, the SRX needs a mechanism to use these new paths. Two possible
solutions (without deploying any new proprietary mechanisms) are:
„„ Use an existing routing protocol, or
„„ Use IPsec traffic selectors.
In the first phase of SRX ADVPN deployment, using an existing routing
protocol, such as OSPF, is required. Naturally, the first concern is the
scalability of the solution, and in subsequent chapters of this book scalabil-
ity will be addressed by specific OSPF mechanisms that can be used to aid in
scale or by network design to scale out the solution. One advantage of
using OSPF is its neighbor discovery mechanism, which will aid in the
simplification of configuration.

NOTE In subsequent releases of SRX ADVPN, it will be possible to configure

traffic selectors on each of the IKE gateway definitions. During IKE ex-
change, the traffic selectors are exchanged, and, using reverse route injec-
tion (effectively inserting static routes automatically), reachability informa-
tion is updated.

Summary
ADVPN is an extension to the IPsec control plane made possible by the
extensibility of IKEv2. SRX gateways can take on the role of a suggester,
that is, they can create shortcut suggestions to hint at new IPsec tunnels to
optimize traffic flow. SRX gateways can take on the role of partners, which
is to listen out for shortcut suggestions and create a new IPsec tunnel,
assuming local policy is met. Identity in an ADVPN network is solved using
PKI. Network reachability will be managed using the OSPF routing proto-
col.
Now that the architecture of ADVPN has been covered and how it works
from a protocol perspective, Chapter 4 will cover the key configuration
steps.
Chapter 4

Key Configuration Steps

ADVPN builds on the configuration of a previous phase of SRX

AutoVPN functionality – Zero Touch Hub. The seven configuration
steps are:
1. Generate local X.509 certificate(s) and get the certificate(s) enrolled
and signed by the Certificate Authority (CA). A fully worked example
is included with the Microsoft CA later in this book. An alternative
lab-only CA using Open SSL as an offline CA is also discussed in the
appendices of this book.
2. Create the IKE proposal to use certificates, authentication, and
encryption as per your organization’s security policy, or choose one of
the predefined phase 1 proposal-sets.
3. Create the IKE policy/policies that bind the proposal and local
certificates.
4. Create the IKE gateway definition where all the specific ADVPN
configuration work gets done.
5. Create the IPsec proposal or decide which predefined phase 2
proposal set to use.
6. Create the IPsec policy linking to the IPsec proposal or proposal set.
7. Create the IPsec VPN binding the IPsec policy and respective IKE
gateway definition.
 28 Day One: ADVPN Design and Implementation

The proposal and policy configurations for both the suggester and
partner should be very similar. What differences there are, are in the
configuration center on the IKE gateway and the IPsec VPN defini-
tions. As you will read in the subsequent sections of this chapter,
enabling ADVPN is straightforward if the requisite configuration is
already in place.
Let’s start the real work of this book by working through the configu-
ration of a suggester and partner. Because AutoVPN Zero Touch Hub
configurations are a relatively new Juniper configuration concept, an
overview of what they require is covered as well.

Suggester Configuration
Let’s start with an IKE proposal and policy:
policy ikepol-advpn {
certificate {
local-certificate srx550-1;
}
proposal-set suiteb-gcm-256;
}

You can see that in this example a local certificate srx550-1 has been
created and the built-in proposal-set suiteb-gcm-256 has been
referenced. The certificate generated must be capable of being used
with the ciphers selected. Hence certificate srx550-1 is an Elliptic
Curve (ECDSA) certificate with a size of 384 bits, using SHA384 as a
hash.
Now let’s look at the IKE gateway definition:
gateway hub-gw {
ike-policy ikepol-advpn;
dynamic {
distinguished-name {
wildcard ST=ACT,O=Juniper;
}
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
advpn {
partner {
disable;
}
}
version v2-only;
}
 Chapter 4: Key Configuration Steps 29

Here the IKE gateway definition binds the policy to gateway, and the next
stanza is the dynamic hierarchy. This configuration was first introduced
with AutoVPN Zero Touch Hub in Junos 12.1X44, allowing the SRX to
accept dynamic neighbors, and in this case, it’s looking for a wildcard
match in the certificate subject line of ST=ACT,O=Juniper of the IKE peer.
The local-identity that is used is the certificate name as bound by the
IKE policy. The external-interface is the interface the SRX will listen
on for incoming IKE requests. Up to this point, the configuration is
exactly as per a Zero Touch Hub configuration. Finally, the ADVPN
configuration is set and the Partner function is disabled – this signals that
the suggester function is enabled. The configuration ends with the
IKEv2-only designation that must be used for ADVPN operation.
Once the IKE configuration is complete, let’s turn to the IPsec configura-
tion. First, create the policies:
policy standard {
proposal-set suiteb-gcm-256;
}

Now let’s build the VPN definition for this particular gateway, which is
no different than any other SRX IPsec configuration:
vpn advpn {
bind-interface st0.0;
ike {
gateway hub-gw;
ipsec-policy standard;
}

This process can be repeated for additional suggester functions if you are
running routing instances in the SRX to create separate WAN domains
that function completely independently of each other. It’s particularly
useful when separation functions need to be stronger than simply routing
instance separation – a common requirement for security conscious
customers. In order to follow best practices, different certificates should
be created for each routing instance and the subject should be distinct so
accidental misconfiguration does not join the two security domains. An
example of this architecture is discussed in more detail in Chapter 9,
Architectural Blueprints.
 30 Day One: ADVPN Design and Implementation

Partner Configuration
Let’s look at the IKE proposal and policy:
policy ikepol-advpn {
certificate {
local-certificate srx550-2;
}
proposal-set suiteb-gcm-256;
}

It’s exactly the same as at the suggester end, though the certificate, of
course, is created for this particular SRX. Now let’s look at the IKE
gateway definition:
gateway advpn-hub {
ike-policy ikepol-advpn;
address 192.168.66.1;
local-identity distinguished-name;
remote-identity distinguished-name container
ST=ACT,O=Juniper;
external-interface ge-0/0/0.0;
advpn {
suggester {
disable;
}
partner {
connection-limit 10;
idle-time 60;
idle-threshold 10;
}
}
version v2-only;
}

You can see that you start with binding the policy to the gateway and
set the IP address of the suggester. The identity of the SRX is set to the
distinguished-name in the local certificate. When this partner SRX
creates a session to the suggester SRX, the partner SRX will be looking
for the suggester SRX certificate to have a part of the subject be
ST=ACT,O=Juniper. The external interface is the interface from which
the IKE sessions will be sourced. So far, this is a standard IKE gateway
configuration using certificates. The ADVPN partner definition is
next. Because this is an ADVPN partner configuration, the ADVPN
suggester function needs to be explicitly disabled.
 Chapter 4: Key Configuration Steps 31

Under the partner stanza, there are three possible options. These
options control how many outbound shortcut security associations to
allow from the SRX, and the traffic characteristics that control when
shortcut security associations are torn down.

NOTE All three options have defaults and if you are happy with these defaults
there is no need to configure them.

The connection limit imposes a limit on how many shortcuts this

partner will be a part of. The use case for this parameter is to limit the
number of sessions in line with the number of sessions a particular
SRX model can sustain – a topic covered in Chapter 5.
This configuration parameter can also be used as a protection mecha-
nism; a potential vulnerability of any dynamic VPN solution is a
Denial of Service (DoS) attack launched by inserting traffic into the
network with the malicious intention of overwhelming the control
plane. In terms of traffic volume this style of attack can be very low in
nature, but by the nature of the traffic flows, wide spread ADVPN
shortcut suggestions could be triggered. Even with SRX separation of
control plane and data plane, which in many instances negates the
effects of such an attack, it is still a security threat that customers
should guard against. Fortunately, the SRX has many other features
that can be used to allow or deny traffic and implicitly allow or deny
traffic that may create ADPVN shortcut suggestions; this will be
covered in Chapter 5.
Back to the configuration, the idle parameters allow tunnels to be torn
down when they are not servicing traffic, either with an absolute idle
timer (no traffic for a given number of seconds), or when traffic falls
below a specified packets per second (pps) threshold.
Now let’s build the VPN definition for this particular gateway. This is
no different than any SRX IPsec configuration:
policy standard {
proposal-set suiteb-gcm-256;
}

vpn spoke {
bind-interface st0.0;
ike {
gateway advpn-hub;
ipsec-policy standard;
}
establish-tunnels immediately;
}
 32 Day One: ADVPN Design and Implementation

It is possible to configure a single SRX with both the suggester and

partner configuration. In the first release of ADVPN in Junos
12.3X48, this can only be configured when using separate IKE gate-
way definitions, and when doing this, traffic will need to flow through
this node from an IPsec perspective when crossing from the suggester
configuration to the partner configuration and vice versa.

NOTE Attempting to configure both ADVPN suggester and partner functions

on the same IKE gateway will result in a commit error.

NOTE In subsequent releases of Junos for the SRX, the ADVPN suggester and
partner functions will be able to operate on the same IKE gateway
definition, allowing for many possible cross domain examples (as
outlined in the draft response to RFC 7018) to be implemented.

Routing Protocols
The first implementations of ADVPN will require the configuration of
dynamic protocols in order to use the additional paths that are created
once the Partner SRXs have established a shortcut tunnel. The sup-
ported protocol is OSPF. Subsequent releases of ADVPN are planned
to use a traffic selector configuration. Depending on your perspective,
if you want the most automatic and least configuration effort avail-
able, then choosing a dynamic routing protocol is the preferred path.
Take a step back for a moment. The problem to solve is how to
configure a routing protocol where interfaces are dynamic and can
appear or disappear at any stage. If you think about it, that problem is
very similar to backup scenarios from network designs in years past.
The same principles used then are readily used again today and the
routing protocol needs to be able to cater to these dynamic characteris-
tics.
For an OSPF configuration, this is achieved by tailoring the character-
istics of the st0.0 interface, an example shown here:
ospf {
area 0.0.0.0 {
interface st0.0 {
interface-type p2mp;
demand-circuit;
dynamic-neighbors;
}
}
}
 Chapter 4: Key Configuration Steps 33

There are three key configuration stanzas in an ADVPN environment

in OSPF.
„„ The first is to set the interface type to Point-to-Multipoint (p2mp).
From the IPsec interface perspective st0.0 is a single interface that
will have a number of tunnels associated with it, all with their
own IPsec security association. Next Hop Tunnel Binding in this
environment will identify the IP address at the other end of the
protected tunnel. This IP address will be used to create an OSPF
adjacency with the remote SRX.
„„ The second stanza sets the interface to operate in demand-circuit
mode, as defined in RFC 1793. This changes OSPF keep-alive
behavior for the IPsec interface. Once the OSPF database
synchronization is complete, OSPF Hello packets and OSPF Link
State Advertisement (LSA) packets are suppressed. To ensure
LSAs do not time out in these environments, they are advertised
with the DoNotAge bit set. LSAs and OSPF Hellos are then only
sent when there is a topology change. What constitutes a change
in topology in an ADVPN environment? Simply the creation and
tear down of dynamic IPsec tunnels in response to shortcut
suggestions being sent, or the partner deciding that the connec-
tion is no longer required. Additional methods for speeding up
network convergence are discussed later in this book.
„„ Finally, in the third stanza, the dynamic-neighbors keyword is
required. This informs OSPF that it should expect to see neigh-
bor adjacencies come and go as the ADVPN suggester and
partner functions communicate on the st0 interface.

Summary
ADVPN configuration builds on existing SRX IPsec configuration. For
users converting from an existing AutoVPN configuration, the addi-
tions are minimal. ADVPN functions of suggester or partner are
defined in the IKE gateway stanzas of configuration. OSPF configura-
tion will require some tuning to cater to the dynamic nature of AD-
VPN with tunnels being added and removed from the network.
As simple as the ADVPN configuration is, Chapter 5 will cover the
tuning considerations of deploying ADVPN – like all network designs
there are a multitude of factors to consider.
 34 Day One: ADVPN Design and Implementation
Chapter 5

Tuning Considerations for ADVPN

From the smallest branch office device to the largest core/data center
SRX Series, the SRX family has considerable capabilities. The AD-
VPN feature is supported on all SRX platforms as partner roles.
Support for the branch SRX came in 12.3X48-D10, while support for
the HE SRX will be introduced in Junos 12.3X48-D20. The ADVPN
Suggester function is only supported on the SRX240 and above models
(due to the extra control plane processing that is required for the
function to operate successfully).

Choosing the SRX Series Model

Deciding which device is appropriate, from a scaling point of view,
needs to be considered from two perspectives.
First it’s necessary to consider the number of sessions the SRX is
required to peer with. For the suggester function, this decision should
be straightforward, as the first cut calculation should be the total
number of partner nodes in the network. For the partner function, you
should calculate using the number of traffic flows in the network – for
instance, if ADVPN is being deployed over an existing network and
applications flows are not changing, then this information could be
derived from J-Flow records. If the use case is to enable voice RTP
packets as the dominant shortcut traffic type, the base information
should be available from your organization’s voice team, in terms of
the number of site-to-site calls. The calculation becomes more interest-
ing in relation to how the tunnels operate in the data network imple-
mentation, and this is discussed in a later section of this chapter.
 36 Day One: ADVPN Design and Implementation

Table 5.1 below shows the supported number of tunnels for each SRX
model when acting in suggester or partner roles.
Table 5.1 Choosing a SRX Series Device for ADVPN

SRX Platforms Partner Suggester

SRX100 32 N/A

SRX110 32 N/A

SRX210 64 N/A

SRX220 64 N/A

SRX240 128 128

SRX550 256 256

SRX650 512 512

SRX1400 512* 512

SRX3000 512* 512

SRX5000 512* 512

* Supported from Junos 12.3X48-D20.

Second, it’s necessary to think about the encryption throughput

required for the device. Like any IPsec implementation, it is important
to understand the traffic profile - that is, the distribution of the size of
packets and the total number of packets per second to be processed.
Transitioning from a hierarchical design or a partial-mesh design, you
should observe that the SRX devices at the aggregation points in your
network have the IPsec processing load removed from them once
ADVPN is deployed.
Implementing ADVPN at the same time as making significant changes
to applications running on the network (often the case in business
transformation projects) should be approached cautiously. For
example, a new implementation of VoIP in a WAN will dramatically
change the mix of packet sizes in the network. A single G.711 voice
stream, using standard 20ms voice payload with RTP encoding, adds
fifty packets per second in each direction, and each IP packet’s length is
200 bytes before IPsec encapsulation. Careful planning is advised to
ensure the appropriate SRX device is chosen to match the required
throughput.
Table 5.2 contains the IPsec encryption/decryption capabilities for each
model when measured with the IMIX traffic profile.
 Chapter 5: Tuning Considerations for ADVPN 37

Table 5.2 IPsec Capabilities for SRX Series Devices as Measured With an IMIX Traffic Profile

Platform IMIX

SRX100 25 Mbps

SRX110 29 Mbps

SRX210 29 Mbps

SRX220 33 Mbps

SRX240 100 Mbps

SRX550 330 Mbps

SRX650 460 Mbps

SRX1400/3000 SPU 700 Mbps

SRX5x00 (1st gen SPU) 700 Mbps

SRX5x00 (2nd gen SPU) 1400 Mbps

Note that the throughput rates listed in Table 5.2 do not take into
consideration the performance impact of other enabled features. If
additional services are enabled on these platforms, the throughput
numbers can reduce as additional service processing takes away from the
encryption/decryption performance.
Another point to make about Table 5.2 is that there are two models of
SPCs for the SRX5000 platform. For the original (first generation) SPC,
there are two SPUs on each card. For the second generation SPC, there
are four SPUs on each card, and each SPU is approximately twice as
powerful as a first generation SPU. The numbers quoted in Table 5.2 are
per SPU. Also note that on SRX1000, SRX3000, and SRX5000 plat-
forms, the first SPU is used for the Central Point (CP) housekeeping
function; this will reduce the encryption/decryption capability of the SPU
that is performing the CP function.

IP Addressing
From a reachability point of view, ADVPN essentially flattens the
network. The effect of ADVPN is to put all other nodes, and hence
branch offices or locations, one hop away from one another. It may seem
that addressing schemes, which are often based on hierarchy or geogra-
phy to achieve easy address summarization, don’t matter as much in
these environments. But IP addressing schemes are still valid in an
ADVPN domain, it’s just that how you go about carving up the address
space should be thought of a little differently.
 38 Day One: ADVPN Design and Implementation

The concept of application reachability makes sense from a supernetting

point of view. For example, an enterprise has five data processing sites,
and the branch offices are allowed to send and receive any application
type from the data processing sites – a very permissive model. However
the branch sites can only send and receive voice traffic and CIFS traffic
directly to other branch sites – a fairly restrictive model. IP address
allocation based on application flows makes rule generation and mainte-
nance simple. All partner sites are represented by one supernet, and all
processing sites are represented by another supernet.

IGP Metrics
Fine-tuning of OSPF metrics is required in an ADVPN environment to
ensure that traffic flows through a suggester node when the IPsec tunnel
is not a shortcut peer. This is important for two reasons. The first is that
additional shortcut tunnels cannot be created if the traffic does not flow
through a SRX with the suggester function enabled. The second is that
partner nodes may not be sized either by SRX capacity, or bandwidth, or
both, to that site to perform any transit IPsec functions.
To illustrate this point, let’s take the following simple network of one
suggester and three partner SRX nodes.

Figure 5.1 Topology of Fine-tuning OSPF Example

By default, the cost of a st0 interface is 1. Each partner has a control

tunnel to the suggester. As traffic flows, Partner 1 and Partner 2 have
created a shortcut tunnel between each other, and Partner 2 and Partner 3
have created a shortcut tunnel between each other. The problem arises if
traffic from Partner 1 starts to flow to Partner 3. From Partner 1’s
 Chapter 5: Tuning Considerations for ADVPN 39

perspective, there are two paths available, P1-S-P3 and P1-P2-P3.

With default OSPF costs, each path is equal and it would be legitimate
for Partner 1 to choose the path P1-P2-P3. The same would also be
true for Partner 3, and it would also be legitimate to choose the path
P3-P2-P1.
OSPF costs need to be differentiated by suggester and partner, and
potentially suggester-to-suggester, if multiple suggester nodes are
provisioned in the network.
Using the example in Figure 5.1, network paths that go through a part-
ner node must have a higher cost than network paths that go through a
suggester. This forces traffic to go via a suggested path where there
isn’t a direct shortcut. Using the example in Figure 5.1, the OSPF cost
of the st0 interface on each partner is configured to be 2. The OSPF
cost for network path P1-S-P3 is now 3 and the OSPF cost for network
path P1-P2-P3 is now 4. Traffic now flows through the suggester, and
assuming policy is met, a shortcut is built directory from Partner 1 to
Partner 3.
Many ADPVN deployments have multiple suggester nodes provi-
sioned to provide high availability. To keep the network as simple as
possible and to help with management and troubleshooting, a sug-
gester should be designated as the primary suggester. Other suggesters
assume the role of secondary and tertiary suggesters, if that level of
availability is called for.
To illustrate the multiple-suggester concept, let’s take the example
shown in Figure 5.2 of two suggesters and three partner SRX nodes.

Figure 5.2 Use Case for Multiple Suggesters

 40 Day One: ADVPN Design and Implementation

You can see that in terms of the metrics there are two formulas in play.
The partner SRX nodes’ metric must be higher than either of the sug-
gester nodes. The primary suggester node’s metric must be lower than
the secondary suggester node. It sounds pretty simple that Suggester 1, as
the designated primary suggester, is configured with a metric of 1,
Suggester 2 as the secondary suggester is configured with a metric of 2,
and the partner SRXs are all configured with a value of 3. The paths
available, with their associated metrics, from Partner 1 to Partner 3,
would then be:
„„ P1-S1-P3 = 4
„„ P1-S2-P3 = 5
„„ P1-P2-P3 = 6
These metrics work, but they don’t take into account operational or
maintenance needs in case mistakes or other events happen during
change windows. For example, let’s say Suggester 1 requires mainte-
nance and needs to be taken offline. To minimize the disruption to the
rest of the network, the st.0 OSPF metric is changed from 1 to 3 at the
first step of the maintenance window. This effectively promotes Sug-
gester 2 to the role of the primary suggester as that SRX will have the
lowest metric. The network converges by active signaling rather than a
box simply disappearing from the OSPF domain, so now:
„„ P1-S1-P3 = 6
„„ P1-S2-P3 = 5
„„ P1-P2-P3 = 6
Now, let’s say just by chance that Suggester 2 has had a loss of WAN
connectivity before Suggester 1’s maintenance takes the SRX offline.
This now leads to the following metrics being active in the network:
„„ P1-S1-P3 = 6
„„ P1-P2-P3 = 6
As discussed earlier, this can lead to some undesirable results. To work
around the problem, a gap between suggester metrics and partner metrics
can be reserved for maintenance. Reworking this example, the primary
suggester gets a value of 1, the secondary suggester gets a value of 2, the
metric 3 is reserved, and the partner SRXs have a metric value of 4. In
steady state, this leads to the following metrics per the last example:
„„ P1-S1-P3 = 5
„„ P1-S2-P3 = 6
„„ P1-P2-P3 = 8
 Chapter 5: Tuning Considerations for ADVPN 41

The maintenance window begins as Suggester 2, is elevated to primary

status, and given Suggester 1’s metric a value of 3:
„„ P1-S1-P3 = 7
„„ P1-S2-P3 = 6
„„ P1-P2-P3 = 8
If there is a repeat of Suggester 2 having an outage while working on
Suggester 1, then Suggester 1 can continue on performing as expected
without having to roll back any changes:
„„ P1-S1-P3 = 7
„„ P1-P2-P3 = 8
Below is an example of configuring OSPF metrics on the st0 interface:
[email protected]> show configuration protocols ospf
area 0.0.0.0 {
interface st0.0 {
interface-type p2mp;
metric 8;
demand-circuit;
dynamic-neighbors;
}
}

IGP Loop Free Alternative

In an ADVPN environment there will be many feasible paths by which
traffic can flow, as discussed in the previous section. Loop Free Alterna-
tive (LFA) is a method to allow the next feasible path to be calculated by
the IGP and then installed as a backup route in the forwarding table.
When the primary link fails, the next feasible path is installed as the
route, without waiting for the IGP to converge. This can help in
minimizing disruptions to connectivity when link states change in the
network.
For a path to be eligible as a next feasible path, it must not share the
underlying IP interface as known by the IGP. In an ADVPN network
this is the st0 interface. This is due to a characteristic of LFA where
outbound interfaces share the same fate – that is, if one IPsec security
association breaks, then it’s deemed that all IPsec security associations
are broken for that instance of a st0 interface. For physical interfaces,
this behavior makes perfect sense, however for st0 interfaces, being a
logical interface, it’s not ideal. As a result, LFA only makes sense in an
ADVPN network when there are dual clouds and hence dual st0
interfaces from an ADVPN partner perspective. This is covered in more
detail in Chapter 9: Architectural Blueprints.
 42 Day One: ADVPN Design and Implementation

There are two actions that need to be configured when enabling LFA:
1. Tell the IGP to calculate a LFA, by nominating which interfaces are
to be protected.
2. Have the forwarding table reflect the backup routes.
For OSPF’s configuration of LFA, the key word link-protection needs
to be added to the configuration:
root@vSRXB1> show configuration protocols ospf
area 0.0.0.0 {
interface st0.0 {
interface-type p2mp;
link-protection;
metric 100;
demand-circuit;
dynamic-neighbors;
}
interface st0.10 {
interface-type p2mp;
link-protection;
metric 101;
demand-circuit;
dynamic-neighbors;
}
}

As mentioned earlier in this chapter, for LFA to make sense there needs
to be two distinct IP interfaces that are eligible for link protection.
The second item to configure is getting the forwarding table to reflect
the routes as calculated by OSPF. This involves creating a policy and
setting the policy to load-balance on a per-packet basis. The per-pack-
et keyword, harks back to older Juniper routing platforms, when it
was actually possible to forward traffic on a packet-by-packet basis.
Traffic forwarding today is on a flow basis, but the old per-packet
keyword remains. The configuration below creates a policy named
ecmp with the load-balance statement:

root@vSRXB1> show configuration policy-options

policy-statement ecmp {
term 1 {
then {
load-balance per-packet;
}
}
}

Now let’s get the RIB to be exported to the forwarding table based on
the policy that has just been created. The following configuration
creates a forwarding table with the loop free alternate routes in the
forwarding table:
 Chapter 5: Tuning Considerations for ADVPN 43

root@vSRXB1> show configuration routing-options

forwarding-table {
export ecmp;
}

To verify that the loop free alternate routes are now part of the for-
warding table, a show route is performed. In this example the specific
route 10.1.12.1/32 is reachable via st0.0 as the primary path and via
st0.10 as the secondary path:
root@vSRXB1> show route 10.1.2.12

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

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

10.1.2.12/32 *[OSPF/10] 00:00:45, metric 190

> to 10.1.1.1 via st0.0
to 10.1.2.2 via st0.10

SRX Session Flow Management

At the heart of SRX packet forwarding is a concept called flow. A flow
is simply a traffic stream from a socket address on one IP endpoint
communicating to a socket address on another IP endpoint, traversing
interfaces on the SRX. By default the SRX flow management takes on
the posture of being a firewall, meaning the SRX must see the entire
connection to allow traffic to flow.
In an ADVPN environment, this may not always be the case, for
example, as in when a SSH session is flowing between two ADVPN
partner nodes (P1 and P2) and a shortcut tunnel has been established.
There are two suggester functions in the network (S1 and S2). The first
suggester is taken offline and the shortcut tunnel has just been torn
down due to an inactivity timer being triggered. At this stage, routing
converges as the IGP function completes and the path is now P1-S2-P2.
The second suggester node has no ability to see any of the previous
sessions, but there is still an active SSH session. The user tries to
continue their session, but finds the session is non-responsive. The
reason for this is traffic is now flowing through S2 and there is no
active flow session. No flow session will be built because the SRX is
looking for the TCP-SYN sequence to establish the bona fides of the
session and create a flow, the very basics of a firewall. In addition, the
SRX also ensure DNS replies and embedded ICMP replies have
matching initiation requests. When the ADVPN network is in transi-
tion, that is, when it has tunnels coming up or down, it can lead to
DNS or traceroutes not working correctly during those transitions.
 44 Day One: ADVPN Design and Implementation

This default behavior can be overridden to allow TCP sessions that are
in mid-session to be eligible to create a SRX flow, as well as a DNS
reply and embedded ICMP replies. The configuration is as follows:
admin@srx650-02> show configuration security flow
allow-dns-reply;
allow-embedded-icmp;
tcp-session {
    no-syn-check;
    no-syn-check-in-tunnel;
    no-sequence-check;
} 

WAN Transport
One of the significant advantages of ADVPN over Group VPN (RFC
6407) is the wider choice of WAN transport. In Group VPN, the
protected IP addresses must be routable across the WAN, as that is the
encapsulation method for that VPN technology. This almost always
means the transport must be a private WAN. ADVPN imposes no such
restriction because the encapsulation used hides the protected tunnel
addresses, allowing ADVPN to use the Internet as a transport.
As discussed in Chapter 3: ADVPN Key Concepts, ADVPN also has
the ability to traverse NATs. The following condition must be met,
however, for a shortcut session to be initiated: of the two partners, only
one of them can be behind a NAT in the network, not both. In such a
scenario, the shortcut suggester picks the SRX partner node behind the
NAT to be the shortcut initiator, which makes sense because it allows
an additional NAT to be built as the traffic is initiated from the inside
interface of the NAT device. If both partner nodes are behind NATs,
the shortcut suggester will not send a shortcut exchange, as the IKE
negotiation is likely to fail.

Philosophy of Tunnel Life

Network designs must balance the needs of appropriately sized
equipment in terms of number of shortcut tunnels and encryption
throughput required, future growth, and the needs of particular
applications and how a dynamic network transport such as ADVPN
interacts with a given application. Changing any one of these charac-
teristics is like pushing on a balloon – the balloon will move but pushes
out the other side and affects the other related characteristics. The
ideal is to find the common overlap as shown in Figure 5.3.
 Chapter 5: Tuning Considerations for ADVPN 45

Figure 5.3 Trying to Find the Common Overlap

Finding the balance leads to considered design choices given the

constraints that are always imposed on any network design.
For example, in a call center-to-call center environment with an
application that transports voice, let’s say the business rules may put a
premium on network stability, with the greatest number of shortcut
paths active to fully optimize voice transport. To accommodate for
this, the design has set a low threshold to keep the shortcut path active.
Over time, the network will look like a full mesh for the application
flows in the network. While encryption performance fits the character-
istics of a SRX240, the potential number of tunnels in the network
suits a SRX550. In this instance, a more powerful SRX is provisioned
to deliver the appropriate outcome. The configuration of ADVPN to
allow tunnels to never be taken down is here:
[email protected]> show configuration security ike gateway advpn-hub
ike-policy ikepol-advpn;
address 192.168.66.1;
local-identity distinguished-name;
remote-identity distinguished-name container ST=ACT,O=Juniper;
external-interface ge-0/0/0.0;
advpn {
suggester {
disable;
}
partner {
idle-threshold 1;
}
}
version v2-only;
 46 Day One: ADVPN Design and Implementation

In another example, there are hundreds of remote branch office sites.

The traffic flow is 95% to the core, which also happens to be the
suggester sites. The balance of the traffic between branch office sites is
random in nature and relatively short-lived. In this case, the encryp-
tion throughput is easily met by the SRX210, but by policy each
SRX210 is only allowed to have sixteen shortcut tunnels. To address
this scenario, the designers have specified a shortcut tunnel idle timer.
Once the tunnel has been idle for 60 seconds, the shortcut tunnel is
deactivated. It was recognized that some traffic flows will not have a
shortcut tunnel created (due to the sixteen shortcut tunnel policy) and
some network traffic will trombone through the suggester SRX. To
cater to this slightly higher capacity, more powerful suggester SRX
nodes are provisioned. The configuration of ADVPN to only allow
sixteen shortcut tunnels and an inactive tunnel life of 60 seconds is:
[email protected]> show configuration security ike gateway advpn-hub
ike-policy ikepol-advpn;
address 192.168.66.1;
local-identity distinguished-name;
remote-identity distinguished-name container ST=ACT,O=Juniper;
external-interface ge-0/0/0.0;
advpn {
suggester {
disable;
}
partner {
connection-limit 16;
idle-time 60;
}
}
version v2-only;

Controlling Spoke-to-Spoke Traffic

One final big picture design point is to decide what traffic is allowed to
go peer-to-peer. There are three broad use cases:
1. Secure router
2. Blacklist traffic
3. Whitelist traffic
The decision of which approach to take should reflect what problem is
being solved by the deployment of ADVPN. As discussed earlier,
network designers may not have a good understanding of the flows
within the network. The imposition of ADVPN can lead to a discovery
of flows as shortcut tunnels that are created to cater for such flows.
 Chapter 5: Tuning Considerations for ADVPN 47

The secure router use case effectively allows any-to-any connectivity in

the network. For such a use case, the SRX security policies follow a
permit all approach. Shortcut tunnels will be suggested and established
up to the limits imposed by the ADVPN configuration. In this use case
care needs to be taken that potential suggestion loops and storms are
not permitted. This would be achieved outside the SRX environment
by having sufficiently locked-down clients. Here’s an example of a
secure router use case policy:
[email protected]> show configuration security policies
default-policy {
permit-all;
}
Next, the blacklist traffic use case specifically denies traffic that should
not be occurring between sites. For example, there are no HTTP servers
outside the data center. As such there should be no call for any HTTP
traffic to flow from a partner site to another partner site. Likewise,
there should be no call for any network management traffic (such as
SNMP) to flow from a partner site to another partner site. However
there are file servers, printing, and directory services that could flow
from site to site. In the blacklisted use case, traffic on the blacklist is
specifically denied, with a general permit any traffic as the default:
root@vSRXB1> show configuration security address-book
global {
address ADVPNspokes 10.1.128.0/17;
}

root@vSRXB1> show configuration security policies

from-zone trust to-zone trust {
policy blacklist-advpn {
match {
source-address ADVPNspokes;
destination-address ADVPNspokes;
application [ junos-http junos-snmp-agentx ];
}
then {
deny;
}
}
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
 48 Day One: ADVPN Design and Implementation

And the whitelist traffic use case only allows traffic that is expected to
flow from partner SRX to partner SRX. An example of this is in an
enterprise where all data processing takes place in the data center and
there should be no data traffic flowing from partner SRX to partner
SRX. However, on the same network, voice traffic is allowed to flow
from partner SRX to partner SRX. The policy rules in this example
would allow voice traffic and specifically deny all other traffic as such:
root@vSRXB1> show configuration security address-book
global {
address ADVPNspokes 10.1.128.0/17;
}

root@vSRXB1> show configuration security policies

from-zone trust to-zone trust {
policy whitelist-advpn {
match {
source-address ADVPNspokes;
destination-address ADVPNspokes;
application junos-sip;
}
then {
permit;
}
}
policy default-deny {
match {
source-address ADVPNspokes;
destination-address ADVPNspokes;
application any;
}
then {
deny;
}
}
}

The SRX has a complete list of tools that can be used to create black or
white lists, in the form of SRX security policies. As noted in preceding
IP Addressing section, the creation of rules can be greatly simplified if
an IP addressing scheme that allows supernetting has been implement-
ed. For many installations, traditional SRX security policy will be
sufficient in terms of classification.
For a very fine granularity of the rules, the SRX application firewall
feature can be used, allowing for traffic to be classified beyond Layer 4
where applications can be rather stealthy in terms of port number
used. It should be noted that rules based on SRX application firewall
may still trigger a shortcut suggestion to be made and tunnel being
formed. The reason for this is some traffic needs to flow from end
station to end station before a determination is made whether the
 Chapter 5: Tuning Considerations for ADVPN 49

application flow matches the application firewall rule. It is possible

during the time from the initial TCP exchange deciding whether this
traffic should be permitted or not to the application firewall, that a
shortcut suggestion is made and a shortcut tunnel is formed. Appro-
priate tuning of tunnel lifetimes will be needed to ensure these tunnels
are deactivated quickly.
While the SRX provides excellent tools to classify traffic, smart
allocations of IP addressing or port numbers can achieve the same
result. This has the advantage of making the SRX policies very simple
and easy to understand. For networks that carry voice and data traffic,
a common implementation is to separate voice and data by VLANs at
the branch office site. Taking this to the logical conclusion, an enter-
prise could have a single supernet for data purposes and a single
supernet for voice purposes. Relating this back to SRX policy rules,
some enterprises may find that referring to the supernet for voice is
sufficient for classification for voice traffic. Likewise many enterprise
applications are delivered using HTTP as a transport. By default, most
web applications use TCP port 80. In many circumstances, the choice
of port can be tailored during application installation. By internally
selecting a unique application port to the enterprise, security policies
can be simplified.

Is the Shortcut Tunnel Still Alive?

IPsec tunnels are a logical interface on the SRX, and as such they are
always considered to be up. With OSPF configured in demand circuit
mode, there needs to be a mechanism to test that the tunnel is still able
to pass traffic. The supported choices in ADVPN are:
1. Dead Peer Detection (DPD)
2. Bidirectional Forwarding Detection (BFD)
DPD uses signaling between the IKE peers to ascertain if the peer
relationship is still good. The downside to DPD is traffic that tests
reachability only goes through the IKE association and there is a
possibility that IPsec traffic is not forwarding, even though the IKE
relationship is okay. The implementation of DPD on SRX can look at
the flow of traffic across the related IPsec tunnel as an indicator that
the peer is okay and suppresses probe messages. However, when the
peer does fail and probe messages are sent, the smallest interval
between probe messages is ten seconds. Assuming a reasonable
threshold of at least 2 is also configured, the minimum convergence
time is at least twenty seconds. DPD should always be configured to
bring down stale tunnels even if the timers are set very conservatively.
 50 Day One: ADVPN Design and Implementation

BFD is a lightweight protocol specifically designed to test for peer

reachability. BFD is designed for very rapid convergence and timers
can be configured to be in the range of tens to hundreds of millisec-
onds. It should be noted that the routing engine performs the BFD
implementation on the SRX platform. Considered tuning of BFD
values will be required to ensure the routing engine does not get
overloaded performing BFD processing.
BFD timers are adaptive, that is, they take into account the status of
the network, and the configuration of the peer node. This can be used
to ensure differentiated timers for partner-to-suggester SRX BFD
sessions, and partner-to partner SRX BFD sessions. As the suggester
SRXs are likely to have a peer connection with every partner SRX in
the network, the BFD load on the suggester is going to be heavy. As
such, the timers for the suggester nodes will need to be conservative.
However, on the partner SRXs, there is likely to be far fewer connec-
tions and the timers can be more aggressive on those connections. To
achieve such state, the following configuration is added to the sug-
gester:
root@vSRXHQ> show configuration protocols ospf
area 0.0.0.0 {
interface st0.0 {
interface-type p2mp;
metric 90;
demand-circuit;
bfd-liveness-detection {
minimum-interval 3000;
multiplier 3;
}
dynamic-neighbors;
}

And the following configuration is added to the partner SRXs:

root@vSRXB1> show configuration protocols ospf
area 0.0.0.0 {
interface st0.0 {
interface-type p2mp;
link-protection;
metric 100;
demand-circuit;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
dynamic-neighbors;
}

Now, looking at the BFD sessions from the suggester SRX, SRXHQ,
and the two partner SRXs, SRXB1, and SRXB2:
 Chapter 5: Tuning Considerations for ADVPN 51

root@vSRXHQ> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.11                Up        st0.0          9.000     3.000        3   
10.1.1.12                Up        st0.0          9.000     3.000        3   

root@vSRXB1> show bfd session    
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        st0.0          9.000     3.000        3   

root@vSRXB2> show bfd session    
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        st0.0          9.000     3.000        3   

You can see that BFD has negotiated the less aggressive of the two
timers. A ping is initiated to trigger a shortcut suggestion, and shortcut
tunnels are established between the two partners:
root@vSRXB1> ping 10.1.1.12 rapid
PING 10.1.1.12 (10.1.1.12): 56 data bytes
!!!!!

The BFD sessions are inspected again and this time, as the partners are
negotiating with a common shared BFD value, a more aggressive set of
timers is put in place. The BFD sessions to the suggester node remains
more conservative:
root@vSRXB1> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        st0.0          9.000     3.000        3   
10.1.1.12                Up        st0.0          0.900     0.300        3   

root@vSRXB2> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        st0.0          9.000     3.000        3   
10.1.1.11                Up        st0.0          0.900     0.300        3   

The implementation of BFD creates traffic on shortcut tunnels. This

traffic will count towards the total traffic a partner will monitor to
ascertain if the shortcut should be left active. If configuration of
ADVPN partners calls for traffic to fall below a certain packet per
second value before a tunnel is deactivated due to insufficient traffic
being sent, the total should reflect the underlying BFD traffic that is
sent on the shortcut tunnel. If not, the tunnel could stay up perma-
nently, as BFD traffic satisfies the minimum packet per second configu-
ration. The configuration on the partner would be as follows:
 52 Day One: ADVPN Design and Implementation

[email protected]> show configuration security ike gateway advpn-hub

ike-policy ikepol-advpn;
address 192.168.66.1;
local-identity distinguished-name;
remote-identity distinguished-name container ST=ACT,O=Juniper;
external-interface ge-0/0/0.0;
advpn {
suggester {
disable;
}
partner {
idle-threshold 6;
}
}
version v2-only;

Summary
ADVPN tuning considerations, like many network designs, consist of
trade-offs between hardware sizing, policy objectives, and what service
level targets are required by the business. Hopefully by this stage you
have your ADVPN environment created in a lab and can be experi-
menting with the factors you need to consider in your network designs.
In the next chapter you’ll be moving past the configuration stage of
deploying an ADVPN enabled network, and start focusing on how you
go about managing the network.
Chapter 6

Management and Day-to-Day Operations

Monitoring ADVPN With SNMP

If you’ve got an existing network management platform, you’ll want to
know which SNMP MIBs and objects are worth polling, and you’re
probably also interested in how to handle SNMP traps relating to VPN
events.
While the ADVPN feature does not introduce any changes to existing
SNMP MIBs supported by Junos, SNMP can still be used effectively
to monitor the operation of an ADVPN deployment through existing
IPsec VPN MIBs.
This chapter does not provide a comprehensive guide to using SNMP
to monitor SRX gateways; however, some ADVPN-specific examples
will be covered. Let’s take a closer look.

SNMP MIBs
Most of the Juniper security-related management objects are contained
within the jnxJsSecurity branch of the Juniper enterprise MIB
hierarchy. Along with IPsec VPN, this branch contains entries for
features such as NAT, screens, IDP, UTM, and LSYS.

MORE? Check out the SNMP MIB Explorer tool at http://contentapps.juniper.

net/mib-explorer/.

TIP The show snmp mib walk command allows interrogation of the various
MIBs supported by Junos without needing an external host or NMS.

The following MIBs contain objects (for example, counters and

gauges) relating to the operation of IPsec on SRX gateways.
 54 Day One: ADVPN Design and Implementation

JUNIPER-IPSEC-FLOW-MON-MIB (jnxIpSecFlowMonMIB)
This MIB exposes information about both phases of the IPsec opera-
tion. The MIB is populated with information about ADVPN shortcut
SAs as they are created. Similarly, when a shortcut tunnel is deleted,
data disappears from the MIB.

Phase 1
„„ Number of IKE tunnels (phase 1 SAs)
„„ Details of phase 1 SAs (local and remote peer IP addresses, SA
status, encryption, and hashing algorithms, etc.)
„„ Phase 1 SA status (packets and octets in/out)

Phase 2
„„ Number of IPsec tunnels (phase 2 SAs)
„„ Details of phase 2 SAs (local/remote IP addresses, proxy IDs, key-
ing method)
„„ Phase 2 SA status (encrypted and decrypted packets and octets in/
out, anti-replay drops, authentication failures, encryption
failures, etc.)
$ snmpwalk -v2c -c <community> <ipaddress> jnxIpSecFlowMonMIB
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalGwAddr.ipv4.”10.16.0.1”.5021960 = STRING: “10.16.2.1”
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalGwAddrType.ipv4.”10.16.0.1”.5021960 = INTEGER: ipv4(1)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonState.ipv4.”10.16.0.1”.5021960 = INTEGER: up(1)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonInitiatorCookie.
ipv4.”10.16.0.1”.5021960 = STRING: 9284c8b24baab87e
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonResponderCookie.
ipv4.”10.16.0.1”.5021960 = STRING: 8c18d24c99abfe1a
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalRole.ipv4.”10.16.0.1”.5021960 = INTEGER: initiator(1)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalIdType.ipv4.”10.16.0.1”.5021960 = INTEGER: idDn(3)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalIdValue.
ipv4.”10.16.0.1”.5021960 = STRING: C=AU, DC=sec0001, ST=ACT, L=Canberra, CN=srx550-01.sec0001.lab.
jnprcbr.local
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLocalCertName.ipv4.”10.16.0.1”.5021960 = STRING: srx550-01_0001.
cert
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonRemoteIdType.ipv4.”10.16.0.1”.5021960 = INTEGER: idDn(3)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonRemoteIdValue.
ipv4.”10.16.0.1”.5021960 = STRING: C=AU, DC=sec0001, ST=ACT, L=Canberra, CN=srx650-01.sec0001.lab.
jnprcbr.local
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonEncryptAlgo.ipv4.”10.16.0.1”.5021960 = INTEGER: espAes256(6)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonAuthMethod.ipv4.”10.16.0.1”.5021960 = INTEGER: 0
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonLifeTime.ipv4.”10.16.0.1”.5021960 = INTEGER: 28459 seconds
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonActiveTime.ipv4.”10.16.0.1”.5021960 = INTEGER: 34100
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonInOctets.ipv4.”10.16.0.1”.5021960 = Counter64: 1795 Octets
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonInPkts.ipv4.”10.16.0.1”.5021960 = Counter32: 3 Packets
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonOutOctets.ipv4.”10.16.0.1”.5021960 = Counter64: 1802 Octets
 Chapter 6: Management and Day-to-Day Operations 55

JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonOutPkts.ipv4.”10.16.0.1”.5021960 = Counter32: 3 Packets
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonXAuthUserId.ipv4.”10.16.0.1”.5021960 = STRING: not available
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIkeTunMonDPDDownCount.ipv4.”10.16.0.1”.5021960 = Counter32: 0 Packets
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonProtocol.ipv4.”10.16.0.1”.67108866.1 = INTEGER: esp(2)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonInSpi.ipv4.”10.16.0.1”.67108866.1 = Gauge32: 2279630321
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonOutSpi.ipv4.”10.16.0.1”.67108866.1 = Gauge32: 65043527
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonType.ipv4.”10.16.0.1”.67108866.1 = INTEGER: dynamic(2)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonEncapMode.ipv4.”10.16.0.1”.67108866.1 = INTEGER: tunnel(1)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonLifeSize.ipv4.”10.16.0.1”.67108866.1 = INTEGER: 0
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonLifeTime.ipv4.”10.16.0.1”.67108866.1 = INTEGER: 3600
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonActiveTime.ipv4.”10.16.0.1”.67108866.1 = INTEGER: 34100
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIPsecSaMonLifeTimeThreshold.ipv4.”10.16.0.1”.67108866.1 = INTEGER: 2965
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonEncryptAlgo.ipv4.”10.16.0.1”.67108866.1 = INTEGER: espNull(3)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonAuthAlgo.ipv4.”10.16.0.1”.67108866.1 = INTEGER: unknown(0)
JUNIPER-IPSEC-FLOW-MON-MIB::jnxIpSecSaMonState.ipv4.”10.16.0.1”.67108866.1 = INTEGER: active(1)

The output above might look a bit daunting, but once you know what
you’re looking at, deciding which objects are operationally useful will
be easy.
Take a look at the output again. You’ll notice that about halfway
through the output, the objects change from having a jnxIkeTunMon
prefix, to jnxIpSecSaMon – this is the separation of phase 1 and phase 2
information.
The numbers “5021960” and “67108866” are the phase 1 and phase
2 SA index numbers, respectively. These values are ephemeral and
correspond to the index numbers you see in the show security [ ike |
ipsec ] security-associations command output.

Lastly, you’ll see the IP address 10.16.0.1 embedded in the output.

That just happens to be the peer IP address of the SRX specified at the
snmpwalk command line. If you have multiple peers – and that’s the
whole point of ADVPN – you’ll see this same set of objects enumerated
for every IPsec peer on the SRX.

JUNIPER-JS-IPSEC-VPN-MIB (jnxJsIpSecVpnMib)
This MIB provides IPsec-related configuration information. Informa-
tion extracted from this MIB could be used to augment information
gathered from another MIB or from another source altogether.
„„ Tunnel policy name (only applies to policy-based VPNs – not
applicable to ADVPN)
„„ Tunnel type (policy-based or route-based – ADVPN tunnels are
always route-based)
„„ Tunnel monitoring configuration state (VPN Monitor enabled or
disabled)
„„ Tunnel monitoring state (VPN Monitor detects up, down, or
VPN Monitor disabled)
 56 Day One: ADVPN Design and Implementation

$ snmpwalk -v2c -c <community> <ipaddress> jnxJsIpSecVpnMib
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunPolicyName.ipv4.”10.16.0.1”.131073 = STRING: 
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunPolicyName.ipv4.”10.16.0.1”.67108865 = STRING: 
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunPolicyName.ipv4.”10.16.0.1”.67108866 = STRING: 
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecVpnTunType.ipv4.”10.16.0.1”.131073 = INTEGER: routeBased(2)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecVpnTunType.ipv4.”10.16.0.1”.67108865 = INTEGER: routeBased(2)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecVpnTunType.ipv4.”10.16.0.1”.67108866 = INTEGER: routeBased(2)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunCfgMonState.ipv4.”10.16.0.1”.131073 = INTEGER: disable(1)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunCfgMonState.ipv4.”10.16.0.1”.67108865 = INTEGER: disable(1)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunCfgMonState.ipv4.”10.16.0.1”.67108866 = INTEGER: disable(1)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunState.ipv4.”10.16.0.1”.131073 = INTEGER: vpnMonitoringDisabled(3)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunState.
ipv4.”10.16.0.1”.67108865 = INTEGER: vpnMonitoringDisabled(3)
JUNIPER-JS-IPSEC-VPN-MIB::jnxJsIpSecTunState.
ipv4.”10.16.0.1”.67108866 = INTEGER: vpnMonitoringDisabled(3)

JUNIPER-SRX5000-SPU-MONITORING-MIB
(jnxJsSPUMonitoringMIB)

TIP Don’t let the MIB’s name fool you – this MIB is supported by all
SRX-series devices, not just the SRX5K.

This MIB is really important for monitoring SRX-series devices,

whether or not you’re using ADVPN. It’s through this MIB that the
performance of SRX services processors – the system element that
handles flows, firewalling, encryption and other security services – can
be monitored.
Given the clean separation between the control and data planes
inherent in the design of SRX-series devices, it is theoretically possible
for the control plane to be utilized very minimally, while the data plane
(of which the SPU(s) are a part) is running red hot!

TIP If you’re running an SNMP-based monitoring suite, check to see wheth-

er it’s reporting on both control plane and data plane utilization. At
least one very well known commercial product only reports on control
plane stats out of the box, which can lull customers into a false sense of
security.

The key performance indicators exposed via this MIB are:

1. SPU processor utilization (0-100%)
2. SPU memory utilization (0-100%)
3. SPU current flows
4. SPU max flows
$ snmpwalk -v2c -c <community> <ipaddress> jnxJsSPUMonitoringMIB
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringFPCIndex.0 = Gauge32: 0
 Chapter 6: Management and Day-to-Day Operations 57

JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringSPUIndex.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCPUUsage.0 = Gauge32: 0 percent
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringMemoryUsage.0 = Gauge32: 75 percent
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCurrentFlowSession.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringMaxFlowSession.0 = Gauge32: 409600
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCurrentCPSession.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringMaxCPSession.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringNodeIndex.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringNodeDescr.0 = STRING: single
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringFlowSessIPv4.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringFlowSessIPv6.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCPSessIPv4.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCPSessIPv6.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCurrentTotalSession.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringMaxTotalSession.0 = Gauge32: 409600
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsClusterMonitoringNodeIndex.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsClusterMonitoringNodeDescr.0 = STRING: single
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeCurrentTotalSession.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeMaxTotalSession.0 = Gauge32: 409600
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeSessionCreationPerSecond.0 = Counter64: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeSessCreationPerSecIPv4.0 = Counter64: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeSessCreationPerSecIPv6.0 = Counter64: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeCurrentTotalSessIPv4.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsNodeCurrentTotalSessIPv6.0 = Gauge32: 0
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringTotalSessIPv4.0 = Gauge32: 29
JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringTotalSessIPv6.0 = Gauge32: 0

SNMP Traps
There isn’t much choice in the way of IPsec-specific SNMP traps in
Junos. In practice, what’s done for IPsec VPNs is to monitor for traps
from protocols surrounding IPsec. Some examples include:
„„ OSPF neighbor state changes (from OSPF-TRAP-MIB)
„„ BFD session state changes (from BFD-STD-MIB)
„„ Secure tunnel (st0) interface state changes (from IF-MIB)
One of the potential problems to solve, if you’re reliant on SNMP traps
to monitor your network, is how to differentiate between events from
the above sources that are real incidents to investigate, and events that
are simply triggered by ADVPN doing what it does best – dynamically
bringing up and tearing down tunnels.
Thankfully, modern SNMP trap managers allow events to be ignored
completely, or perhaps just downgraded in severity, based on variables
embedded within the trap itself. This applies to the OSPF and BFD
traps you might see. Dust off your favorite packet analysis utility and
see if you can spot something that’s different in the embedded variables
for a trap relating to a to a control SA going down, versus a shortcut
tunnel going down.
 58 Day One: ADVPN Design and Implementation

Hint: You can probably white-list (therefore, treat as real incidents)

events that include the IP addresses of your suggesters, and ignore or
downgrade events that include IP addresses from anything else.
Of course, if the link state of your secure tunnel (st0) interface goes
down and you receive a trap from IF-MIB, that’s probably something
worth investigating!

Remote Monitoring (RMON)

Junos includes Remote Monitoring (RMON) functionality that can be
used to create on-box agents capable of monitoring the values of
specific SNMP OIDs, and taking actions such as generating a system
log, sending an SNMP trap, or both, when thresholds are crossed.
RMON is useful for augmenting the pre-defined/built-in trap types
that Junos generates out of the box. By dissecting the variables embed-
ded within an SNMP trap triggered by an RMON alarm, it is possible
to gain greater visibility into the operational state of Junos-based
platforms.
The following example creates an RMON alarm definition that
samples the jnxJsSPUMonitoringCurrentFlowSession object every 10
seconds. This object tracks the number of active traffic flow sessions
that the SRX is handling.
When the number of sessions goes above 18,432, an SNMP trap is sent
to the target defined in the ADVPN trap group. Similarly, an SNMP
trap is sent when the number of sessions falls below 12,288:
snmp {
location Nishi;
contact “[email protected]”;
interface vlan.100;
community public {
authorization read-only;
clients {
172.27.160.0/24;
}
}
trap-group ADVPN {
version v2;
categories {
rmon-alarm;
}
targets {
172.27.160.180;
}
}
rmon {
alarm 100 {
interval 10;
 Chapter 6: Management and Day-to-Day Operations 59

variable jnxJsSPUMonitoringCurrentFlowSession.0;
sample-type absolute-value;
startup-alarm rising-alarm;
rising-threshold 18432;
falling-threshold 12288;
rising-event-index 500;
falling-event-index 500;
}
event 500 {
type log-and-trap;
community ADVPN;
}
}
}

For demonstration purposes, the above configuration was applied to

an SRX210 gateway, with rising and falling thresholds set to 50 and 40
respectively.
The following output is a text extract taken from Wireshark of the
SNMP trap packet associated with the rising threshold event:

Simple Network Management Protocol

version: v2c (1)
community: ADVPN
data: snmpV2-trap (7)
snmpV2-trap
request-id: 1601857833
error-status: noError (0)
error-index: 0
variable-bindings: 8 items
SNMPv2-MIB::sysUpTime.0 (1.3.6.1.2.1.1.3.0): 585099400
Object Name: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
Scalar Instance Index: 0
SNMPv2-MIB::sysUpTime: 585099400
SNMPv2-MIB::snmpTrapOID.0 (1.3.6.1.6.3.1.1.4.1.0): 1.3.6.1.2.1.16.0.1
(RMON-MIB::risingAlarm)
Object Name: 1.3.6.1.6.3.1.1.4.1.0 (SNMPv2-MIB::snmpTrapOID.0)
Scalar Instance Index: 0
SNMPv2-MIB::snmpTrapOID: 1.3.6.1.2.1.16.0.1 (RMON-MIB::risingAlarm)
RMON-MIB::alarmIndex.100 (1.3.6.1.2.1.16.3.1.1.1.100): 100
Object Name: 1.3.6.1.2.1.16.3.1.1.1.100 (RMON-MIB::alarmIndex.100)
RMON-MIB::alarmEntry.alarmIndex: 100
RMON-MIB::alarmIndex: 100
RMON-MIB::alarmVariable.100 (1.3.6.1.2.1.16.3.1.1.3.100): 1.3.6.1.4.1.26
36.3.39.1.12.1.1.1.6.0 (JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCurrent
FlowSession.0)
Object Name: 1.3.6.1.2.1.16.3.1.1.3.100 (RMON-MIB::alarmVariable.100)
RMON-MIB::alarmEntry.alarmIndex: 100
RMON-MIB::alarmVariable: 1.3.6.1.4.1.2636.3.39.1.12.1.1.1.6.0
(JUNIPER-SRX5000-SPU-MONITORING-MIB::jnxJsSPUMonitoringCurrentFlowSession.0)
RMON-MIB::alarmSampleType.100 (1.3.6.1.2.1.16.3.1.1.4.100):
absoluteValue (1)
Object Name: 1.3.6.1.2.1.16.3.1.1.4.100 (RMON-
 60 Day One: ADVPN Design and Implementation

MIB::alarmSampleType.100)
RMON-MIB::alarmEntry.alarmIndex: 100
RMON-MIB::alarmSampleType: absoluteValue (1)
RMON-MIB::alarmValue.100 (1.3.6.1.2.1.16.3.1.1.5.100): 95
Object Name: 1.3.6.1.2.1.16.3.1.1.5.100 (RMON-MIB::alarmValue.100)
RMON-MIB::alarmEntry.alarmIndex: 100
RMON-MIB::alarmValue: 95
RMON-MIB::alarmRisingThreshold.100 (1.3.6.1.2.1.16.3.1.1.7.100): 50
Object Name: 1.3.6.1.2.1.16.3.1.1.7.100 (RMON-
MIB::alarmRisingThreshold.100)
RMON-MIB::alarmEntry.alarmIndex: 100
RMON-MIB::alarmRisingThreshold: 50
SNMPv2-MIB::snmpTrapEnterprise.0 (1.3.6.1.6.3.1.1.4.3.0):
1.3.6.1.4.1.2636.1.1.1.2.36 (JUNIPER-CHASSIS-DEFINES-MIB::jnxProductNameSRX210)
Object Name: 1.3.6.1.6.3.1.1.4.3.0 (SNMPv2-MIB::snmpTrapEnterprise.0)
Scalar Instance Index: 0
SNMPv2-MIB::snmpTrapEnterprise: 1.3.6.1.4.1.2636.1.1.1.2.36 (JUNIPER-
CHASSIS-DEFINES-MIB::jnxProductNameSRX210)

Summary
SNMP is still a very popular protocol for managing network devices. In
this chapter, you’ve seen how SNMP can be used to pull operational
VPN information from SRX-series devices, and how SNMP traps and
RMON alarms can be used to push event information into an existing
SNMP-based network management platform.
In the next chapter, you’ll take a look at some newer and more flexible
methods for managing ADVPN using automation techniques built into
Junos.
Chapter 7

Using Junos Automation to Help

Manage ADVPN Environments

The Junos OS has a number of different tools that can be used to

automate work and help manage Juniper SRX Series networks. What
to automate and how to automate is very much an individual or
organizational preference, so a couple of different examples are listed
in this chapter. While the examples should be useful, this chapter also
demonstrates better approaches and seeds a few ideas about how
Junos automation can be used to make SRX management even easier.

Using Junos Events

Juniper has an extensive array of events that are logged during the
course of SRX operation. When thinking about the foundation of this
automation, you want Junos to do something when an event has been
seen, rather having to perform the actions yourself. Events can be the
standard syslog messages Junos knows about, match text on any syslog
message, or, alternatively, Junos can create events based on time. In
response to these events Junos can execute CLI commands, change the
configuration, raise a trap, upload a file, or run a more complex SLAX
event script. The beauty about most of these methods is that once you
are familiar with the Junos CLI, the incremental learning required is to
get going with Junos automation is minimal.
Let’s consider a simple example to illustrate the benefits of Junos
automation. A new ADVPN network implementation has a business
rule that shortcut tunnels should not be taken down during business
hours in order to minimize network state changes. However, for
statistical purposes, the same organization does not want unused
shortcut tunnels to linger. To achieve this, every 24 hours, in the
middle of the night, all shortcut tunnels are to be removed from
 62 Day One: ADVPN Design and Implementation

service. There are two steps – the first to generate an event, and the
second a policy to react to the event that has been generated. The
configuration required to achieve this is:
event-options {
generate-event {
1AM time-of-day “01:00:00 +0000”;
}
policy clearadvpn {
events 1AM;
then {
execute-commands {
commands {
“clear security ike sa sa-type shortcut”;
“clear security ipsec sa sa-type shortcut”;
}
}
}
}
}

The event 1AM is generated by the SRX. This event happens at 1 AM

every day. Note how the event is aware of time zones to ensure the
event occurs when you expect the event to occur and not based on
UTC.
You can also see that a policy called clearadpvn was created. This
policy is executed when the event 1AM is triggered. The action for this
policy is to execute the CLI commands that clear the IKE and IPsec
security associations where the attributes for the association are a
shortcut tunnel.

Using Junos SLAX Scripting

SLAX scripting is the next level of sophistication of Junos automation.
SLAX is a programming language built into Junos, specifically de-
signed to handle XML formatted information. When working with
Junos, configuration and show commands are all XML-encoded,
ensuring a consistent way in how information is presented.
To see this, execute the command: show configuration | display xml

As a consequence, this also allows for easy matching of information.

SLAX syntax is similar to C or Perl. When a SLAX script is executed,
the SLAX script is transformed into a XSLT script and run by the Junos
management daemon (mgd).

MORE? There are a number of books in the Day One library to get you up to
speed with SLAX programming at http://www.juniper.net/dayone.
 Chapter 7: Using Junos Automation to Help Manage ADVPN Environments 63

NOTE Script writing practice often follows the long taught computer science
principle of code reuse, that is, find another script that does something
similar in nature to what is required and modify that code to achieve the
result required. Scripts that have been made publicly available can be
found here:

„„ https://techwiki.juniper.net/Automation_Scripting/Junos_Automa-
tion_Library
„„ https://github.com/Juniper/junoscriptorium/tree/master/library/
juniper
One of the more useful examples of using SLAX scripting is to build your
own MIB – that is, to expose via SNMP information contained on the
SRX not covered by an existing standard or Juniper specific MIB. In
almost all circumstances, if the information is available via the CLI, a
SLAX script can be used to extract this information and place it in a
private MIB. Junos has a facility under the Juniper enterprise OID tree
called the Utility MIB, where values can be set either by the CLI or a
SLAX script.
Okay, back to ADVPN. Now that the network is more dynamic than
ever, how can the usage of ADVPN be measured? Built into Junos is the
jnxIpSecFlowMonMIB MIB under the Junos enterprise MIB tree. This gives
the ongoing statistics for the IPsec security association, such as encrypted
bytes, in and out, and encrypted packets in and out. Note that the IP
addresses that are used in the MIB are the external peer IP addresses.
With a good IP addressing and naming scheme, it should be possible to
infer the routing instance, the local and remote IP addresses of the
protected tunnel. That may not be possible, but the information should
be able to be derived from the SRX. If so, it should also be possible to
polled via SNMP.
Let’s execute the show security ipsec next-hop-tunnels command:
root@vSRXB1> show security ipsec next-hop-tunnels    
Next-hop gateway  interface   IPsec VPN name                    Flag     IKE-ID
XAUTH username
10.1.1.1          st0.0       instance-GT-ADVPN-
spoke1-67108865_67108870 Auto C=AU, ST=ACT, O=Juniper, OU=juniper-vpn, CN=vSRXHQ.
juniper.net Not-Available 
10.1.1.2          st0.0       instance-GT-ADVPN-
spoke1bu-67108868_67108869 Auto C=AU, ST=ACT, O=Juniper, OU=JuniperCA, CN=vSRXHQBU.
juniper.net Not-Available 
11.1.1.1          st0.1       instance-GT-ADVPN-spoke1-
vr1-67108866_67108872 Auto C=AU, ST=ACT, O=Juniper, OU=VR1, CN=vSRXHQ-VR1.juniper.
net Not-Available 
11.1.1.2          st0.1       instance-GT-ADVPN-spoke1-vr1-
bu-67108867_67108871 Auto C=AU, ST=ACT, O=Juniper, OU=VR1, CN=vSRXHQBU-VR1.juniper.
net Not-Available 
 64 Day One: ADVPN Design and Implementation

You can see in the bolded output that the first entry is the next-hop
address. Importantly, this is the protected IP address. The second entry
is the local interface. It is important you know which interface is being
used as that will become the key to what routing instance is being used.
Inspecting the IPsec VPN name, the name is made up from the underlying
VPN name as well as the IPsec security association’s identifiers from both
ends of the security association. Using SLAX, the next-hop address, local
st0 interface, and stripping out the security association from the IPsec
VPN name is relatively simple. Using the security association index as a
MIB key means you can relate this information to the jnxIpSecFlowMon-
MIB MIB. That is, stats from that MIB now have the remote protected IP
address as well as the outbound local interface.
The final piece of the puzzle is to relate the local st0 interface to a routing
instance so you can make the distinction between IPsec security associa-
tions belonging to different routing instances. Let’s try the show inter-
faces routing-instance all terse command:

show interfaces routing-instance all terse 
root@vSRXB1> show interfaces routing-instance all terse 
Interface        Admin Link Proto  Local                Instance
...
st0.0            up    up   inet   10.1.1.11/24         default
st0.1            up    up   inet   11.1.1.11/24         vr1

The first entry is the local interface and the last entry is the routing
instance name. Using the interface as a key, this entry can be directly
related to the previous show command. In summary, the information is
available from the SRX, it just needs to be extracted and put into the
Utility MIB so that it can be polled via SNMP.
By convention, Juniper Utility MIBs should have their OIDs pre-pended
by a script identifier so they are unique to that script, allowing for
multiple uses of the MIB without having collisions on OIDs. In this case,
the script identifier chosen is “23876” (ADVPN). The layout of the
information that is to be populated is as follows:
jnxUtilStringValue.23287.0                      = script tracker to delete old items
jnxUtilStringValue.23287.1.<IPsec SA number> .1 = local tunnel name (string)
                                             .2 = next hop address (string)
jnxUtilStringValue.23287.2.<interface name>  .1 = routing instance name (string)

The script that that does all the work is on this book’s landing page at
http://www.juniper.net/dayone.

NOTE If you’re in your lab and you want to experiment a little, Junos Space can
manage scripts.

The script needs to find its way to /var/op/script/db. Once the script is
there, Junos needs to be configured so it knows of its existence:
 Chapter 7: Using Junos Automation to Help Manage ADVPN Environments 65

root@vSRXB1> show configuration system scripts

op {
file advpnmib.slax;
}

Once in Junos configuration mode the script can be run at any time:
root@vSRXB1> op advpnmib

As this script is designed to populate the utility MIB, there is no output

to the screen.
As mentioned previously, Junos has a very convenient way of walking
the MIB tree via a show command. In this first instance, let’s walk the
first part of the tree, where 50.51.56.55.54 is the script identifier
ADVPN and 49 (numeric 1) is the IPsec SA part of the MIB. So it’s
easier to read, the output has been requested in ASCII:
root@vSRXB1> show snmp mib walk jnxUtilStringValue.50.51.56.55.54.49 ascii
jnxUtilStringValue.”238761671088691” = st0.0
jnxUtilStringValue.”238761671088692” = 10.1.1.2
jnxUtilStringValue.”238761671088701” = st0.0
jnxUtilStringValue.”238761671088702” = 10.1.1.1
jnxUtilStringValue.”238761671088711” = st0.1
jnxUtilStringValue.”238761671088712” = 11.1.1.2
jnxUtilStringValue.”238761671088721” = st0.1
jnxUtilStringValue.”238761671088722” = 11.1.1.1

The script has found four IPsec security associations active, with their
respective tunnel index numbers being 67108869, 67108870,
67108871, and 67108872. For each security association, the remote
protected tunnel interface and local outbound interface is provided.
Now, for the second part of the tree, where again 50.51.56.55.54 is our
script identifier ADVPN, but this time 50 (numeric 2) is the interface
part of the MIB:
root@vSRXB1> show snmp mib walk jnxUtilStringValue.50.51.56.55.54.50 ascii
jnxUtilStringValue.”238762st0.0” = default
jnxUtilStringValue.”238762st0.1” = vr1

The script has found two st0 interfaces, with their respective names
being st0.0 and st0.1, and for each interface, the routing instance they
belong to, is listed.

Putting It All Together

The final piece to a working solution for our new MIB creation script is
to have it updated regularly. The update cycle needs to balance how
fresh the information is versus the impact of running the script on the
routing engine. The freshness of the information needs to be coupled
with how long a tunnel is expected to live. If tunnel lifetime is very
 66 Day One: ADVPN Design and Implementation

short, say 1-2 minutes, the ability to capture the requisite information
before the tunnel is torn down will be marginal. For suggester nodes
that are likely to have a very large number of IPsec security associa-
tions, the script should run less frequently. Given IPsec tunnels to
suggester nodes should be long-lived, this should not pose too many
difficulties with having lost data.
Using the work from the first example, the SRX is going to generate an
event every five minutes (300 seconds). Unlike the first example where
a command was used as the action, in this case the action is to call the
script that updates the Utility MIB. The configuration is as follows:
root@vSRXB1> show configuration event-options
generate-event {
5Min time-interval 300;
}
policy advpnmib {
events 5Min;
then {
event-script advpnmib.slax;
}
}

Summary
Junos automation should be used to help manage the ADVPN network
implementation. The goal for any automation should be to get a
machine to do something that you don’t want to do. Automation can
be as simple as executing certain actions based on events that occur in
the ADVPN enabled network or as sophisticated as scripting to extract
detailed information for further analysis.
Now we’ve covered the day-to-day management of an ADVPN
environment and how to automate it, the next chapter will concentrate
on troubleshooting an ADVPN environment.
Chapter 8

Troubleshooting ADVPN

Monitoring ADVPN with Syslog

ADVPN – as part of the IKE daemon in Junos – introduces a number
of new system log messages. Additionally, the format of some existing
log messages has been updated to include ADVPN specific details. It’s
important to be aware of these updated messages as they provide key
insight into the operation of ADVPN and will help you troubleshoot if
things aren’t going according to plan.

MORE Check out the System Log Explorer tool at http://contentapps.juniper.

net/syslog-explorer/.

Structured IPsec and PKI related system logs are prefixed with KMD_
and PKID_ respectively.
Junos provides a very flexible framework for managing system log
messages. Whether you’re logging to the terminal, local files, an
external syslog host, or a combination thereof, Junos provides you
with a lot of control of what gets logged, and where.
 68 Day One:ADVPN Design and Implementation

One of the most useful features in the logging configuration is the

ability to match patterns in system messages, using a regular expres-
sion, to only capture messages you’re interested in.
Now that you know which system messages contain ADVPN-related
information, it’s trivial to match and log those messages:
[edit system syslog]
admin@srx550-01# show file advpn-log
any any;
match KMD_SHORTCUT;

This example simply captures any log messages containing the string
“KMD_SHORTCUT” (NB: the match is not case sensitive), regardless
of the facility or severity at which it was logged, into the local file /
var/log/advpn-log.

Here are some helpful hints that should allow you to fine-tune your
syslog configuration:
„„ When you’re testing or piloting ADVPN, consider logging more
events (for example, any facility, any severity) so that you can
determine what’s operationally useful, and what’s not. This
allows you to white-list events at the source rather than over-
whelming your logging system. It’s also useful to observe rela-
tionships between events (for example, between BFD and OSPF).
„„ If you’re not sure what facility and/or severity a specific event is
being logged at, you have two options:
„„ Use the online syslog reference built into Junos:
admin@srx550-01> help syslog RPD_OSPF_NBRDOWN
Name: RPD_OSPF_NBRDOWN
Message: OSPF neighbor <neighbor-address> (realm <realm-name> <interface-name>
area <area-id>i) state changed from <old-state> to <new-state> due to <event-name>
(event
reason: <reason>)
Help: OSPF neighbor adjacency was terminated
Description: An OSPF adjacency with the indicated neighboring router was terminated.
The local router no longer exchanges routing information with, or directs traffic to,
the
neighboring router.
Type: Event: This message reports an event, not an error
Severity: notice
Facility: LOG_DAEMON
Action: For more information, see KB19074.

„„ Use the “explicit-priority” statement under your syslog target/

destination to include the facility and severity in the log message
itself.
 Chapter 8: Troubleshooting ADVPN 69

Without “explicit-priority”:
rpd[1460]: RPD_OSPF_NBRUP: OSPF neighbor 172.24.114.2 (realm ospf-v2 st0.10 area 0.0.0.0)
state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this
router)

With “explicit-priority”:
rpd[1460]: %DAEMON-6-RPD_OSPF_NBRUP: OSPF neighbor 172.24.114.2 (realm ospf-v2 st0.10
area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor
detected this router)

In the second output, the facility is “daemon” and the severity is “6”,
which is considered “informational.” See RFC 5424 (section 6.2.1) for
more details on syslog facilities and severities.

New Messages
This section describes the new system log messages introduced as part of
the ADVPN feature.

Advertising ADVPN Capabilities

This message is logged when the control SA is established between a
partner and a suggester. You’ll see this message logged on both partner
and suggester SRX gateways.
The following fields are included in the message:
„„ IKE security association ID
„„ Local and remote IKE peer IP addresses
„„ Local and remote ADVPN capability (e.g. partner, suggester)
„„ Negotiated ADVPN protocol version (currently only version 1)
Example:
Dec 7 19:15:36 vsrxvpn30 kmd[1144]: IKE negotiation successfully completed. IKE
Version: 2, VPN: zth_spoke_vpn Gateway: zth_spoke_gw, Local: 17.0.1.7/500, Remote:
23.0.0.250/500, Local IKE-ID: DC=juniper, CN=vsrx30, L=Sunnyvale, ST=CA, C=US, Remote
IKE-ID: DC=juniper, CN=vsrx29, L=Sunnyvale, ST=CA, C=US, VR-ID: 0, Role: Initiator, Local
ADVPN Capability: Partner, Peer ADVPN Capability: Suggester, Negotiated ADVPN version: 1

KMD_SHORTCUT_SUGGESTION_SENT
This is logged when a suggester sends a shortcut request to an initiator
partner or a responder partner.
The following fields are included in the message:
„„ Shortcut identifier
 70 Day One:ADVPN Design and Implementation

„„ Partner IP address to which the suggestion is being made

„„ Partner role to which this suggestion is being made
„„ Initiator Partner information (IP address, IKE-ID, role)
„„ Responder Partner information (IP address, IKE-ID, Role)
„„ Traffic selectors proposed in suggestion
„„ P1 SA index on which this suggestion is sent
Example:
Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_SENT to responder partner:
31.1.1.2, for shortcut identifier: 0xff800007; between partner 12.1.1.202 ike-id: C=US,
DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn80; role:
Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper,
OU=engineering, CN=vsrxvpn79; role: Responder; traffic selectors: ipv4(0.0.0.0-
255.255.255.255); P1 SA index: 2686136

Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_SENT to initiator partner:

12.1.1.202, for shortcut identifier: 0xff800007; between partner 12.1.1.202 ike-id:
C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn80; role:
Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper,
OU=engineering, CN=vsrxvpn79; role: Responder; traffic selectors: ipv4(0.0.0.0-
255.255.255.255); P1 SA index: 2686133

KMD_SHORTCUT_SUGGESTION_RECEIVED
This message will be logged when a partner receives a shortcut sugges-
tion. The response, i.e. whether the shortcut suggested is accepted or
declined, will also be logged in the same message.
The following fields are included in the message:
„„ Control/Static P1 SA ID
„„ Suggester IP address
„„ Local Partner IP address
„„ Peer Partner IP address
„„ Shortcut identifier
„„ Initiator IKE ID
„„ Responder IKE ID
„„ Initiator Traffic-Selector
„„ Responder Traffic-Selector
„„ Shortcut Lifetime
„„ Shortcut negotiation role
„„ Shortcut Response (accept/decline)
 Chapter 8: Troubleshooting ADVPN 71

Example:
Dec 7 18:52:38 vsrxvpn30 kmd[1144]: SHORTCUT_SUGGESTION_RECEIVED: P1 SA id: 2369718,
Local shortcut partner address: 17.0.1.7, Suggester address: 23.0.0.250, Remote
shortcut partner address: 23.0.0.111 Shortcut initiator ike-id: DC=juniper, CN=vsrx30,
L=Sunnyvale, ST=CA, C=US Shortcut responder ike-id: DC=juniper, CN=vsrx263-cert1,
L=Sunnyvale, ST=CA, C=US Local traffic-selector id: ipv4(0.0.0.0-255.255.255.255)
Remote traffic-selector id: ipv4(0.0.0.0-255.255.255.255), Shortcut identifier:
4286578695, Shortcut lifetime: 0, Shortcut negotiation role: Initiator, Shortcut
response: Shortcut ACK

KMD_SHORTCUT_SUGGESTION_RESPONSE_RECEIVED
This message is logged when a response to a shortcut suggestion is
received from initiator and responder partners.
The following fields are included in the message:
„„ Shortcut identifier
„„ Partner IP address from which the response is received
„„ Partner role from which the response is received
„„ Initiator Partner information (IP address, IKE-ID, role)
„„ Responder Partner information (IP address, IKE-ID, Role)
„„ Traffic selectors proposed in suggestion
„„ P1 SA index on which the response is received
„„ Response code indicated in the response; one of:
SHORTCUT_ACK,
SHORTCUT_OK,
SHORTCUT_DELETE,
SHORTCUT_PARTNER_UNREACHABLE,
SHORTCUT_TEMPORARILY_DISABLED,
SHORTCUT_NEGOTIATION_FAILED,
SHORTCUT_SPD_UNMATCHED,
SHORTCUT_PAD_UNMATCHED

Examples:
Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_RESPONSE_RECEIVED from
responder partner: 31.1.1.2, for shortcut identifier: 0xff800007; between partner
12.1.1.202 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering,
CN=vsrxvpn80; role: Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA,
L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn79; role: Responder; traffic
selectors: ipv4(0.0.0.0-255.255.255.255); P1 SA index: 2686136; shortcut response:
SHORTCUT_ACK

Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_RESPONSE_RECEIVED from

initiator partner: 12.1.1.202, for shortcut identifier: 0xff800007; between partner
12.1.1.202 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering,
CN=vsrxvpn80; role: Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA,
L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn79; role: Responder; traffic
selectors: ipv4(0.0.0.0-255.255.255.255); P1 SA index: 2686133; shortcut response:
SHORTCUT_ACK
 72 Day One:ADVPN Design and Implementation

Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_RESPONSE_RECEIVED from

responder partner: 31.1.1.2, for shortcut identifier: 0xff800007; between partner
12.1.1.202 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering,
CN=vsrxvpn80; role: Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA,
L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn79; role: Responder; shortcut
response: SHORTCUT_OK

Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_RESPONSE_RECEIVED from

initiator partner: 12.1.1.202, for shortcut identifier: 0xff800007; between partner
12.1.1.202 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering,
CN=vsrxvpn80; role: Initiator; and partner 31.1.1.2 ike-id: C=US, DC=juniper, ST=CA,
L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn79; role: Responder; shortcut
response: SHORTCUT_OK

KMD_SHORTCUT_SUGGESTION_SUCCESS

This is logged to indicate that a shortcut suggestion has completed

successfully, when SHORTCUT_ACK or SHORTCUT_OK is received
from both partners.
The following fields are included in the message:
„„ Shortcut identifier
„„ Initiator Partner information (IP address, IKE-ID, role)
„„ Responder Partner information (IP address, IKE-ID, Role)
„„ Initiator Traffic selectors
„„ Responder Traffic selectors
Example:
Sep 18 23:34:04 vsrxvpn75 kmd[2732]: SHORTCUT_SUGGESTION_SUCCESS on shortcut id:
0xff800007; between partner 12.1.1.202 ike-id: C=US, DC=juniper, ST=CA, L=Sunnyvale,
O=Juniper, OU=engineering, CN=vsrxvpn80; role: Initiator; and partner 31.1.1.2 ike-id:
C=US, DC=juniper, ST=CA, L=Sunnyvale, O=Juniper, OU=engineering, CN=vsrxvpn79; role:
Responder; partner1 traffic selectors: ipv4(0.0.0.0-255.255.255.255); partner2 traffic
selectors: ipv4(0.0.0.0-255.255.255.255);

KMD_SHORTCUT_TUNNEL_DELETED
When a partner has deleted a shortcut tunnel, a message will be logged.
The following fields are included in the message:
„„ Shortcut Tunnel ID
„„ Partner_1 IP address
„„ Partner_2 IP address
 Chapter 8: Troubleshooting ADVPN 73

„„ Shortcut Identifier
„„ Initiator IKE ID
„„ Responder IKE ID
„„ Initiator Traffic-Selector
„„ Responder Traffic-Selector
„„ Shortcut Lifetime
„„ Shortcut negotiation role
„„ Reason for deletion
Example:
Dec 7 19:35:28 vsrxvpn30 kmd[1144]: SHORTCUT_TUNNEL_DELETED: tunnel_id: 268173334,
Local partner address: 17.0.1.7, Remote partner address: 23.0.0.111, Shortcut
identifier: 4286578697, Shortcut lifetime: Infinite, Shortcut negotiation role:
Initiator, Initiator ike id: der_asn1_dn(any:0,[0..89]=DC=juniper, CN=vsrx30,
L=Sunnyvale, ST=CA, C=US), Responder ike id: der_asn1_dn(any:0,[0..96]=DC=juniper,
CN=vsrx263-cert1, L=Sunnyvale, ST=CA, C=US), Initiator traffic-selector: ipv4_
subnet(any:0,[0..7]=0.0.0.0/0), Responder traffic-selector: ipv4_
subnet(any:0,[0..7]=0.0.0.0/0), Reason: Idle-time reached

Updated Messages

KMD_VPN_UP_ALARM_USER
The existing KMD_VPN_UP_ALARM_USER message, which is logged
when a security association comes up, has been extended to include a
field indicating the type of security association. In the case of a dynamic
SA between ADVPN Partners, the value is “Shortcut.”
The following fields have been added to the message:
„„ SA Type - Control/Static or Shortcut
Example:
Dec 7 19:32:30 vsrxvpn30 kmd[1144]: KMD_VPN_UP_ALARM_USER: VPN instance-GT-ADVPN-zth_
spoke_vpn-268173331_268173332 from 23.0.0.111 is up. Local-ip: 17.0.1.7, gateway name:
zth_spoke_gw, vpn name: GT-ADVPN-zth_spoke_vpn-268173331, tunnel-id: 268173332, local
tunnel-if: st0.0, remote tunnel-ip: 2.1.1.111, Local IKE-ID: DC=juniper, CN=vsrx30,
L=Sunnyvale, ST=CA, C=US, Remote IKE-ID: DC=juniper, CN=vsrx263-cert1, L=Sunnyvale,
ST=CA, C=US, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector: , Traffic-
selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Traffic-selector remote ID:
ipv4_subnet(any:0,[0..7]=0.0.0.0/0), SA Type: Shortcut
 74 Day One:ADVPN Design and Implementation

KMD_VPN_DOWN_ALARM_USER
When a shortcut tunnel goes down (i.e. when phase 2 SA is deleted),
then Junos will use the existing message KMD_VPN_DOWN_
ALARM_USER.
The following fields have been added to the message:
SA Type - Control/Static or Shortcut
Example:
Dec 7 19:35:28 vsrxvpn30 kmd[1144]: KMD_VPN_DOWN_ALARM_USER: VPN instance-GT-ADVPN-
zth_spoke_vpn-268173333_268173334 from 23.0.0.111 is down. Local-ip: 17.0.1.7,
gateway name: zth_spoke_gw, vpn name: GT-ADVPN-zth_spoke_vpn-268173333, tunnel-id:
268173334, local tunnel-if: st0.0, remote tunnel-ip: 2.1.1.111, Local IKE-ID:
DC=juniper, CN=vsrx30, L=Sunnyvale, ST=CA, C=US, Remote IKE-ID: DC=juniper,
CN=vsrx263-cert1, L=Sunnyvale, ST=CA, C=US, XAUTH username: Not-Applicable, VR id: 0,
Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0),
Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), SA Type: Shortcut,
Reason: Idle-time reached

PKI Messages
All PKI related messages are logged with the PKID_ prefix. Junos
includes over 50 such messages (see “help syslog | match PKID_”), so
we won’t cover them all individually here.
If you’d like to configure a local log file that contains only PKI-related
messages, try this syslog file configuration:
admin@srx650-01> show configuration system syslog | find pki
file pki-log {
daemon any;
match PKID_;
explicit-priority;
}

Here’s an example PKI log message:

admin@srx650-01> monitor start pki-log

admin@srx650-01> clear security pki crl all

admin@srx650-01> Feb 26 22:36:42 srx650-01 pkid[1460]: %DAEMON-6-PKID_CRL_DOWNLOAD_

SUCCESS: CRL download successful for CA ca01-root, next refresh 348398 seconds
 Chapter 8: Troubleshooting ADVPN 75

Summary
You’ve just seen how the logging framework built into Junos can be
used to monitor ADVPN effectively. A number of new log messages
have been introduced as part of the ADVPN feature, and some existing
messages have been extended to include ADVPN-related details.
System logs can be used during testing and development, as well as in
business-as-usual operations.
In the next section, we’ll take a look at the way the Junos operational
mode CLI has been extended to include ADVPN commands that are
useful for troubleshooting purposes.

Troubleshooting ADVPN
As you’re already familiar with IPsec concepts, extending your existing
troubleshooting knowledge to cover ADVPN will take no time at all.
Some CLI commands have been extended to include ADVPN-specific
output and in some cases, additional parameters/arguments have been
added to existing commands to focus the output on ADVPN opera-
tion.

CLI Changes

Changed Command Outputs

The show security ike sa detail and show security ipsec sa
detail command outputs have been enhanced to show ADVPN status
information, if applicable:
admin@srx550-01> show security ike sa detail
IKE peer 10.16.3.1, Index 4195625, Gateway Name: ADVPN-IKEGW-HUB2-VR0001
Auto Discovery VPN:
Type: Shortcut, Local Capability: Partner, Peer Capability: Partner
[...]

admin@srx550-01> show security ipsec sa detail

ID: 67108902 Virtual-system: root, VPN Name: ADVPN-VPN-HUB1-VR0001

Local Gateway: 10.16.2.1, Remote Gateway: 10.16.3.1
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Auto Discovery VPN:
Type: Shortcut, Shortcut Role: Initiator
[...]
 76 Day One:ADVPN Design and Implementation

Commands With New Parameters

The show security ike security-associations [detail], show
security ipsec security-associations [detail] and show security
ipsec inactive-tunnels commands accept a new parameter called
sa-type shortcut that limits the output to show only ADVPN shortcut
SA information:
Examples:
admin@srx550-01> show security ike security-associations sa-type shortcut
Index State Initiator cookie Responder cookie Mode Remote Address
5021959 UP 444c2775a1bb7eb9 bdbef5ff1b939341 IKEv2 10.16.3.2
5021962 UP 71ed8e0abc2c1ec1 e913330fd2b23292 IKEv2 10.16.3.1

admin@srx550-01> show security ipsec security-associations sa-type shortcut

Total active tunnels: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<67108879 ESP:aes-gcm-256/None 813810b9 1522/ unlim - root 500 10.16.3.2
>67108879 ESP:aes-gcm-256/None a2f010d0 1522/ unlim - root 500 10.16.3.2

admin@srx550-01> show security ipsec inactive-tunnels sa-type shortcut

Total inactive tunnels: 0
Total inactive tunnels with establish immediately: 0

Troubleshooting PKI
ADVPN’s requirement for PKI in conjunction with IPsec can seem
daunting at first, and there’s no doubt it does introduce a degree of
complexity that you don’t get with the pre-shared keys you’ve come to
know and love.
Without question, the use of PKI can greatly widen the scope of your
troubleshooting if something’s not working. But even once you do get
device certificates signed and issued with the right attribute values and
so on, things can still go wrong.
Take the example where your network might be ticking along just fine,
then without warning, your IPsec SAs go down and take your tunnels
with them. The most likely explanation for this is that you’ve config-
ured Certificate Revocation List (CRL) checking but something
external to the SRX has changed and the CRL Distribution Point
(CDP) can no longer be accessed to refresh the locally cached CRL.
This is not a sign of buggy software; it’s a self-preservation mechanism
and a security compliance requirement. The behavior of the SRX is
determined through standards such as RFC 5280 (“Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile”).
 Chapter 8: Troubleshooting ADVPN 77

The timing and sequence of events can be interesting, too. Certificates

are only used to authenticate phase 1 (IKE), so it’s conceivable that if
you’ve got a problem accessing the CDP, IPsec SAs could begin to fail
in a staggered manner, rather than all at once.
Despite all this potential doom and gloom, Junos provides all the tools
you need to troubleshoot PKI whether you’re in the test, build, or
operate phase.
We briefly covered the PKI-related syslog messages in the Syslog
section of this chapter. If you’re experiencing an issue with PKI and the
syslog messages just aren’t giving you enough to go on, you need to dig
a bit deeper, into the world of traceoptions.
Here’s a configuration example of enabling traceoptions for PKI:
admin@srx650-01> show configuration security pki traceoptions
file pki-trace;
flag all;

Once that’s committed, the local file /var/log/pki-trace is going to

start filling up with very “chatty” messages like these ones:
Feb 26 22:42:54 CRL check local cert name:: /C=AU/ST=ACT/L=Canberra/O=Juniper
Networks/CN=lab-CA01
Feb 26 22:42:54 CRL check CA cert name:: /C=AU/ST=ACT/L=Canberra/O=Juniper Networks/
CN=lab-CA01
Feb 26 22:42:54 CRL Check for: /C=AU/DC=sec0001/ST=ACT/L=Canberra/CN=srx650-01.
sec0001.lab.jnprcbr.local
Feb 26 22:42:54 pkid crl issuer found
Feb 26 22:42:54 found ee cert by subject for id <ca01-root>
Feb 26 22:42:54 pkid ee cert found in lhash
[...]

These trace outputs are clearly not as easy to digest as regular syslog
messages – the messages are intended for the Juniper software engi-
neers that wrote the code in the first place – but they do reveal a great
deal about what’s going on under the covers.

CAUTION! Enabling traceoptions places additional load on the SRX control

plane. Where possible, avoid enabling traceoptions in a production
environment, and preferably work under the guidance of JTAC.
 78 Day One:ADVPN Design and Implementation
Chapter 9

Architectural Blueprints

ADVPN can be included in a number of different design topologies. In

the simplest scenario, a single SRX suggester is deployed to support
SRX partner devices deployed at branch or edge sites. As high avail-
ability and support for multiple routing instances is incorporated,
complexity increases.

Best Common Practices

There are some best common practices (BCPs) relating to IPsec VPN
management on Juniper Networks platforms. The following BCPs are
not ADVPN specific per se, but can certainly help reduce configuration
complexity and help with troubleshooting.

Secure Tunnel Numbering

The secure tunnel virtual interface (st0) can have one or more logical
units configured, each with its own numeric identifier between 0 and
1073741823. That’s a big range, with plenty of potential to allow you
to embed some meaning into the interface numbering. This becomes
particularly useful when you deploy virtual routing instances.
Here are some ideas for st0 unit numbering:
Assign a three digit unique identifier to every SRX gateway in your
WAN (for example, 1-999) and use this ID in the st0 unit numbering
for all connections to that SRX. For example, if your primary hub SRX
has been assigned ID 128, you could number all of the spoke SRX
interfaces that connect to the hub as st0.128.
 80 Day One: ADVPN Design and Implementation

Expanding upon the first idea, if you’re using virtual routing instances
with multiple parallel sets of secure tunnel interfaces, you could assign
a routing instance ID to each instance and use it in the st0 unit number-
ing as a prefix. This would result in spoke SRX secure tunnel interfaces
that connect to the hub in routing instance 1 being configured as
st0.1128, and for routing instance 2 it would be st0.2128.
For ADVPN, given the multipoint nature of the secure tunnels,
consider assigning each ADVPN instance a numeric ID. For ADVPN
instance 1, you would number the st0 interfaces on the suggesters and
partners as st0.1000, and for ADVPN instance 2 you would configure
st0.2000.
With that much space to play with, you can embed a lot of operation-
ally useful information in tunnel interface numbering. Just don’t get
carried away – keep it simple, and make sure you’re not creating too
much work for yourself.

Configuration Annotation
Junos allows you to put a comment against most elements of the
configuration using the annotate command. This can be very useful for
“in-config” documentation.
Have you ever deployed a firewall filter that does something non-
obvious? Don’t be “that” colleague; insert an annotation that explains
the “five Ws”:
1. Who? (Bob did it)
2. What? (Firewall filter to stop Application Z from reaching the
Internet)
3. Where? (On all branch SRX gateways in the APAC region)
4. Why? (Application Z traffic from APAC should not reach the
Internet per the company’s security policy)
5. When? (On the 1st of April, under change ref. CHG12345)
The possibilities are endless!

Configuration Object Naming

Many of the elements used to build ADVPN configurations require
you to enter arbitrary names. For example, IKE policies and gateways,
and IPsec proposals and VPN definitions all require the configured
objects to be named.
 Chapter 9: Architectural Blueprints 81

When naming objects, use the case that allows you to differentiate
between Junos configuration statements and the named object(s).
Perhaps ALLUPPERCASE works for you, or maybe you prefer the
readability of thingsNamedUsingCamelCase, or maybe you’d just like
to insert an organization-specific prefix, like the company’s acronym,
into the names of everything you’ve named.
Whichever method you choose, document your decision somewhere,
and apply it consistently. The benefits of consistent naming become
invaluable during significant changes. Coupled with Junos CLI func-
tionality like “replace pattern,” it becomes very easy to make changes
across the entire configuration without accidentally leaving something
out and causing an unplanned outage.

Configuration Object Descriptions

Separate from the object naming BCP, many configuration elements in
Junos allow a description to be applied. Some examples are interfaces
(at both the physical and logical level), routing instances, MPLS LSPs,
NAT pools, and BGP groups. Similarly, the SNMP agent’s contact and/
or location field values can be used as a description field.
Just as with the tunnel numbering BCP, descriptions provide you with a
free text field to use as you see fit. You can use them as they were
originally intended – as simple, one-line descriptions – or you can come
up with your own structure for the field and embed operationally
useful data.

Common Design Topologies

Now that we’ve discussed some generic BCPs, let’s take a look at some
common design topologies – architectural blueprints – for ADVPN:
„„ Suggester Designs
„„ Single Suggester
„„ Dual Suggester
„„ Partner Designs
„„ Dual Partner
„„ Virtualized Routing Support
 82 Day One: ADVPN Design and Implementation

Suggester Designs: Single Suggester

This design is suitable for small networks and networks without the
requirement or budget for high availability. A single SRX services
gateway is deployed at the head office or data center location to
provide the ADVPN suggester function, and a single ADVPN overlay
is established between it and the ADVPN partner SRX gateways
deployed throughout the WAN, as shown in Figure 9.1.
The control tunnel configurations are deployed in a traditional
hub-and-spoke layout but the traffic flow and bandwidth optimization
benefits of ADVPN can still be realized.
This suggester blueprint can be coupled with either the single or dual
partner blueprint (explained below), however without any suggester
redundancy, having redundant partners only protects against failures
at the remote branch site.

Figure 9.1 Suggester Single Hub Blueprint

Key Takeaways

This is the simplest form of ADVPN – it’s easy to deploy and there
aren’t many decisions that need to be made. It’s great for networks of
all sizes, from a small business with a handful of sites, to a large
retailer with up to 512 locations.
Here are some key takeaways for you to remember:
„„ Secure tunnel interfaces (st0.*) are assigned IP addresses from a
single IP subnet and each node in the ADVPN, regardless of its
 Chapter 9: Architectural Blueprints 83

role (partner or suggester), has only one tunnel interface associ-

ated with the ADVPN.
„„ The suggester node has a single IKE configuration and a single
multipoint IPsec VPN configuration.
„„ Routing protocol configuration is very straightforward. Oppor-
tunities for tuning are limited as each node in the ADVPN has
only a single tunnel interface defined.
„„ This blueprint doesn’t include any suggester redundancy – if the
suggester is offline, partners won’t be able to reach network desti-
nations located behind the suggester, nor will they be able to
communicate with networks behind other partners.
„„ Despite the lack of redundancy in the ADVPN itself, backup
paths or tunnels via a separate interface (for example, cellular) in
each partner can still be configured separately to provide connec-
tivity in the event that the primary path becomes unavailable.
„„ Multiple routing instances can be supported with this blueprint.

Suggester Configuration
Here are some general notes about the configuration that follows:
„„ It uses apply-groups to enable GRES and ADVPN, and to
standardize the way OSPF and BFD are configured on secure
tunnel interfaces.
„„ It uses virtual routing instances to separate WAN/carrier routing
information from your organization’s routing information.
„„ It uses a default security policy of permit-all. This is probably
not desirable for many environments but in this lab, it’s okay.
„„ It does not include any LAN-facing interface definitions.
groups {
GROUP-GRES-CFG {
routing-instances {
<*> {
routing-options {
graceful-restart;
}
}
}
}
GROUP-ADVPN-CFG {
security {
ike {
gateway <*> {
advpn {
partner {
 84 Day One: ADVPN Design and Implementation

disable;
}
}
}
}
}
}
GROUP-OSPF-TUNNEL-CFG {
routing-instances {
<*> {
protocols {
ospf {
area <*> {
interface <st0.*> {
interface-type p2mp;
demand-circuit;
dynamic-neighbors;
bfd-liveness-detection {
minimum-interval 1000;
multiplier 3;
}
}
}
}
}
}
}
}
}
system {
host-name Hub-1;
domain-name lab.jnprcbr.local;
time-zone EST-10EDT-11,M10.1.0/2,M4.1.0/3;
default-address-selection;
root-authentication {
encrypted-password "<REMOVED>"; ## SECRET-DATA
}
name-server {
172.27.160.221;
}
services {
ssh {
protocol-version v2;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
 Chapter 9: Architectural Blueprints 85

file traffic-log {
any any;
match RT_FLOW_SESSION;
explicit-priority;
}
file ospf-log {
any any;
match "OSPF|BFD";
explicit-priority;
}
file vpn-log {
any any;
match "KMD|SHORTCUT";
explicit-priority;
}
file pki-log {
daemon any;
match PKID;
explicit-priority;
}
}
ntp {
boot-server 172.27.160.1;
server 172.27.160.1;
}
}
security {
pki {
ca-profile ca01-root {
ca-identity lab-CA01;
revocation-check {
use-crl;
crl {
url "http://ca01.lab.jnprcbr.local/CertEnroll/lab-CA01.crl";
}
}
}
}
ike {
apply-groups GROUP-ADVPN-CFG;
policy ADVPN-IKEPOL-SUITEB-VR0001 {
mode main;
certificate {
local-certificate srx650-01_0001;
}
proposal-set suiteb-gcm-256;
}
gateway ADVPN-IKEGW-SPOKES-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
dynamic {
distinguished-name {
wildcard DC=sec0001;
}
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
 86 Day One: ADVPN Design and Implementation

version v2-only;
}
}
ipsec {
policy ADVPN-IPSECPOL-SUITEB-SHARED {
proposal-set suiteb-gcm-256;
}
vpn ADVPN-VPN-SPOKES-VR0001 {
bind-interface st0.1001;
ike {
gateway ADVPN-IKEGW-SPOKES-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
}
}
}
policies {
default-policy {
permit-all;
}
}
zones {
security-zone WAN {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ike;
}
protocols {
bgp;
}
}
}
}
}
security-zone VR0001-zone {
interfaces {
st0.1001 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/24;
}
 Chapter 9: Architectural Blueprints 87

}
}
st0 {
unit 1001 {
multipoint;
family inet {
address 10.127.101.1/24;
}
}
}
}
routing-options {
graceful-restart;
}
policy-options {
policy-statement CE_PE_BGP_EXPORT {
term EXPORT_IKE_PEER_PREFIXES {
from interface [ ge-0/0/0.0 ];
then accept;
}
}
}
routing-instances {
apply-groups [ GROUP-GRES-CFG GROUP-OSPF-TUNNEL-CFG ];
VR0001 {
instance-type virtual-router;
interface st0.1001;
protocols {
ospf {
area 0.0.0.0 {
interface st0.1001 {
metric 101;
}
}
}
}
}
WAN {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
autonomous-system 65000;
}
protocols {
bgp {
log-updown;
group CE_PE_BGP {
export CE_PE_BGP_EXPORT;
peer-as 64512;
neighbor 10.0.0.1;
}
}
}
}
}
 88 Day One: ADVPN Design and Implementation

Suggester Designs: Dual Suggester Use Case

Deploying a second SRX gateway to act as an ADVPN suggester adds
redundancy to the network infrastructure and opens up the possibility
to design resiliency into your WAN. The ADVPN suggesters don’t have
to be physically co-located, and for the purposes of enabling spoke-to-
spoke connectivity, they don’t need to be directly connected to each
other, either. The suggester nodes might be co-located within a single
data center, with redundant connectivity back into the data center
LAN, or they might be located at geographically separated locations.
As long as each suggester has active control tunnels to the two partners
using it for transit, the suggester can send the suggestion to build a
shortcut tunnel.
By using this blueprint, you’re no longer reliant on a single physical
device to be up and running for shortcut tunnels to be formed between
partner nodes.

Key Takeaways
This suggester blueprint is the most commonly deployed design for
organizations requiring high availability. In terms of scaling, because
the number of supported tunnels varies between platforms, this design
scales identically to the design in the Single Suggester blueprint – any-
where from 2 to 512 partner nodes are supported. Here are the key
takeaways:
„„ Because there are multiple tunnel interfaces defined on the
partner nodes, routing protocol behavior should be tuned to
assure deterministic behavior in the event of an outage (planned
or unplanned).

Figure 9.2 Suggester Dual Hub Blueprint

 Chapter 9: Architectural Blueprints 89

„„ The configuration on the suggester nodes is simple – it’s the same

as it is in the Single Suggester blueprint above – but the partner
nodes require additional IKE, IPsec, and routing protocol
configuration because they have multiple control tunnels defined
(one to each suggester).
„„ This blueprint includes redundant suggesters. If one of the
suggesters goes offline for any reason, shortcut tunnels can still
be established between partner nodes. Existing shortcut tunnels
established prior to the outage remain unaffected in this case.
„„ Multiple routing instances can be supported.

Suggester Configurations

Suggester Configuration Hub 1

groups {
GROUP-GRES-CFG {
routing-instances {
<*> {
routing-options {
graceful-restart;
}
}
}
}
GROUP-ADVPN-CFG {
security {
ike {
gateway <*> {
advpn {
partner {
disable;
}
}
}
}
}
}
GROUP-OSPF-TUNNEL-CFG {
routing-instances {
<*> {
protocols {
ospf {
area <*> {
interface <st0.*> {
interface-type p2mp;
demand-circuit;
bfd-liveness-detection {
minimum-interval 1000;
multiplier 3;
}
 90 Day One: ADVPN Design and Implementation

dynamic-neighbors;
}
}
}
}
}
}
}
}
system {
host-name Hub-1;
domain-name lab.jnprcbr.local;
time-zone EST-10EDT-11,M10.1.0/2,M4.1.0/3;
default-address-selection;
root-authentication {
encrypted-password "<REMOVED>"; ## SECRET-DATA
}
name-server {
172.27.160.221;
}
services {
ssh {
protocol-version v2;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file traffic-log {
any any;
match RT_FLOW_SESSION;
explicit-priority;
}
file ospf-log {
any any;
match "OSPF|BFD";
explicit-priority;
}
file vpn-log {
any any;
match "KMD|SHORTCUT";
explicit-priority;
}
file pki-log {
 Chapter 9: Architectural Blueprints 91

daemon any;
match PKID;
explicit-priority;
}
}
ntp {
boot-server 172.27.160.1;
server 172.27.160.1;
}
}
security {
pki {
ca-profile ca01-root {
ca-identity lab-CA01;
revocation-check {
use-crl;
crl {
url "http://ca01.lab.jnprcbr.local/CertEnroll/lab-CA01.crl";
}
}
}
}
ike {
apply-groups GROUP-ADVPN-CFG;
policy ADVPN-IKEPOL-SUITEB-VR0001 {
mode main;
certificate {
local-certificate srx650-01_0001;
}
proposal-set suiteb-gcm-256;
}
gateway ADVPN-IKEGW-SPOKES-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
dynamic {
distinguished-name {
wildcard DC=sec0001;
}
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
version v2-only;
}
}
ipsec {
policy ADVPN-IPSECPOL-SUITEB-SHARED {
proposal-set suiteb-gcm-256;
}
vpn ADVPN-VPN-SPOKES-VR0001 {
bind-interface st0.1001;
ike {
gateway ADVPN-IKEGW-SPOKES-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
 92 Day One: ADVPN Design and Implementation

}
}
}
policies {
default-policy {
permit-all;
}
}
zones {
security-zone WAN {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ike;
}
protocols {
bgp;
}
}
}
}
}
security-zone VR0001-zone {
interfaces {
st0.1001 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/24;
}
}
}
st0 {
unit 1001 {
multipoint;
family inet {
address 10.127.101.1/24;
}
 Chapter 9: Architectural Blueprints 93

}
}
}
routing-options {
graceful-restart;
}
policy-options {
policy-statement CE_PE_BGP_EXPORT {
term EXPORT_IKE_PEER_PREFIXES {
from interface ge-0/0/0.0;
then accept;
}
}
}
routing-instances {
apply-groups [ GROUP-GRES-CFG GROUP-OSPF-TUNNEL-CFG ];
VR0001 {
instance-type virtual-router;
interface st0.1001;
protocols {
ospf {
area 0.0.0.0 {
interface st0.1001 {
metric 101;
}
}
}
}
}
WAN {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
autonomous-system 65000;
}
protocols {
bgp {
log-updown;
group CE_PE_BGP {
export CE_PE_BGP_EXPORT;
peer-as 64512;
neighbor 10.0.0.1;
}
}
}
}
}
 94 Day One: ADVPN Design and Implementation

Suggester Configuration Hub 2

groups {
GROUP-GRES-CFG {
routing-instances {
<*> {
routing-options {
graceful-restart;
}
}
}
}
GROUP-ADVPN-CFG {
security {
ike {
gateway <*> {
advpn {
partner {
disable;
}
}
}
}
}
}
GROUP-OSPF-TUNNEL-CFG {
routing-instances {
<*> {
protocols {
ospf {
area <*> {
interface <st0.*> {
interface-type p2mp;
demand-circuit;
bfd-liveness-detection {
minimum-interval 1000;
multiplier 3;
}
dynamic-neighbors;
}
}
}
}
}
}
}
}
system {
host-name Hub-2;
domain-name lab.jnprcbr.local;
time-zone EST-10EDT-11,M10.1.0/2,M4.1.0/3;
default-address-selection;
root-authentication {
encrypted-password "<REMOVED>"; ## SECRET-DATA
}
name-server {
 Chapter 9: Architectural Blueprints 95

172.27.160.221;
}
services {
ssh {
protocol-version v2;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file traffic-log {
any any;
match RT_FLOW_SESSION;
explicit-priority;
}
file ospf-log {
any any;
match "OSPF|BFD";
explicit-priority;
}
file vpn-log {
any any;
match "KMD|SHORTCUT";
explicit-priority;
}
file pki-log {
daemon any;
match PKID;
explicit-priority;
}
}
ntp {
boot-server 172.27.160.1;
server 172.27.160.1;
}
}
security {
pki {
ca-profile ca01-root {
ca-identity lab-CA01;
revocation-check {
use-crl;
crl {
url "http://ca01.lab.jnprcbr.local/CertEnroll/lab-CA01.crl";
}
}
}
 96 Day One: ADVPN Design and Implementation

}
ike {
apply-groups GROUP-ADVPN-CFG;
policy ADVPN-IKEPOL-SUITEB-VR0001 {
mode main;
certificate {
local-certificate srx650-02_0001;
}
proposal-set suiteb-gcm-256;
}
gateway ADVPN-IKEGW-SPOKES-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
dynamic {
distinguished-name {
wildcard DC=sec0001;
}
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
version v2-only;
}
}
ipsec {
policy ADVPN-IPSECPOL-SUITEB-SHARED {
proposal-set suiteb-gcm-256;
}
vpn ADVPN-VPN-SPOKES-VR0001 {
bind-interface st0.1001;
ike {
gateway ADVPN-IKEGW-SPOKES-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
}
}
}
policies {
default-policy {
permit-all;
}
}
zones {
security-zone WAN {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ike;
}
protocols {
bgp;
}
}
}
}
}
security-zone VR0001-zone {
 Chapter 9: Architectural Blueprints 97

interfaces {
st0.1001 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.1.2/24;
}
}
}
st0 {
unit 1001 {
multipoint;
family inet {
address 10.127.102.2/24;
}
}
}
}
routing-options {
graceful-restart;
}
policy-options {
policy-statement CE_PE_BGP_EXPORT {
term EXPORT_IKE_PEER_PREFIXES {
from interface ge-0/0/0.0;
then accept;
}
}
}
routing-instances {
apply-groups [ GROUP-GRES-CFG GROUP-OSPF-TUNNEL-CFG ];
VR0001 {
instance-type virtual-router;
interface st0.1001;
protocols {
ospf {
area 0.0.0.0 {
interface st0.1001 {
metric 102;
}
}
}
 98 Day One: ADVPN Design and Implementation

}
}
WAN {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
autonomous-system 65001;
}
protocols {
bgp {
log-updown;
group CE_PE_BGP {
export CE_PE_BGP_EXPORT;
peer-as 64512;
neighbor 10.0.1.1;
}
}
}
}
}

Partner Designs: Dual Partner Use Case

The dual partner blueprint is intended for remote sites where the
availability of the network justifies the cost of deploying additional
hardware. It provides for traffic to flow over the WAN if a partner
node is taken offline, or if a partner node fails.
When deploying a second partner SRX, one decision you’re forced to
make relates to ADVPN cloud membership.
If you’ve opted to go with the dual hub blueprint described earlier, you
have two ADVPN clouds. Should each partner be a member of both,
or should the first partner be part of cloud 1, and the second partner a
part of cloud 2?

Dual Cloud Membership

Making each partner SRX a member of both ADVPN clouds means
that a failure at the suggester end doesn’t trigger a failover at the
partner end. For example, if the suggester for ADVPN cloud 1 were to
fail, all of the tunnels from that suggester to its partners would also go
down. From the partner’s perspective, it can still reach destinations it
knows about via the suggester associated with ADVPN cloud 2.

Single Cloud Membership

Making the primary partner SRX a member of ADVPN cloud 1, and
the secondary partner SRX a member of ADVPN cloud 2, means that
a suggester failure in cloud 1 triggers a network-wide failover to
 Chapter 9: Architectural Blueprints 99

secondary partner SRXs. Depending on the way the underlying

transport is provisioned, this may be undesirable (e.g. if your second-
ary partner SRXs are connected to the WAN via a lower speed and/or
higher latency access method).

Figure 9.3 Dual Partner Blueprint

This blueprint simply extends the Single Partner design by adding a

second SRX device acting as an ADVPN partner node at the remote
site.

Key Takeaways
„„ In most cases, deploying a second partner SRX implies that there
are multiple suggester SRX gateways deployed, either in a single
ADVPN cloud or multiple ADVPN clouds.
„„ Deploying a second partner SRX at your remote branch sites
provides increased availability during planned and unplanned
outages.
„„ The branch LAN facing interfaces of the partner SRX gateways
can be configured routed interfaces, or in a common L2 segment
with VRRP.
„„ Branch LAN-to-WAN traffic flows can be controlled using
routing protocol metrics, or if using VRRP, via VRRP priority
and route tracking.
„„ WAN-to-Branch LAN traffic flows can be controlled using
routing protocol metrics.
 100 Day One: ADVPN Design and Implementation

„„ The partner SRX gateways can be made a member of both

ADVPN clouds, or each partner SRX can be made a member of
separate ADVPN clouds.
Here are some general notes about the configuration that follows:
„„ Uses apply-groups to enable GRES and ADVPN, and to stan-
dardize the way OSPF and BFD are configured on secure tunnel
interfaces.
„„ Uses virtual routing instances to separate WAN/carrier routing
information from your organisation’s routing information.
„„ Uses a default security policy of permit-all. This is probably not
desirable for many environments but in this lab, it’s okay.
„„ Does not include any LAN-facing interface definitions.

Partner Configuration Spoke 1

groups {
GROUP-GRES-CFG {
routing-instances {
<*> {
routing-options {
graceful-restart;
}
}
}
}
GROUP-ADVPN-CFG {
security {
ike {
gateway <*> {
advpn {
suggester {
disable;
}
}
}
}
}
}
GROUP-OSPF-TUNNEL-CFG {
routing-instances {
<*> {
protocols {
ospf {
area <*> {
interface <st0.*> {
interface-type p2mp;
demand-circuit;
bfd-liveness-detection {
minimum-interval 1000;
multiplier 3;
}
 Chapter 9: Architectural Blueprints 101

dynamic-neighbors;
}
}
}
}
}
}
}
}
system {
host-name Spoke-1;
domain-name lab.jnprcbr.local;
time-zone EST-10EDT-11,M10.1.0/2,M4.1.0/3;
default-address-selection;
root-authentication {
encrypted-password "<REMOVED>"; ## SECRET-DATA
}
name-server {
172.27.160.221;
}
services {
ssh {
protocol-version v2;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file traffic-log {
any any;
match RT_FLOW_SESSION;
explicit-priority;
}
file ospf-log {
any any;
match "OSPF|BFD";
explicit-priority;
}
file vpn-log {
any any;
match "KMD|SHORTCUT";
explicit-priority;
}
file pki-log {
daemon any;
match PKID;
explicit-priority;
 102 Day One: ADVPN Design and Implementation

}
}
ntp {
boot-server 172.27.160.1;
server 172.27.160.1;
}
}
security {
pki {
ca-profile ca01-root {
ca-identity lab-CA01;
revocation-check {
use-crl;
crl {
url "http://ca01.lab.jnprcbr.local/CertEnroll/lab-CA01.crl";
}
}
}
}
ike {
apply-groups GROUP-ADVPN-CFG;
policy ADVPN-IKEPOL-SUITEB-VR0001 {
mode main;
certificate {
local-certificate srx550-01_0001;
}
proposal-set suiteb-gcm-256;
}
gateway ADVPN-IKEGW-HUB1-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
address 10.0.0.2;
local-identity distinguished-name;
remote-identity distinguished-name container CN=srx650-01.sec0001.lab.
jnprcbr.local;
external-interface ge-0/0/0.0;
version v2-only;
}
gateway ADVPN-IKEGW-HUB2-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
address 10.0.1.2;
local-identity distinguished-name;
remote-identity distinguished-name container CN=srx650-02.sec0001.lab.
jnprcbr.local;
external-interface ge-0/0/0.0;
version v2-only;
}
}
ipsec {
policy ADVPN-IPSECPOL-SUITEB-SHARED {
proposal-set suiteb-gcm-256;
}
vpn ADVPN-VPN-HUB1-VR0001 {
bind-interface st0.1001;
ike {
gateway ADVPN-IKEGW-HUB1-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
 Chapter 9: Architectural Blueprints 103

}
establish-tunnels immediately;
}
vpn ADVPN-VPN-HUB2-VR0001 {
bind-interface st0.1002;
ike {
gateway ADVPN-IKEGW-HUB2-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
}
establish-tunnels immediately;
}
}
policies {
default-policy {
permit-all;
}
}
zones {
security-zone WAN {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ike;
}
protocols {
bgp;
}
}
}
}
}
security-zone VR0001-zone {
interfaces {
st0.1001 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
st0.1002 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/1.0 {
host-inbound-traffic {
 104 Day One: ADVPN Design and Implementation

system-services {
all;
}
protocols {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.2.2/24;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.255.100.3/24 {
vrrp-group 1 {
virtual-address 10.255.100.254;
priority 110;
accept-data;
}
}
}
}
}
st0 {
unit 1001 {
multipoint;
family inet {
address 10.127.101.3/24;
}
}
unit 1002 {
multipoint;
family inet {
address 10.127.102.3/24;
}
}
}
}
routing-options {
graceful-restart;
}
policy-options {
policy-statement CE_PE_BGP_EXPORT {
term EXPORT_IKE_PEER_PREFIXES {
from interface ge-0/0/0.0;
then accept;
 Chapter 9: Architectural Blueprints 105

}
}
}
routing-instances {
apply-groups [ GROUP-GRES-CFG GROUP-OSPF-TUNNEL-CFG ];
VR0001 {
instance-type virtual-router;
interface ge-0/0/1.0;
interface st0.1001;
interface st0.1002;
protocols {
ospf {
area 0.0.0.0 {
interface st0.1001 {
metric 101;
}
interface st0.1002 {
metric 102;
}
interface ge-0/0/1.0 {
passive;
}
}
}
}
}
WAN {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
autonomous-system 65002;
}
protocols {
bgp {
log-updown;
group CE_PE_BGP {
export CE_PE_BGP_EXPORT;
peer-as 64512;
neighbor 10.0.2.1;
}
}
}
}
}
 106 Day One: ADVPN Design and Implementation

Partner Configuration Spoke 2

groups {
GROUP-GRES-CFG {
routing-instances {
<*> {
routing-options {
graceful-restart;
}
}
}
}
GROUP-ADVPN-CFG {
security {
ike {
gateway <*> {
advpn {
suggester {
disable;
}
}
}
}
}
}
GROUP-OSPF-TUNNEL-CFG {
routing-instances {
<*> {
protocols {
ospf {
area <*> {
interface <st0.*> {
interface-type p2mp;
demand-circuit;
bfd-liveness-detection {
minimum-interval 1000;
multiplier 3;
}
dynamic-neighbors;
}
}
}
}
}
}
}
}
system {
host-name Spoke-2;
domain-name lab.jnprcbr.local;
time-zone EST-10EDT-11,M10.1.0/2,M4.1.0/3;
default-address-selection;
root-authentication {
encrypted-password "<REMOVED>"; ## SECRET-DATA
}
name-server {
 Chapter 9: Architectural Blueprints 107

172.27.160.221;
}
services {
ssh {
protocol-version v2;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file traffic-log {
any any;
match RT_FLOW_SESSION;
explicit-priority;
}
file ospf-log {
any any;
match "OSPF|BFD";
explicit-priority;
}
file vpn-log {
any any;
match "KMD|SHORTCUT";
explicit-priority;
}
file pki-log {
daemon any;
match PKID;
explicit-priority;
}
}
ntp {
boot-server 172.27.160.1;
server 172.27.160.1;
}
}
security {
pki {
ca-profile ca01-root {
ca-identity lab-CA01;
revocation-check {
use-crl;
crl {
url "http://ca01.lab.jnprcbr.local/CertEnroll/lab-CA01.crl";
}
}
}
 108 Day One: ADVPN Design and Implementation

}
ike {
apply-groups GROUP-ADVPN-CFG;
policy ADVPN-IKEPOL-SUITEB-VR0001 {
mode main;
certificate {
local-certificate srx550-02_0001;
}
proposal-set suiteb-gcm-256;
}
gateway ADVPN-IKEGW-HUB1-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
address 10.0.0.2;
local-identity distinguished-name;
remote-identity distinguished-name container CN=srx650-01.sec0001.lab.
jnprcbr.local;
external-interface ge-0/0/0.0;
version v2-only;
}
gateway ADVPN-IKEGW-HUB2-VR0001 {
ike-policy ADVPN-IKEPOL-SUITEB-VR0001;
address 10.0.1.2;
local-identity distinguished-name;
remote-identity distinguished-name container CN=srx650-02.sec0001.lab.
jnprcbr.local;
external-interface ge-0/0/0.0;
version v2-only;
}
}
ipsec {
policy ADVPN-IPSECPOL-SUITEB-SHARED {
proposal-set suiteb-gcm-256;
}
vpn ADVPN-VPN-HUB1-VR0001 {
bind-interface st0.1001;
ike {
gateway ADVPN-IKEGW-HUB1-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
}
establish-tunnels immediately;
}
vpn ADVPN-VPN-HUB2-VR0001 {
bind-interface st0.1002;
ike {
gateway ADVPN-IKEGW-HUB2-VR0001;
ipsec-policy ADVPN-IPSECPOL-SUITEB-SHARED;
}
establish-tunnels immediately;
}
}
policies {
default-policy {
permit-all;
}
}
zones {
 Chapter 9: Architectural Blueprints 109

security-zone WAN {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
ike;
}
protocols {
bgp;
}
}
}
}
}
security-zone VR0001-zone {
interfaces {
st0.1001 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
st0.1002 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
ge-0/0/1.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.3.2/24;
 110 Day One: ADVPN Design and Implementation

}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.255.100.4/24 {
vrrp-group 1 {
virtual-address 10.255.100.254;
accept-data;
}
}
}
}
}
st0 {
unit 1001 {
multipoint;
family inet {
address 10.127.101.4/24;
}
}
unit 1002 {
multipoint;
family inet {
address 10.127.102.4/24;
}
}
}
}
routing-options {
graceful-restart;
}
policy-options {
policy-statement CE_PE_BGP_EXPORT {
term EXPORT_IKE_PEER_PREFIXES {
from interface ge-0/0/0.0;
then accept;
}
}
}
routing-instances {
apply-groups [ GROUP-GRES-CFG GROUP-OSPF-TUNNEL-CFG ];
VR0001 {
instance-type virtual-router;
interface ge-0/0/1.0;
interface st0.1001;
interface st0.1002;
protocols {
ospf {
area 0.0.0.0 {
interface st0.1001 {
metric 101;
}
interface st0.1002 {
metric 102;
}
 Chapter 9: Architectural Blueprints 111

interface ge-0/0/1.0 {
passive;
metric 1000;
}
}
}
}
}
WAN {
instance-type virtual-router;
interface ge-0/0/0.0;
routing-options {
autonomous-system 65003;
}
protocols {
bgp {
log-updown;
group CE_PE_BGP {
export CE_PE_BGP_EXPORT;
peer-as 64512;
neighbor 10.0.3.1;
}
}
}
}
}

Virtualized Routing Support

Support for virtual routers (virtual routing instances, also known as
VRF Lite) can be added to any blueprint described in this chapter. If
you’re not already familiar with virtual routers, here’s a quick review:
„„ Routing instances provide the ability to separate routing infor-
mation into separate “virtual” tables
„„ In Junos, the default/master IPv4 routing table is known as
“inet.0”
„„ In the absence of additional virtual routing instances, all IPv4
routes are installed into the inet.0 table
„„ With virtual routing instances, routes within each instance are
installed into “<instance_name>.inet.0”
„„ Overlapping IPv4 addresses are permitted (therefore, the same
routing destination prefixes in multiple tables)
„„ There is a one-to-one mapping between an interface (IFL) and a
routing instance
Routing table virtualization is used extensively in service provider
networks; however, over the past years, the same techniques have been
deployed more and more in enterprise network deployments.
 112 Day One: ADVPN Design and Implementation

The use cases for virtualized routing are wide and varied – the tech-
nique might be used for the age-old requirement to separate the com-
pany’s marketing and engineering business units, or it could be used for
something a bit more realistic, for example, where you need to separate
routing information (and therefore traffic flows) carried within a guest
access/BYOD network, from the main corporate network.
Junos has supported IPsec in combination with virtual routing since the
10.0 release; it’s a proven technology in numerous networks around the
world. Once you’ve wrapped your head around the concept of one
physical router being carved up into multiple virtual routers, coupling it
with ADVPN is pretty straightforward.
Here are a few key points to consider when coupling IPsec (with or
without ADVPN) with virtual routing:
„„ One or more secure tunnel (st0.x) logical interfaces are created
and assigned to each routing instance; a single interface (for
example, st0.10) can’t be assigned into more than one routing-
instance.
„„ IKE configurations, such as policies, can be shared between
routing instances but in some cases, your company’s IT security
policy may mandate separation (for example, the use of different
local X.509 certificates for authentication). That’s fine – it’s
supported, too!
„„ Sharing IKE policies between IKE gateways covering multiple
routing instances requires unique external-interface values, or
the use of the local-address statement.
„„ A single SRX security zone can’t have interfaces assigned from
multiple routing instances. For example, you can’t have a single
“trust” security zone with ge-0/0/0.0 from routing instance A,
and ge-0/0/1.0 from routing instance B, as members. The easiest
way to think about this is that each routing instance needs its very
own set of security zones.
„„ Finally, careful consideration needs to be given to where (there-
fore, within which routing instance) your network management
systems are placed. Best practice is to keep management routes in
the default/master table, inet.0. The implication here is that
control plane protocols such as NTP, RADIUS, syslog, and SNMP
should be able to communicate with peers by routing inside
inet.0.
That’s it. A four-minute review of virtualized routing instances, and
remember that the Juniper documentation suite is a good source of
information: http://www.juniper.net/documentation.
Appendices

Appendix 1: Installing Microsoft Active

Directory Certificate Services (ADCS)

Most large organizations will have a dedicated staff of security person-

nel to take care of security policies and monitoring systems, but you’re
a networking person and this is a Day One book! You just need to get
a Certificate Authority (CA) up and running so that you can meet the
requirements of building your first ADVPN!
This appendix steps you through the configuration of a CA running on
the Windows Server OS. You’re not going to emerge from this chapter
as a subject matter expert on CAs, but it should provide you with
enough to get you up and running in your lab. If you’re working on a
small network, you’ll know what you need to do for your production
rollout. If you’re in a larger organization, you’ll be able to articulate
ADVPN’s PKI requirements to your organization’s security expert so
that, if required, they can reconfigure the existing CA to support SRX
device certificates.
To make things interesting, you’re going to build the CA to use Suite B
compliant algorithms. The only downside to this approach is that, at
the time this book was written, it rules out the possibility of automati-
cally enrolling (and auto-reenrolling) devices with the CA. The reason
for that is that the SCEP protocol relies on RSA operations, and in a
Suite B configuration, the CA does not have an RSA keypair. You’ll be
manually enrolling devices, for now.
 114 Day One: ADVPN Design and Implementation

Lab Environment and Installation Prerequisites

Here’s what you’ll need in your lab:
„„ The Active Directory domain is ready (our lab domain is named
lab.jnprbcr.local in this book)
„„ Host “dc01” is a domain controller running Windows Server
2012 R2
„„ Host “ca01” is a domain member server running Windows
Server 2012 R2
„„ System time synchronized (ideally by configuring the domain
controller to synchronize its clock with an NTP server – domain
member servers will synchronize using the domain hierarchy)

Installation Goals
And here’s what to expect when completing this chapter in your lab:
„„ You’ve installed ADCS roles onto the “ca01” domain member
server
„„ You’ve configured the CA to be an Enterprise Root CA
„„ You are able to submit certificate requests and download issued
certificates via the ADCS web interface
„„ You are able to perform certificate revocation status checking
from the SRX via the ADCS web interface

Install Active Directory Certificate Services

On your CA host, start up the Server Manager utility and click Manage
> Add Roles and Features.
 Appendices 115

The Add Roles and Features Wizard will launch:

Select role-based or feature-based installation and click Next:

Choose Select a server from the server pool (it should default to the
local system) and click Next:
 116 Day One: ADVPN Design and Implementation

Check the box next to Active Directory Certificate Services role:

Click Add Features on the dialog box that pops up, then click Next:
 Appendices 117

Accept the defaults. Click Next to arrive at the ADCS section of the
wizard:

Once you’ve read the notes, click Next:

Now you need to decide which of the ADCS roles you want to install
on your CA. The first role service – the Certification Authority itself –
is obvious. Review the descriptions alongside each role and make your
selections.
As noted earlier, because you’ll be building a Suite B compliant CA, the
Network Device Enrollment Service (NDES) role – Microsoft’s imple-
mentation of the Simple Certificate Enrollment Protocol (SCEP) –
won’t be installed. Certificate operations will be performed manually,
via the CA’s web interface. You can still choose to install NDES if you
like, as the one remaining benefit – even in a Suite B CA configuration
– is that the CA’s certificate can be downloaded via SCEP, easing the
process of bootstrapping PKI on the SRX. If you decide to do that,
follow one of the many good online guides for installing and configur-
ing NDES.
In this lab, in addition to the CA role service, you’ll add the Certifica-
tion Authority Web Enrollment role service.
 118 Day One: ADVPN Design and Implementation

Once you’ve selected the desired role services, click Next. Click your
way through any additional dialog boxes that ask you to select depen-
dent role services, such as the Web Server (IIS):
 Appendices 119

Once you arrive at the Confirmation page, review your selections and
once satisfied, click Install:

Congratulations! ADCS is installed. Click Close. Now you’ll move on

to the CA configuration.

Configure Active Directory Certificate Services

Open the Credentials window:
 120 Day One: ADVPN Design and Implementation

Enter the user credentials used to configure role services, or accept the
default (the currently logged-on user) and click Next:
On the next screen make sure that Certification Authority and Certifi-
cation Authority Web Enrollment role services are checked then click
Next:

Choose the CA type. In this lab, you’re going to configure an Enter-

prise CA, but for ADVPN purposes, a Standalone CA would do the
job as well. Click Next:
 Appendices 121

This is our first, and only, CA in our lab, so Root CA is the appropriate
selection here. Click Next:
Accept the default: Generate a new private key. Click Next:

OK, now you’re going to diverge from the defaults to ensure that your
CA exits this wizard configured in a Suite B compliant manner.
Drop the cryptographic provider drop-down, choose ECDSA_
P384#Microsoft Software Key Storage Provider. Set the Key length to
384 and choose SHA384 as the hashing algorithm.
Click Next:
 122 Day One: ADVPN Design and Implementation

Choose a name for your CA. In our lab, we’re going to call it “lab-
CA01.” As you type in the name, the distinguished name (DN) preview
of your CA will change. You may have a preference for the way the DN
is built – for example, you may want to include additional detail such
as the locality, state, or company name. Once you’ve named your CA
and you’re happy with the DN, click Next:

Choose the validity period for the CA’s self-signed certificate. Five
years is enough for our lab but your security policy may require
something else. Click Next:
 Appendices 123

If you want to override the default ADCS database locations, do so.

Here they are left to the default values. Click Next:

You’ve almost reached the point of no return. Review the summary of

the selections/settings made during the wizard. Click Configure when
ready:

You’re almost done! Click Close. Everything should now be config-

ured. If there are any errors, investigate and resolve them before
proceeding. The next few steps are to fine tune.
 124 Day One: ADVPN Design and Implementation

CA Configuration for Certificate Revocation List Checking

By default, ADCS will issue certificates to end entities with the Certifi-
cate Revocation List Distribution Point ("CRLDP", or simply "CDP")
value set without an HTTP location. This needs to be changed.
In Server Manager, click Tools > Certification Authority:

Right-click on your CA in the left pane and click Properties:

 Appendices 125

Navigate to the Extensions tab. Find the CRL location that begins with
“http://” and click it once. Ensure that Include in CRLs. Clients use
this to find Delta CRL locations and Include in the CDP extension of
issued certificates options are checked.
In the book’s lab, we also unchecked all boxes in the ldap:// CRL
location. By default, the file:// location options are not checked.
It’s important to note that the HTTP URL defined here is embedded in
the certificates issued by the CA.
In this book’s lab, using the default HTTP variables as follows:
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><
DeltaCRLAllowed>.crl
The resultant URL used in the CDP becomes: http://ca01.lab.jnprcbr.
local/CertEnroll/lab-CA01.crl

Publish the IPsec (Offline) Certificate Template

Within the Certification Authority management snap-in, right-click on
Certificate Templates and navigate to New > Certificate Template to
Issue:
 126 Day One: ADVPN Design and Implementation

Scroll down until you find the IPsec (Offline request) template. High-
light it, and then click OK:

SRX Configuration: Obtain and Load the CA Certificate

Download the CA’s certificate by pointing your web browser at http://
yourserver/certsrv/. Click the link to Download a CA certificate,
certificate chain, or CRL. Choose the Base64 option and then click
Download CA Certificate. Save the resultant file (certnew.cer) to a
known location.
Now, to get the certificate onto the SRX, you can either transfer the
certnew.cer file using SCP or FTP as you would a Junos image, or you
can use the method described below to paste it into a terminal session.
To transfer the certificate using the terminal method, open certnew.new
in your favorite text editor. It should look something like this:
-----BEGIN CERTIFICATE-----
MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw
CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG
A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw
MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE
CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3
b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq
0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz
q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj
eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58
AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV
AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD
kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv
O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4=
-----END CERTIFICATE-----
 Appendices 127

If it looks different, it may be that you downloaded the certificate in

DER format instead. Now, highlight and copy the entire contents of
the file and switch to your terminal window:
admin@srx550-01> start shell
% cat >ca.txt
<PASTE>
-----BEGIN CERTIFICATE-----
MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw
CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG
A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw
MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE
CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3
b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq
0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz
q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj
eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58
AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV
AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD
kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv
O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4=
-----END CERTIFICATE-----
<TYPE ^D>
% exit
exit

admin@srx550-01>
Let’s step through this. First, you’re dropping out of the Junos CLI into
a shell prompt. Next, you’re using the “cat” (concatenate) tool to
redirect what you’re about to paste into a file named ca.txt. Then,
you’re pasting in the contents of the Base64-encoded CA certificate.
After the line containing the string -----END CERTIFICATE-----, type
Control-D (^D) to finish the process. Type exit to return to the Junos
CLI.
You should now have a file named “ca.txt” in your home directory on
the SRX. Let’s confirm it:
admin@srx550-01> file show ca.txt
-----BEGIN CERTIFICATE-----
MIICazCCAfGgAwIBAgIQE3Ryv2zi6Z9BwW5yLzK4EzAKBggqhkjOPQQDAzBcMQsw
CQYDVQQGEwJBVTEMMAoGA1UECBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcG
A1UEChMQSnVuaXBlciBOZXR3b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwHhcNMTUw
MTIyMDUyMTQ4WhcNMjAwMTIyMDUzMTM0WjBcMQswCQYDVQQGEwJBVTEMMAoGA1UE
CBMDQUNUMREwDwYDVQQHEwhDYW5iZXJyYTEZMBcGA1UEChMQSnVuaXBlciBOZXR3
b3JrczERMA8GA1UEAxMIbGFiLUNBMDEwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQq
0xaGCwhIwnwjHXXQzmjfVE8f/x5VmQHWpQbFUKtf0xOr4kbeRhqCUDgEBpxri8cz
q+RDtOMSf4cGWWN+WiJRS/yvVPgKz5mp/Gknwxb7t1QkjITnSUEgfDLstCywg1Gj
eDB2MAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTLcO58
AudRR9Mx2vCOjXrsd8G9NTASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcV
AgQWBBTSi1+P17mnRXcyivXExfpGGzjhRTAKBggqhkjOPQQDAwNoADBlAjBGTGtD
kGanQJQNsv3JF0fnnkldGyZGL4/rIBAOaVvBaxi6Bh0xAKLqg5EjK5Obt9ECMQDv
O8bEXWpNlrORNUdXDnXzu6HIXhm0n22OoAm14V3wSBsdeiiM2PQgJa9H3GzH/l4=
-----END CERTIFICATE-----
 128 Day One: ADVPN Design and Implementation

Okay, great!
Now, you need to apply some PKI configuration in Junos. At this point
all you need to do is to define a CA profile that can be used to associate
with the certificate:
admin@srx550-01> configure 
Entering configuration mode

[edit]
admin@srx550-01# set security pki ca-profile lab-root ca-identity lab-CA01 

[edit]
admin@srx550-01# commit and-quit 

Load the certificate:

admin@srx550-01> request security pki ca-certificate load ca-profile lab-root filename
ca.txt
Fingerprint:
a5:52:47:47:28:49:c9:95:da:83:0c:15:67:4b:0e:0c:bc:19:67:93 (sha1)
ff:6a:4e:c7:15:98:5d:ab:61:ff:0f:f6:ab:39:c1:5b (md5)
Do you want to load this CA certificate ? [yes,no] (no) yes

CA certificate for profile lab-root loaded successfully

Generate a Key Pair and Complete the Onboarding Process

Generate an ECDSA-384 key pair:
admin@srx550-01> request security pki generate-key-pair certificate-id srx550-01_0003
size 384 type ecdsa
Generated key pair srx550-01_0003, key size 384 bits

If you’ve configured syslog to look for PKI events, when you run this
command, you should see a PKI syslog message similar to the follow-
ing:
Feb 27 11:09:18 srx550-01 pkid[1452]: %DAEMON-5-PKID_PV_KEYPAIR_GEN: A 384 bit ECDSA
key-Pair has been generated for srx550-01_0003

Now generate a request for an X.509 certificate:

admin@srx550-01> request security pki generate-certificate-request digest sha-
256 domain-name srx550-01.lab.jnprcbr.local certificate-id srx550-
01_0003 subject “DC=sec0003, CN=srx550-01.sec0003.lab.jnprcbr.
local, L=Canberra, ST=ACT, C=AU”

Generated certificate request
-----BEGIN CERTIFICATE REQUEST-----
MIIBqDCCASwCAQAwdDEXMBUGCgmSJomT8ixkARkWB3NlYzAwMDMxKzApBgNVBAMT
 Appendices 129

InNyeDU1MC0wMS5zZWMwMDAzbGFiLmpucHJjYnIubG9jYWwxETAPBgNVBAcTCENh
bmJlcnJhMQwwCgYDVQQIEwNBQ1QxCzAJBgNVBAYTAkFVMHYwEAYHKoZIzj0CAQYF
K4EEACIDYgAElKvwWTffQ235Rre5Aj/yF0Uyht8K7amjTRAxJSeKsx5pde9hemHc
VbLHC7dBGBBiMURouI0CLRZyAHIGLa19m20IdR3G31B6zHTUAOduZHyqkeSa4CPS
blvHSiznWD17oDkwNwYJKoZIhvcNAQkOMSowKDAmBgNVHREEHzAdghtzcng1NTAt
MDEubGFiLmpucHJjYnIubG9jYWwwDAYIKoZIzj0EAwMFAANoADBlAjBraKeGjlui
PFoTlyGqumEd5K24BzIeIiP3ZfmtGJ/rD6ChUyMSznVtitwPhgZbp54CMQC1BDfV
A3/a97opaVDQv+4w7a+m63HasXttwF0gP721Mb/ii213v8EldHmXDZNNY1w=
-----END CERTIFICATE REQUEST-----
Fingerprint:
00:95:5b:b7:89:da:46:2b:99:1b:cd:68:eb:72:f7:7a:99:c5:8b:9d (sha1)
fe:b3:0d:9c:f3:3c:11:53:83:51:94:2b:bf:25:02:4e (md5)

Submit the request to the CA via the web interface:

Copy the text above, starting at the line containing the string -----BE-
GIN CERTIFICATE REQUEST----- and ending at the line containing the
string -----END CERTIFICATE REQUEST-----.
Point your web browser at http://yourserver/certsrv/. Click the link to
Request a certificate, then click Submit a certificate request by using a
base-64-encoded CMC or PKCS #10 file, or submit a renewal request
by using a base-64-encoded PKCS #7 file.
In the Saved Request text box, paste in the certificate request. From the
Certificate Template drop-down, ensure that IPsec (Offline request) is
selected. Click Submit.
On the next screen, click the radio button next to Base64 encoded and
then download the certificate. The file will be named certnew.cer as
before, so when you save it, give it a unique name (for example,
srx550-01.cer). Using your preferred method (therefore, FTP/SCP or
terminal), transfer this file to the SRX as you did with the CA certifi-
cate.
Now you’re ready to load the issued certificate:
admin@srx550-01> request security pki local-certificate load certificate-id srx550-
01_0003 filename srx550-01_0003.cer
Local certificate loaded successfully

If you’ve configured syslog to look for PKI events, when you run this
command, you should see a PKI syslog message similar to the follow-
ing:
Feb 27 11:21:52 srx550-01 pkid[1452]: %DAEMON-5-PKID_PV_CERT_LOAD: Certificate
srx550-01_0003 has been successfully loaded

Now you’re ready to configure ADVPN!

 130 Day One: ADVPN Design and Implementation

Appendix 2: OpenSSL as an Offline CA

During the writing of this book some of our labs were completely
isolated; in one instance, the entire lab was provisioned on a laptop
with resources only sufficient to run the Junos vSRX images. A
work-around was found, and it turned out to be so useful during our
testing that we decided to document it in this book. It should be
stressed, however, that this should only be used in a lab environment,
as important CA functions such as certificate revocation are not by
definition available for an offline CA. In addition there is some manual
cut and paste work, which is probably fine for a lab network, but in a
production environment, certificate enrollment is a far superior
solution.
The workaround consists of having OpenSSL instances running on a
Linux host (the chosen version of Linux is Ubuntu 14.04).
If you are new to public key infrastructure (PKI), going through these
Appendices will give you insights into how the mechanics of PKI really
work because due to this Appendice’s manual nature the steps take
place at the most basic level. Note that these steps can typically be
abstracted and hidden by the CA provider’s service offerings.

Preparing the Linux Host to Be a CA

A fresh install of Ubuntu has OpenSSL installed. Go to directory/etc/
ssl and take a copy of the default OpenSSL configuration file:
sudo cp openssl.cnf openssl.orig

You need to edit the openssl.cnf file, using your favorite Linux editor,
and add the following stanza to the configuration file:
Dir = ./

This tells OpenSSL to work from the current directory to read the CA
configuration files and where to place the generated certificates.
The other configuration item requiring adjustment is how the SRX
generates certificates that are to be signed. By default, modern versions
of OpenSSL are expecting distinguished names to be in utf8only text
format. However the SRX generates its certificates in printablestring
text format. This becomes an issue when the CA tries to sign a certifi-
cate – by default it will try and match on stateorProvinceName and
organizationName. To work around this issue, modify the policy
match stanza of the configuration file and change the stateorProvince-
 Appendices 131

Name and organizationName from match to optional as noted below:

[ policy_match ]
countryName = match
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Alternatively the string mask can be set to assume printablestring as

noted below:
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = pkix

Save the configuration file.

Decide what you want to call your CA. In this example the CA is
going to be called SuiteBCA. You now need to build a directory
structure that reflects this CA and the subdirectories (starting at the /
etc/ssl part of the directory) for the various CA functions and then
change into the directory:
sudo mkdir –p SuiteBCA/{certs,newcerts}
cd SuiteBCA

The subdirectories names certs and newcerts are derived from the
openssl.cnf file. If you have changed the openssl.cnf file for those
entries, the directories need to match. When creating SRX certificates
to be signed, not only do you need a subject, you also need a domain
name, email address, or IP address, which becomes the subject alterna-
tive name in the X509 certificate. In this tutorial, the email name was
chosen. Create a new file called subalt.txt and create the subject
alternative name:
subjectAltName=email:[email protected]

Save the file.

The next stage is to create a CA private key. As the name of the CA
implies, this CA was used to create certificates that could be used when
encrypting with SuiteB algorithms, and in particular the Juniper 256bit
SuiteB proposal set:
sudo openssl ecparam –out ec_key.pem –name secp384r1 –genkey
 132 Day One: ADVPN Design and Implementation

This OpenSSL command creates a private key using the secp384r1

profile that uses the appropriate elliptic curve necessary so Juniper
SuiteB proposal sets work correctly.
The next step is to create the CA certificate:
sudo openssl req –x509 –new –days 3650 –key ec_key.pem –sha384 –out cacert.pem

This OpenSSL command requests a new certificate to be created. Use

the private key you’ve just created and generate the CA certificate,
which comes in pem format. Again, to ensure compliance with Juni-
per’s currently implemented 256bit SuiteB algorithms, the secure hash
sha384 must be specified. Once you enter this command you will be
prompted for the characteristics of the certificate, which include
Country Name, State, Locality Name, Organization Name, Organiza-
tion Unit, Common Name. Like all good lab configurations, make sure
your CA certificate doesn’t run out anytime soon, that being 10 years.
Keep the generated cacert.pem file handy as it will be required to be
copied to each SRX that you want to use this CA as a signing authority.
The last stage of creating the CA is to seed the starting point for certifi-
cates – you want to create and ensure an index file exists for the certifi-
cates you will be creating:
sudo echo 100 >serial
touch index.txt

That completes the configuration for OpenSSL as an offline CA.

Preparing the SRX

The first stage of preparing the SRX is to create a PKI profile:
security {
pki {
ca-profile SuiteB {
ca-identity suiteB;
revocation-check {
disable;
}
}
}

In this particular case the profile is called SuiteB with a certificate

authority identity of SuiteB. As our CA is completely offline, it is
important to disable revocation checking.
The next step is to load the CA’s certificate on the SRX. The cacert.pem
file generated in the creation of the CA needs to make its way onto the
SRX file system. The simplest way is to drop back to the shell on the
SRX, and create the file via vi, and then cut and paste the cacert.pem
file into the vi session and save it.
 Appendices 133

Now, once the CA’s certificate is on the SRX, you need to associate that
certificate with the profile just created. In a lab context, the file was
stored in root’s home directory so the file goes in /root/cacert.pem:
request security pki ca-certificate load ca-profile SuiteB filename /root/cacert.pem

Now that there is a CA certificate on the SRX, the generation of the

SRX private/public key combination and signing request can begin.
The first stage is to generate the private/public key pair:
Request security pki generate-key-pair generate-key-pair type ecdsa size 384
certificate_id srx550-1

Once again as the generation of the certificates are for a SuiteB imple-
mentation you need to specify the type as an elliptic curve, and because
you want to use the Juniper SuiteB 256 proposal set, you must have a
size of 384.

TIP If you are planning on having multiple ADVPN instances, each

running in its own routing instance, having sensible naming standards
for the certificate IDs so you can readily identify the certificate is
useful.

The final stage of preparing the SRX is to generate a certificate signing

request with the key just created. This stage is very important because
it’s where you get to define the subject in the certificate. This in turn is
used to create the identifier that will be used to decide if the IKE SA
will be accepted:
request security pki generate-certicate-request certificate-id srx550-1 subject
“DC=srx550-1.juniper.net,CN=srx550-1.juniper.net,OU=Base,O=Juniper,L=Canberra,ST=ACT,
C=AU” email [email protected]

Again, if you are going to be generating different certificates for

different routing instances, ensure one element of the subject is used as
a distinguisher. In this case, the OU parameter has been chosen, and
since this certificate is for the default routing instance, it’s called Base.
For the certificate request that resides in the routing instance, using the
name of the routing instance would easily distinguish that certificate.
The final parameter is the Subject Alternative Name as built in the first
section of setting up the OpenSSL CA.
On completion of the request, a certificate signing request will be
generated on the SRX. This needs to be captured to a file so it can then
be taken to the CA to be signed. By convention, the name of the file
should be the certificate ID, with a .csr extension – in this example,
srx550-1.csr.
 134 Day One: ADVPN Design and Implementation

Signing the SRX Certificate With the CA

Place the certificate signing request file that was just created in the base
directory of your CA on the Linux host.
Use the following OpenSSL command to sign the request:
sudo openssl ca –in srx550-1.csr –out certs/srx550-1.pem –keyfile ec_key.pem –cert
cacert.pem –md SHA384 –extfile subalt.txt

Once again, as you are generating certificates for Juniper’s SuiteB 256
proposal set as currently implemented, the hash for the certificate must
be SHA384-based as signified by the –md parameter. The extfile
parameter is the file that was created during the setup of the OpenSSL
CA.
In the directory certs (one level below the CA’s base directory) will be
the signed certificate that needs to go back to the SRX. Once again,
take a copy of this file (as you did before) and get it to the SRX. The
file will have a .pem extension.

Loading the CA Signed Certificate on the SRX Certificate

Use the method previously used to get the CA public key file onto the
SRX, and do so for the signed key for the SRX. Assuming the file is
stored in the root’s directory issue the following SRX command to
install the signed certificate:
request security pki local-certificate load certificate-id srx550-1 filename /root/
srx550-1.pem

You now have a signed certificate installed in your SRX.

SRX IKE Configuration Example

With a signed certificate created, configuration needs to be added to
use the certificates. In addition to the preceding CA profile, the IKE
policy needs to reflect the certificate created. Finally, the distin-
guished-name wildcard needs to be defined so you can match on the
certificate details. An example follows:
ike {
policy ikepol-advpn {
mode main;
certificate {
local-certificate srx550-1;
}
proposal-set suiteb-gcm-256;
}
gateway hub-gw {
 Appendices 135

ike-policy ikepol-advpn;
dynamic {
distinguished-name {
wildcard ST=ACT,O=Juniper;
}
ike-user-type group-ike-id;
}
local-identity distinguished-name;
external-interface ge-0/0/0.0;
advpn {
partner {
disable;
}
}
version v2-only;
}
}

To verify the certificates on the SRX, use the show security pki
ca-certification ca-profile SuiteB detail command:

Certificate identifier: SuiteB
  Certificate version: 3
  Serial number: c50d29afe6c65a10
  Issuer:
    Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT,
    Locality: Canberra, Common name: UbuntuCA
  Subject:
    Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT,
    Locality: Canberra, Common name: UbuntuCA
  Subject string:
    C=AU, ST=ACT, L=Canberra, O=Juniper, OU=Net, CN=UbuntuCA, emailAddress=mbarrett@
juniper.net
  Validity:
    Not before: 12- 2-2014 05:57 UTC
    Not after: 11-29-2024 05:57 UTC
  Public key algorithm: ecdsaEncryption(384 bits)
    04:27:63:65:64:72:ee:c0:69:61:f9:a6:93:53:6d:a9:35:b7:60:31
    85:94:df:45:35:1c:c1:7c:b3:84:ca:61:d2:c2:5e:e7:0c:75:62:ea
    78:75:df:51:43:5a:e3:a1:d4:81:70:82:bb:b6:5d:3a:76:38:5d:d0
    a2:da:f9:5a:16:e9:bc:9e:d8:ad:86:d4:88:03:84:c5:de:be:a1:5c
    22:0f:21:b7:3c:58:f4:be:02:77:24:8d:e4:9b:4d:cd:25
  Signature algorithm: ecdsa-with-SHA384
  Fingerprint:
    3e:82:62:34:77:33:b2:5a:30:00:50:3c:a9:9d:9e:6f:89:a6:d6:f1 (sha1)
    00:d5:a8:56:05:f6:80:cb:26:b7:e4:1e:9e:ef:a2:55 (md5)

Make sure the public key algorithm and signature algorithm are
suitable for the ciphers you’ll use with a show security pki local-
certificate certificate-id SRX550-01 detail command:

Certificate identifier: srx550-1
  Certificate version: 3
  Serial number: 00001001
 136 Day One: ADVPN Design and Implementation

  Issuer:
    Organization: Juniper, Organizational unit: Net, Country: AU, State: ACT,
    Locality: Canberra, Common name: UbuntuCA
  Subject:
    Organization: Juniper, Organizational unit: Base, Country: AU, State: ACT,
    Common name: srx550-01.juniper.net
  Subject string:
    C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-01.juniper.net
  Alternate subject: [email protected], fqdn empty, ip empty
  Validity:
    Not before: 12- 2-2014 06:39 UTC
    Not after: 12- 2-2015 06:39 UTC
  Public key algorithm: ecdsaEncryption(384 bits)
    04:fc:97:41:31:a8:6d:65:9a:65:82:34:f0:e7:69:1f:d9:27:c8:f3
    c6:9e:cb:8e:a1:df:c8:13:a9:1e:6c:8d:35:63:b8:94:5a:8d:55:20
    32:ee:f7:56:45:62:ae:24:54:a5:a0:0c:6a:8f:39:fd:bf:5a:92:b8
    46:c9:13:76:16:18:4c:b9:34:2c:a1:6c:0a:37:eb:71:1b:cf:4e:97
    a5:42:08:15:1c:2b:25:44:2e:04:41:88:57:3c:eb:bf:14
  Signature algorithm: ecdsa-with-SHA384
  Fingerprint:
    8c:1d:34:17:f1:1b:86:f2:03:0e:e8:7e:49:bb:30:15:ac:bd:e2:c9 (sha1)
    6c:19:01:d5:9b:1f:56:01:7d:97:8c:b4:0b:c6:c8:d4 (md5)
  Auto-re-enrollment:
    Status: Disabled
    Next trigger time: Timer not started

Now make sure the public key algorithm and signature algorithm are
suitable for the ciphers you’ll use. In addition, make sure the subject
string is appropriate for what you’ll be matching on for your dynamic
neighbors. Let’s see what it looks like now when associations are
created with the show sececurity ike security-associations com-
mand:
Index     State   Initiator  cookie   Responder  cookie   Mode            Remote  Address
8096092   UP      632272c2d5b27286   41dd14abcb525543   IKEv2          192.168.66.1  

The certificates on both sides of the exchange are okay with established
IKE sessions. Let’s look at this association in detail using the show
security ike security-associations index <number> detail com-
mand:
IKE peer 192.168.66.11, Index 8096092, Gateway Name: hub-gw
  Auto Discovery VPN:
   Type: Static, Local Capability: Suggester, Peer Capability: Partner
   Suggester Shortcut Suggestions Statistics:
     Suggestions sent    :    0
     Suggestions accepted:    0
     Suggestions declined:    0
  Role: Responder, State: UP
  Initiator cookie: d4f3308d89b2973b, Responder cookie: d60cbace459377ad
  Exchange type: IKEv2, Authentication method: ECDSA-384-signatures
  Local: 192.168.66.1:500, Remote: 192.168.66.11:500
  Lifetime: Expires in 27181 seconds
 Appendices 137

  Peer ike-id: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-02.juniper.net
  Xauth user-name: not available
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha384-192
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha384
   Diffie-Hellman group  : DH-group-20
  Traffic statistics:
   Input  bytes  :                 1362
   Output bytes  :                 1323
   Input  packets:                    2
   Output packets:                    2
  IPsec security associations: 2 created, 0 deleted
  Phase 2 negotiations in progress: 1

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 192.168.66.1:500, Remote: 192.168.66.11:500
    Local identity: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-01.juniper.net
    Remote identity: C=AU, ST=ACT, O=Juniper, OU=Base, CN=srx550-02.juniper.net
    Flags: IKE SA is created

You can see the algorithms that are being used and the peer IKE
identification. Now that IKE is established, IPsec associations follow
with the show security ipsec associations command:
  Total active tunnels: 1
   ID     Algorithm        SPI       Life:sec/kb   Mon  lsys  Port   Gateway
  <67108870 ESP:aes-gcm-256/None d7d2b271 3132/ unlim - root 500 192.168.66.1   
  >67108870 ESP:aes-gcm-256/None 6a57b9c3 3132/ unlim - root 500 192.168.66.1   

Summary
Okay lab rats, it’s your turn to take this and run with it. Have fun with
ADVPN.