Jncis Sec P1

JNCIS-SEC Study GuidePart 1
Worldwide Education Services

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks
Education Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered
trademarks, or registered service marks are the property of their respective owners.
JNCIS-SEC Study GuidePart 1.
Copyright 2012, Juniper Networks, Inc.
All rights reserved. Printed in USA.
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 12.1R1.9. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental
or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has
no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Chapter 1:
Introduction to Junos Security Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Chapter 2:
Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Chapter 3:
Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Chapter 4:
Firewall User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Chapter 5:
SCREEN Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Chapter 6:
Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Chapter 7:
IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Chapter 8:
Introduction to Intrusion Detection and Prevention . . . . . . . . . . . . . . . . . . . . 8-1
Chapter 9:
High Availability Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Chapter 10:
High Availability Clustering Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .10-1
Contents iii
Overview
Welcome to the JNCIS-SEC Study GuidePart 1. The purpose of this guide is to help you
prepare for your JN0-332 exam and achieve your JNCIS-SEC credential. The contents of this
document are based on the Junos for Security Platforms course. This study guide covers the
configuration, operation, and implementation of SRX Series Services Gateways in a typical
network environment. Key topics within this study guide include security technologies such as
security zones, security policies, intrusion detection and prevention (IDP), Network Address
Translation (NAT), and high availability clusters, as well as details pertaining to basic
implementation, configuration, and management.
Agenda
Chapter 1:
Introduction to Junos Security Platforms
Chapter 2:
Zones
Chapter 3:
Security Policies
Chapter 4:
Firewall User Authentication
Chapter 5:
SCREEN Options
Chapter 6:
Network Address Translation
Chapter 7:
IPsec VPNs
Chapter 8:
Introduction to Intrusion Detection and Prevention
Chapter 9:
High Availability Clustering
Chapter 10: High Availability Clustering Implementation
Overview iv
Document Conventions
CLI and GUI Text
Frequently throughout this guide, we refer to text that appears in a command-line interface (CLI)
or a graphical user interface (GUI). To make the language of these documents easier to read, we
distinguish GUI and CLI text from chapter text according to the following table.
Style
Description
Usage Example
Franklin Gothic
Normal text.
Most of what you read in the Lab Guide

and Study Guide.
Courier New
Console text:
Screen captures
commit complete
Noncommand-related
syntax
Exiting configuration mode
GUI text elements:

Menu names
Text field entry
Select File > Open, and then click

Configuration.conf in the
Filename text box.
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often these instances
will be shown in the context of where you must enter them. We use bold style to distinguish text
that is input versus text that is simply displayed.
Style
Description
Usage Example
Normal CLI
No distinguishing variant.
Physical interface:fxp0,
Enabled
Normal GUI
View configuration history by clicking

Configuration > History.
CLI Input
Text that you must enter.
lab@San_Jose> show route

Select File > Save, and type
config.ini in the Filename field.
GUI Input
Defined and Undefined Syntax Variables

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

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

CLI Undefined
GUI Undefined
www.juniper.net
Text where the variables value

is the users discretion and text
where the variables value as
shown in the lab guide might
differ from the value the user
must input.
Type set policy policy-name.

ping 10.0.x.y
Select File > Save, and type
filename in the Filename field.
Document Conventions v
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
About This Publication

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

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

This Chapter Discusses:
Traditional routing and security implementations;
Current trends in internetworking;
The Junos operating system for the SRX Series; and
Logical packet flow through SRX Series devices.
Built to Forward Packets
The primary responsibility of a router is to forward packets using Layer 3 IP addresses found in an IP packet header. To forward
packets, the router must have a path determination mechanism. This mechanism could be statically assigned routes, routing
protocols, or policy-based routing.
Packet Processing Is Stateless

Traditionally, routers process packets in a stateless fashion. Routers do not keep track of bidirectional sessions; they forward
each packet individually based on the packet header.
Separate Broadcast Domains and Provide WAN Connectivity

Routers were originally used to separate broadcast domains. With the introduction of advanced switching technologies and the
birth of virtual LAN (VLAN) standards, broadcast domains can also be separated using switches. That capability, however, does
not address inter-VLAN connectivity, which still necessitates the use of routers for forwarding traffic between VLANs.
Furthermore, routers provide WAN connectivity at the network edge.
2012 Juniper Networks, Inc. All rights reserved.
Introduction to Junos Security Chapter 11
Layer 3 Packet Forwarding
The objective of the graphic is to illustrate transmission of packets from Host-A to Host-B. Routers perform Layer 3 packet
forwarding using routing table entries. Routers build routing tables based on the results of dynamic routing protocols (for
example, RIP, OSPF, IS-IS, and BGP), statically entered routes, or both of these methods. Note that routers forward packets
based on the longest prefix match. For example, in the graphic, Router-A selects interface ge-0/0/2 to send traffic to destination
10.3.3.10 because 10.3.3.10/32 is a longer prefix match than 10.3.3.0/24. If entry 10.3.3.10/32 does not exist in the routing
table, the router selects interface ge-0/0/0 as the next hop for the same packet flow.
Layer 3 Packet Forwarding

A traditional router is a promiscuous device that performs stateless packet
processing. It is promiscuous because once it is configured, it immediately
forwards all traffic by default (provided, of course, that some combination of
static and dynamic routing is configured). Typically, a router operates only at
Layer 3 and does not recognize any security threats in higher-layer protocols.
Furthermore, a traditional router operates per packet, which adds to its
fundamentally insecure nature, because it cannot detect malformed
sessions. The network and the router itself are immediately vulnerable to all
security threats.
Typical Treatment of Security

Other than implementing standard access control using IP header
information, most routers are not equipped to secure a network. Traditionally,
a full security solution involves adding a separate firewall device.
Typical Router Positioning
Enterprise customer premise applications are served by the J Series family of service routers and, in the case of larger
enterprises, M Series routers. Enterprise data center applications can also be served by M Series routers. Internet service
Chapter 12 Introduction to Junos Security

provider (ISP) networks can be served by M Series, MX Series, or T Series routers. J Series, M Series, MX Series and T Series
routers support the rich routing and class-of-service (CoS) features needed by networks, and maintain value, stability, and
predictably high performance.
Adding Security to the Network

Standalone routers do not provide adequate security to enterprise networks and data centers. As networks expand, network
applications continue to diversify and expand, and as new methods of remote communications such as telecommuting
increase, the need for added security becomes apparent. Typically, a standalone firewall is added to the network, increasing
costs and maintenance.
Requirements for Firewall Devices

A firewall device must be capable of the following:
Stateful packet processing based on contents of IP and higher-level packet information, which includes TCP/UDP
and the Application Layer;
Network Address Translation (NAT) and Port Address Translation (PAT), achieving private-to-public translations and
vice versa; and
Establishing virtual private networks (VPNs) compounded with authentication and encryption.
Additional Services
The growth in network security has resulted in additional services provided by standalone firewalls such as Secure Sockets
Layer (SSL) network access, intrusion detection and prevention (IDP), application-level gateway (ALG) processing, and more.
Firewall: Stateful Packet Processing

Because the main job of a firewall is to protect networks and devices, fundamental firewall intelligence consists of the ability to
make packet processing decisions based on IP packet header information, including its upper layers.
Stateful packet processing involves the creation of a unidirectional flow, which consists of six elements of informationsource IP
address, destination IP address, source port number, destination port number, protocol number, and a session token. The
session token is derived from a combination of a routing instance and a zone. The outgoing flow initiates a session table entry
and the expected return flow for that packet. Both outgoing and incoming flows comprise the session and are entered into the

session table. The session table enables bidirectional communication without any additional configurational steps for return
traffic.
Firewall: NAT and PAT
When a security device resides at the edge of a network, it must be able to replace private, nonroutable addresses with public
addresses before traffic is sent to the public network. Translation can consist of replacing the IP address, port numbers, or both,
depending on the configuration. Note that NAT can be used on both source and destination addresses, and PAT can be used on
both source and destination ports.
Firewall: Virtual Private Networks
You can use a firewall to build VPNs using the public network as an access medium between two private sites. As such, the
firewall must be able to perform the following:
Encapsulate the original traffic in a packet that can be transported over the public network;
Encrypt the original packet so that it cannot be easily decoded if it is intercepted on the public network; and
Authenticate the originating device as a member of the VPNnot a random device operating on the public network.
Firewall Positioning
The graphic illustrates a typical enterprise deployment of firewall devices. Small office and home offices or retail storefronts use
branch firewall devices to provide secured access to the Internet, as well as an IP Security (IPsec) VPN tunnel back to a central
site.
The enterprise firewall device at the central site provides VPN termination and firewall protection between internal zones as well
as from the Internet, and it might also provide other security services such as IDP, Web filtering, and antispam services.
Junos Security Platforms Versus a Traditional Router
The traditional router and a Junos security platform have completely different starting points with respect to security and traffic
flow.

The traditional router begins by forwarding all traffic. Thus, the network is vulnerable to all threats. You add security policies to
reduce vulnerability until you reach the ideal configuration. Because the traditional router begins as completely promiscuous
and it requires that you add security policies, a greater chance exists that the network will remain vulnerable to some threats.
An SRX Series Services Gateway running the Junos OS begins by forwarding no traffic. The network is secure but not functional.
You add rules to allow traffic until you reach the ideal configuration. Because a Junos security platform begins by forwarding no
traffic and because you must add rules, a greater likelihood exists that the network will restrict undesirable traffic.
The Junos Security Platforms Merge Routing and Security
The new features of the Junos security platforms bring new core security capabilities to the Junos OS. Because the forwarding
algorithm is session-based, security features are tightly integrated into the forwarding plane, improving security performance.
Session-based forwarding and stateful firewall features derive from Juniper Networks ScreenOS software.
The Junos security platforms incorporate ALG functionality, IPsec VPNs, and screen protection in a flowd module within the
Junos OS. Juniper Networks world-class IDP technology is also fully integrated into the Junos security platforms. We discuss
these features later in this material.
Junos Elements
SRX Series Services Gateways use the Junos OS as their base operating system.
As such, these devices deploy all the industry-proven processes of the Junos OS,
such as the routing process, management process, device control process, and
others. Another building element of the Junos security platforms is
session-based forwarding, thereby resulting in a strong suite of security features.
Packet-Based Junos Forwarding

The Junos OSs basic control plane, routing protocol process implementation,
per-packet stateless filters, policers, and CoS functions are all packet based.
Furthermore, other nonsecurity-related features, such as all interface
encapsulations and de-encapsulations, use the industry-proven Junos OS. You
can configure SRX Series Services Gateways using either the CLI or J-Webthe
Junos OS-based graphical user interface (GUI).
Session-Based Forwarding
The Junos security platforms leverage ScreenOS softwares security features as well as its flow-based nature. The first packet
entering the device follows a series of path and policy determination schemes. The Junos OS caches the session information,
the creation of which is triggered by the first packet of the flow. The cached session is used by subsequent packets of that same
flow and the reverse flow of that session. Using the flow module, which is integrated into the forwarding path, the hardware
performs data-plane packet forwarding. Because the Junos security platforms are security-based, all IPv4 packets entering the
services gateway on an interface associate with an incoming zone. Likewise, all IPv4 packets exiting the device on an interface
associate with an outgoing zone. If a route changes, as long as the interface remains in the same zone, the session remains
intact. It only needs a new session if resulting interfaces are in different zones.The Junos security platforms add a bundle of
high-security features to the regular features of a router, including stateful firewall, VPNs, NAT, ALGs, and IDP.
Control Plane
The control plane on a Junos security platform is implemented using the Routing Engine. The control plane consists of the Junos
kernel, various processes, chassis management, user interface, routing protocols and some security features. Many of the
security features resemble ScreenOS features, including the network security process, the VPN process, the authentication
process, and Dynamic Host Configuration Protocol (DHCP). For its control plane, the Junos security platform deploys these
features along with well-known, traditional Junos features.
Data Plane
The data plane on Junos security platforms, implemented on IOCs, NPCs, and SPCs for high-end devices and on CPU cores and
PIMs for branch devices, consists of Junos OS packet-handling modules compounded with a flow engine and session
management like that of the ScreenOS software. Intelligent packet processing ensures that one single thread exists for packet
flow processing associated with a single flow. Real-time processes enable the Junos OS to perform session-based packet
forwarding.
Logical Packet Flow Details
Security platforms running the Junos OS handle an incoming packet as follows:

1.
The software applies stateless policing filters and CoS classification to the packet at the ingress.
2.
If the packet does not drop, the software performs a session lookup to determine whether the packet belongs to an
existing session. The Junos OS matches on six elements of traffic information for this determinationsource IP
address, destination IP address, source port number, destination port number, protocol number, and a session
token.
3.
If the packet does not match an existing session, the software creates a new session for it. This process is referred
to as the first-packet path. If the packet matches a session, the software performs fast-path processing.
The first packet of a flow is subject to first-packet-path processing. The software takes the following steps during
first-packet-path processing:
1.
Based on the protocol used and its session layer (TCP or UDP), the software starts a session timer. For TCP
sessions, the default timeout is 30 minutes. For UDP sessions, the default timeout is 1 minute. These values are
the defaults, and you can change them.

2.
The software applies firewall SCREEN options.
3.
If destination NAT is used, the software performs address allocation.
4.
Next, the software performs the route lookup. If a route exists for the destination prefix, the software takes the next
step. Otherwise, it drops the packet.
5.
The software determines the packets incoming zone by the interface through which it arrives. The software also
determines the packets outgoing zone by the forwarding lookup.
6.
Based on incoming and outgoing zones, the corresponding security policy is determined and a security policy
lookup takes place. The software checks the packet against defined policies to determine how to treat the packet.
7.
If source NAT is used, the software performs address allocation.
8.
The software sets up the ALG service vector.
9.
The software creates and installs the session. Furthermore, the software caches the decisions made for the first
packet into a flow table, which subsequent packets of that flow use.
10.
The packet now enters the fast-path processing.
Subsequent packets of a flow are all subject to fast-path processing. The software takes the following steps during fast-path
processing:
1.
The software applies firewall SCREEN options.
2.
The software performs TCP checks.
3.
The software applies NAT.
4.
The software applies an ALG.
5.
The software applies packet forwarding features, which include the following:
a.
Stateless packet filters;
b.
Traffic shaping by packet; and
c.
Packet encapsulation and transmission.
Session-Based Mode Forwarding

The inset briefly reviews a couple of things about the two types of data-plane forwarding on an SRX device: session-based and
packet-based forwarding. Both types of forwarding require packets to pass through any configured inbound and outbound
firewall filters and class-of-service (CoS) elements (policers and shapers). Beyond that, the two types of forwarding are very
different. Regarding session-based forwarding, each packet is examined to determine whether or not it is part of an existing
session. If the incoming packet is the first packet of a session or flow, then the flow module keeps track of source and
destination IP addresses, source and destination ports, and the IP protocol used in a session state table.
The session information is cached so that subsequent packets for the same flow, as well as packets for the return flow for the
session, are allowed through the device. This latter operation is referred to as fast-path processing.
Packet-Based Mode Forwarding

With packet-based forwarding, each packet is individually inspected, every time. If the incoming packet is not dropped by either
a configured policer or filter, then the SRX device performs a route lookup and forwards the packet. An SRX device forwards
these packets without keeping track of any session state information. No packet requires any information from any other packet.
None of the packets have to be examined to determine whether they are part of a session.
Packet-Based Mode Uses Stateless Security
Packet-based forwarding is stateless forwarding. Packet-based forwarding is performed on a packet-by-packet basis without
regard to flow or state information. With packet-based forwarding, the Junos OS does not maintain information about the
session.
With packet-based forwarding, the Junos OS allows for limited security in the form of stateless firewall filters, sometimes
referred to as access control lists (ACLs). The actions for a filter can be discard, reject, log, or count. So, without any session
table information to keep track of any sessions, the filters must be applied for both initial and return traffic.
The diagram shows the packet flow for packet-based mode. Packets coming into the SRX device pass through a policer and an
inbound firewall filter (if configured). Next, a route lookup is performed to determine the egress interface for the packet. Notice
that the packet does not participate with any of the services on the flow module. It bypasses the security services of the
SRX device. Once the egress interface for the packet is determined, an outbound firewall filter can be applied, as well as a
traffic shaper. Otherwise, the packet is forwarded out to the next-hop interface.
Junos Selective Packet-Mode Forwarding
Branch SRX devices can use both packet-based and session-based forwarding simultaneously. This functionality is called Junos
Selective Stateless Packet-Based Services.
A stateless firewall filter on the inbound interface can specify any matching traffic to be processed as packet-based, in which
case the traffic will bypass the services and security features within the flow module. Otherwise, the rest of the traffic will be
processed within the flow module as session-based traffic.
Advantages
One advantage of having certain traffic be packet-based is scalability. Packet-based traffic has less overhead than
session-based traffic, because it does not pass through the various security and services inspections of the flow module. For
this reason, packet-based mode has a higher scalability than session-based mode, and any packet-based mode traffic will

reduce the processing load within the flow module. The ability to provide packet-based services such as MPLS in conjunction
with session-based security represents another advantage of selective packet-mode filtering.
Selective Packet-Based Configuration

The command-line interface (CLI) commands
displayed in the inset demonstrate a firewall filter
used for selective packet-based services. The
example illustrates a stateless firewall filter named
selective. Term 1 shows that any traffic
matching a source IP address of 10.10.10.1 will
have a matching action of then packet-mode.
With the packet-mode action, the Junos OS
forwards matching packets without applying
stateful security services (assuming there is a
forwarding table entry). The example shows the
firewall filter applied under the logical unit of the
ingress interface. The Junos OS can also apply
filters to virtual LAN (VLAN) interfaces on the
branch SRX series.
Selective Forwarding Example

The inset illustrates a practical example, where a
branch SRX device participates in an MPLS
network, and also provides session-based security
services. The example uses two different routing
instances to forward the two modes of traffic, packet-based and session-based. The Packet-VRF routing instance provides
MPLS and virtual private network (VPN) services by connecting to an MPLS network and terminating the Layer 3 VPN
connection. The main instance has an interface configured that is connected to the MPLS core network. BGP peering is
established, and LDP is used as the MPLS protocol, which then uses the BGP signaling to establish its path to the remote
provider edge (PE) device.
The Junos OS uses the Session-VRF to provide stateful inspection and session-based security. The Junos OS forwards traffic
between the two routing instances over logical tunnel interfaces. Because the routing tables of the two routing instances are
separated, the Junos OS shares routing information between them by means of either a static or dynamic routing protocol. All
traffic going in or out of the Session-VRF participates in security zones, and must pass through security policies to be allowed
through.
The configuration requires a selective packet-based firewall filter to place the traffic into packet-mode. The operator configures
the filter inbound on the logical tunnel (lt-0/0/0) unit 1 interface. The Junos OS applies the filter as traffic ingresses the
Packet-VRF.
The Junos MPLS and VPNs (JMV) course contains more detailed information on VPNs.
Session Maintenance
When a packet enters the system and does not match any existing sessions, the Junos OS creates a new session based on
routing and security policy information. Once this new session is created, the software puts it into a session hash table for
further packet matching and processing. Depending on the protocol and service (TCP or UDP), the session is programmed with a
default timeout. The default TCP timeout is 30 minutes and the UDP default timeout is 1 minute.
Session Cleanup
If no traffic matches the session during the service timeout, the Junos OS ages out the session and frees it to a common
resource pool for a later reuse.
Session Runtime Changes Propagation

The flow module is responsible for propagating any runtime changes that happen during the lifetime of the session. This
propagation allows new packets that match the session to forward using up-to-date information. Routing runtime changes
always propagate into the session. Security policy runtime changes might propagate into the session in progress, based on the
corresponding security policy and zone configuration. We discuss this topic more thoroughly in a subsequent chapter.
Managing Session Characteristics

Sessions are created, based on routing and other classification information, to store information and allocate resources for a
flow. Sessions have characteristics, some of which you can change, such as when they are terminated. For example, you might
want to ensure that a session table is never entirely full to protect against an attackers attempt to flood the table and thereby
prevent legitimate users from starting sessions.
As noted on the preceding page, depending on the protocol and service, a session is programmed with a timeout value. For
example, the default timeout for TCP is 30 minutes. The default timeout for UDP is 1 minute. When a flow is terminated, it is
marked as invalid, and its timeout is reduced to 10 seconds.
You can configure the Junos OS to aggressively age-out sessions based on how full the session table is by specifying the
following options under the [edit security flow aging] hierarchy.
early-ageout: Specify the timeout value in seconds in which sessions age out once the high-watermark
value is met.
high-watermark: Specify a percentage of how full the session table must be to implement the early-ageout
function.
low-watermark: Specify the percentage at which the SRX device disables the early-ageout function and
returns to the default age out time for the sessions.
The Junos OS provides a mechanism for disabling security checks on TCP packets to ensure interoperability with hosts and
devices with faulty TCP implementations. Employing the no-syn-check command tells the Junos OS that it does not need to
look for the TCP SYN packet for session creation. The no-sequence-check command disables TCP sequence checking
validation. Applying these commands under the [edit security tcp-session] hierarchy can increase the throughput of
the SRX device. SYN checking and sequence checking are enabled by default, and the previous commands disable TCP SYN
checks and TCP sequence checks on all TCP sessions, thus reducing security. This might be required in scenarios with
customers, or with applications that do not correctly work with standards. However, you can disable TCP SYN checking and TCP
sequence checking globally and then specify these mechanisms on a per-policy basis.
[edit security policies from-zone untrust to-zone trust policy TCP]
user@srx# set then permit tcp-options ?
Possible completions:
Groups from which to inherit configuration data
+ apply-groups
+ apply-groups-except Don't inherit configuration data from these groups
sequence-check-required Enable per policy sequence-number checking
syn-check-required
Enable per policy SYN-flag check
Other options for TCP sessions can be set under the [edit security tcp-session] hierarchy, which affects how the
Junos OS handles certain situations.
rst-invalidate-session: Marks a session for immediate termination when it receives a TCP RST segment.
By default, this statement is disabled. When this statement is disabled, the router applies the normal session
timeout intervalfor TCP, session timeout is 30 minutes; for HTTP, it is 5 minutes; and for UDP, it is 1 minute.
rst-sequence-check: Checks that the TCP sequence number in a TCP segment with the RST bit enabled
matches the previous sequence number for a packet in that session, or is the next higher number incrementally. By
default, this check is disabled.
strict-syn-check: Enables the strict three-way handshake check for the TCP session. It enhances security by
dropping data packets before the three-way handshake is finished. By default, this check is disabled.
tcp-initial-timeout: Sets the initial TCP session timeout in the session table during the TCP three-way
handshake. The timer is initiated when the first SYN packet is received, and reset with each packet during the
three-way handshake. Once the three-way handshake is completed, the session timeout is reset to the timeout
defined by the specific application. If the timer expires before the three-way handshake is complete, the session is
removed from the session table.
You can specify the maximum segment size (MSS) in TCP SYN packets used during session establishment. Decreasing the MSS
helps to limit packet fragmentation and to protect against packet loss that can occur when a packet must be fragmented to
meet the MTU size but the packets DF-bit (do not fragment) is set. The following options can be set under the [edit
security flow tcp-mss] hierarchy:
all-tcp: Sets the MSS on all TCP packets for network traffic.
gre-in: Enables you to specify the TCP MSS for generic routing encapsulation (GRE) packets that are coming out
from an IPsec VPN tunnel. If the device receives a GRE-encapsulated TCP packet with the SYN bit and TCP MSS
option set and the TCP MSS option specified in the packet exceeds the TCP MSS specified by the device, the device
modifies the TCP MSS value accordingly. By default, a TCP MSS for GRE packets is not set.
gre-out: Enables you to specify the TCP MSS for GRE packets that are going into an IPsec VPN tunnel. If the
device receives a GRE-encapsulated TCP packet with the SYN bit and TCP MSS option set, and the TCP MSS option
specified in the packet exceeds the TCP MSS specified by the device, the device modifies the TCP MSS value
accordingly. By default, a TCP MSS for GRE packets is not set.
ipsec-vpn: Enables MSS override for all packets entering an IPsec tunnel.
Packet Flow Example: Part 1
We now apply the described decision process to a specific example. As the graphic shows, Host-B at 10.1.20.5 wants to initiate
an HTTP session with the Web server at 200.5.5.5. The traffic passes through an SRX Series Services Gateway and is therefore
subject to the decision process.
The graphic shows the packet as received by the SRX Series Services Gateway on interface ge-0/0/1. Following the flowchart,
you can track the progress of the packet through the services gateway:
1.
Based on a lookup in the session table, the Junos OS determines that this session is not an existing session.
2.
The forwarding table shows that the software detects how to reach the destination network.
3.
Now that the forwarding lookup is complete, the software can determine the ingress and egress zones required for
security policy evaluation.
The following is a continuation of the list from the previous page:

4.
The packet is from host 10.1.20.5 and is an HTTP packet. This packet matches the policy statement in the inset.
The action for this particular type of traffic is to permit it.
5.
The SRX Series Services Gateway adds the flow information to the session table. At the same time a return flow is
automatically created and also adds to the session table.
6.
The SRX Series Services Gateway then forwards the packet out interface ge-1/0/0 (as determined by the
destination lookup). The Junos OS allows traffic in both directions for this particular session to pass without any
subsequent policy evaluation.
Review Questions
Answers
1.
Traditionally, routers process packets on a per-packet basis.
2.
Traditionally, firewalls process packets based on stateful flows.
3.
The Junos OS that runs on security platforms uses session-based packet forwarding and by default does not allow traffic to pass, whereas
the traditional Junos OS uses packet-based forwarding and by default allows all traffic to pass.
4.
The first packet of a new session is subject to first-path packet processing.
Chapter 2: Zones
Zones and their purpose;
Types of zones;
Application of zones;
Configuring zones; and
Monitoring zones.
Zone Definition
A zone is a collection of one or more network segments sharing identical security requirements. To group network segments
within a zone, you must assign logical interfaces from the device to a zone.
Traffic Regulation Through a Junos Security Platform

Zones enable network security segregation. Security policies are applied between zones to regulate traffic through the security
platform running the Junos operating system. By default, all network interfaces belong to the system-defined Null Zone. All
traffic to or from the Null Zone is dropped. Special interfaces including the fxp0 management Ethernet interface present in
some SRX Series platforms, chassis cluster fabric interfaces, and internal system em0 interfaces cannot be assigned to a
zone.
Zones Chapter 21
Review: Packet Flow
Recall the packet flow through a Junos security platform. Specifically, once the packet enters a flow module, the device
examines it to determine whether it belongs to an already established session. Recall that the Junos OS matches on six
elements of traffic information to identify a sessionsource IP address, destination IP address, source port number, destination
port number, protocol number, and a session token.
This chapter focuses on defining, configuring, and monitoring zones.
Zones and Interfaces

You can assign one or more logical interfaces to a zone. You can also assign one or more logical interfaces to a routing instance.
You cannot assign a logical interface to multiple zones or multiple routing instances. You must also ensure that all of a zones
logical interfaces are in a single routing instance. Violating any of these restrictions results in a configuration error as shown in
the following examples:
[edit]
user@srx# commit check
[edit security zones security-zone trust]
'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 already assigned to another zone
error: configuration check-out failed
[edit]
[edit routing-instances A interface]
'ge-0/0/0.0'
RT Instance: Interface ge-0/0/0.0 already configured under instance B
[edit routing-instances B]
'interface'
Interface ge-0/0/0.0 is in more than one routing instance (latest A)
error: dcd_config_read fails to set parsing options
[edit]
Chapter 22 Zones

[edit security zones security-zone untrust]
'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 must be in the same routing instance as other interfaces in
the zone
Interfaces, Zones, and Routing Instances
The graphic summarizes logical relationships between interfaces, zones, and routing instances.
Logical interfaces are connections to specific subnets. Zones are logical groupings of logical interfaces with a common security
requirement, and a logical interface can belong to only one zone. Zone configuration can be as simple as a two-zone setup,
where all interfaces connected to internal networks are in one zone, and all interfaces connected to the external world are in a
different zone. A more complicated configuration might divide interfaces based on internal department or function in addition to
external and demilitarized zone (DMZ) connections.
A physical device can be broken up into multiple routing instances. A routing instance is a logical routing construct within a
platform running the Junos OS. Each routing instance maintains its own routing table and forwarding table. A routing instance
can contain one or more zones, which cannot be shared with other routing instances.
Zone Types
The zones within the Junos OS can be subdivided into two categoriesuser-defined and system-defined. You can configure
user-defined zones, but you cannot configure system-defined zones. You can subdivide the user-defined category into security
and functional zones. We cover user-defined and system-defined zones in detail on the next few pages.
Zones Chapter 23
Security Zones
Security zones are a collection of one or more network segments requiring
regulation of inbound and outbound traffic through the use of policies. Security
zones apply to transit traffic as well as traffic destined to any interfaces
belonging to the security zone. You need one or more security policies to
regulate intrazone and interzone traffic. Note that the Junos OS does not have
any default security zones, and you cannot share a security zone between
routing instances.
Functional Zones
Functional zones are special-purpose zones that cannot be specified in security policies. Note that transit traffic does not use
functional zones. While the fxp0 management Ethernet interface is out-of-band by default, the Management zone allows you to
assign other network interfaces the same behavior of isolating management traffic from transit traffic.
Null Zone
Currently only one system-defined zone exists, the Null zone. By default, all interfaces belong to
the Null zone. You cannot configure the Null zone. When you delete an interface from a zone, the
software assigns it back to the Null zone. The Junos OS rejects all traffic to and from interfaces
belonging to the Null zone.
Junos-Host Zone
The junos-host zone is a system-defined zone. You can
configure the junos-host zone in a security policy to
provide granular control for which host-inbound or
host-outbound traffic is allowed in or out of a security
zone on the SRX device.
Functional zones, such as the management zone, cannot
be used in a security policy. For inbound traffic to be
processed by the junos-host zone, the traffic has first to
be allowed by the host-inbound-traffic setting of an
ingress security zone, after which a normal policy lookup
will be done from the ingress zone to the junos-host zone. You can also use the junos-host zone to control or apply services to
host outbound traffic. An example of controlling services to host-outbound traffic would be to configure a security policy to allow
host-outbound traffic through a policy-based VPN. Traffic is permitted through the junos-host zone unless otherwise explicitly
denied by a user-defined security policy.
Chapter 24 Zones
Junos-Host Zone Configuration
The inset demonstrates a configuration example for using the junos-host zone within a security policy. In this case, the
junos-host zone is specified in the to-zone context within the policy. FTP and ping traffic are allowed as host-inbound
traffic on the untrust zone, as shown in the inset security zone configuration. The host-inbound FTP and ping traffic are then
evaluated by the security policy from the untrust zone to the junos-host zone. In this case, if the ping traffic has a source
address of 172.20.1.10, it will be denied. Otherwise, it will be allowed. Also, all FTP traffic will be allowed, and if the FTP traffic
has a source address of 10.10.10.1, the traffic will be logged on session initialization.
Branch Platforms
Junos security platforms for the branch ship from the factory with a template configuration that includes security zones.
SRX Series high-end platforms do not contain zones in the factory-default template configuration and, therefore, you must
configure required zones manually.
Factory-Default Configuration
In branch devices factory-default configuration, two security zones are definedtrust and untrust. In the template
configuration, vlan.0 belongs to the trust zone. In addition, the factory-default configuration file has a security policy
permitting all transit traffic within the trust zone and from the trust zone to the untrust zone. The security policy prohibits
any traffic from the untrust zone to the trust zone. We discuss security policy in further detail in a subsequent chapter. The
zone names trust and untrust have no system-defined meaning. Like any zones defined in the configuration, you can modify or
delete them. You can revert a Junos platform to its factory-default configuration by entering the load factory-default
command from the top of the configuration hierarchy.
Zone Configuration Procedure

Zone configuration involves the following steps:
1.
Define a security or a functional zone;
2.
Add logical interfaces to the zone; and
Zones Chapter 25

3.
Optionally, identify some combination of system services and protocols allowed into the device through the
interfaces belonging to the zone. If you omit this step, all traffic entering through the zones interfaces destined for
the device is blocked.
Configuring Zones
To define a zone you must enter configuration mode, as illustrated in the inset.
Once you enter the configuration mode, you can define a zone type. Recall that you can configure only two types of zones
functional, which is used for device management only (no transit traffic is permitted), and security. You define zones under the
security configuration stanza. Note that user-defined zone names are case sensitive and can contain any standard
characters, like any other variable name in the Junos OS.
Two important configuration characteristics of the functional zone are as follows:
You can define only one type of functional zonemanagement; and
The functional zone does not have a user-defined name.
Chapter 26 Zones
Adding Logical Interfaces to a Zone
Now you are ready to add logical interfaces to the zone. The inset illustrates two variations. The first example illustrates adding
interface ge-0/0/1.0 to the security zone, called HR, and the second example illustrates adding interface ge-0/0/1.100 to the
functional management zone. If you omit the specification of the logical unit of the interface, the Junos OS assumes unit 0. Also,
you can assign all interfaces to a zone by using the keyword all. Should you choose to assign all interfaces to a zone, you will
not be able to assign any interfaces to a different zone.
Specifying Types of Traffic Permitted into the Device: Part 1

Without explicit configuration, traffic destined for a Junos security
platform is not permitted. You can specify types of traffic allowed into the
device using the host-inbound-traffic configuration option under
a specific zone or under an interface configured in a zone. All outbound
traffic originating from the device is always allowed.

When specifying types of traffic permitted into a Junos security platform,
you use some combination of the system-services and protocols
configuration options. The Junos OS provides you with the ability to refer to all system services and protocols and respective
ports with the help of the all keyword. To open all ports for all services, use the any-service keyword. In addition, you can
isolate any exceptions to the referred list of protocols or system services with the help of the except keyword. The examples on
the following pages illustrate the use of this keyword.
You can specify any of the following system services:
[edit security zones]
user@srx# set security-zone HR host-inbound-traffic system-services ?
all
All system services
any-service
Enable services on entire port range
dns
DNS and DNS-proxy service
finger
Finger service
ftp
FTP
http
Web management service using HTTP
https
Web management service using HTTP secured by SSL
ident-reset
Send back TCP RST to IDENT request for port 113
ike
Internet Key Exchange
lsping
Label Switched Path ping service
netconf
NETCONF service
ntp
Network Time Protocol service
ping
Internet Control Message Protocol echo requests
reverse-ssh
Reverse SSH service
Zones Chapter 27

reverse-telnet
rlogin
rpm
rsh
sip
snmp
snmp-trap
ssh
telnet
tftp
traceroute
xnm-clear-text
xnm-ssl
Reverse telnet service

Rlogin service
Real-time performance monitoring
Rsh service
Enable Session Initiation Protocol service
Simple Network Management Protocol service
Simple Network Management Protocol traps
SSH service
Telnet service
TFTP
Traceroute service
JUNOScript API for unencrypted traffic over TCP
JUNOScript API service over SSL
You can specify any of the following protocols:

[edit security zones]
user@srx# set security-zone HR host-inbound-traffic protocols ?
all
All protocols
bfd
Bidirectional Forwarding Detection
bgp
Border Gateway Protocol
dvmrp
Distance Vector Multicast Routing Protocol
igmp
Internet Group Management Protocol
ldp
Label Distribution Protocol
msdp
Multicast Source Discovery Protocol
ndp
Enable Network Discovery Protocol
nhrp
Next Hop Resolution Protocol
ospf
Open Shortest Path First
ospf3
Open Shortest Path First version 3
pgm
Pragmatic General Multicast
pim
Protocol Independent Multicast
rip
Routing Information Protocol
ripng
Routing Information Protocol next generation
router-discovery
Router Discovery
rsvp
Resource Reservation Protocol
sap
Session Announcement Protocol
vrrp
Virtual Router Redundancy Protocol.
Chapter 28 Zones
You can specify allowed traffic either at the zone level of configuration or the interface level within a zone. As with any
configuration in the Junos OS, the precedence rule of more specific configuration applies here as well. In other words,
interface-level configuration (as it is more specific) overrides the zone-level configuration. In the examples in the inset, only the
HTTP system service is allowed into interface ge-0/0/1.0, which is part of the HR Zone. All other interfaces associated with the
HR Zone can accept all system services.
Check Your Knowledge: Part 1
The inset shows an example of zone configuration. What types of traffic are allowed into the specified zone and interfaces? In
this example, a security zone named HR is configured. Interfaces ge-0/0/0.0 and ge-0/0/1.0 belong to that zone. Inbound
Telnet and FTP traffic are allowed into the device through these interfaces. All other inbound traffic that is local to the device on
these interfaces is dropped.
Zones Chapter 29
The inset shows another example of zone configuration. What types of traffic are allowed into the specified zone and interfaces?
In this example, a security zone named HR is configured. Interfaces ge-0/0/0.0 and ge-0/0/1.0 belong to that zone. As the
SNMP service is specified to be allowed only through interface ge-0/0/1.0, SNMP will not be allowed into interface ge-0/0/0.0.
In addition, Telnet and FTP services will be allowed only using the ge-0/0/0.0 interface and not the ge-0/0/1.0 interface.
Chapter 210 Zones
The inset shows the third example in this series. What does this configuration do? In this example, a security zone named zone1
is defined. It permits all inbound services with the exception of Telnet. There are two interfaces that belong to security zone
zone1ge-0/0/0.0 and ge-0/0/1.0. Interface ge-0/0/0.0 permits all services with the exception of Telnet. Interface ge-0/0/1.0
permits all services with the exception of HTTP and FTP services.
Zones Chapter 211
Monitoring Zones
The graphic illustrates the show security zones command, which is useful for zone monitoring. The command provides
information on the zone type and name along with the number and names of interfaces bound to the zone.
Chapter 212 Zones
Monitoring Traffic Permitted into Interfaces: Part 1
Using the show interfaces interface-name extensive command enables you to view zone specifics. The command
displays information on permitted protocols and system services allowed into the device through the corresponding interface. In
addition, the command provides information on flow statistics through the interface.
Monitoring Traffic Permitted Into Interfaces: Part 2
The inset provides the continuation of the output from the previous page.
Zones Chapter 213
Review Questions
Answers
1.
A zone is a collection of one or more network segments sharing identical security requirements.
2.
Overall, there are two types of zones in the Junos OSuser-defined and system-defined zones. User-defined zones include security and
functional zones, both of which you can configure. The Null Zone is a system-defined zone that you cannot configure. The security zone
allows transit packets and packets to the device itself. The functional zone allows only management traffic. The Null Zone is a placeholder
for interfaces that do not belong to any zone. All interfaces belonging to the Null Zone drop all packets.
3.
To configure a zone, you must perform the following steps: (1) Define a security zone or a functional zone; (2) Add logical interfaces to the
zone; and (3) Optionally, add services and protocols that must be permitted into the device.
4.
You can specify traffic types to be allowed into a Junos security platform using the host-inbound-traffic statement.
Chapter 214 Zones
Chapter 3: Security Policies

Security policy functionality;
Components of a security policy;
Verification and monitoring of security policies; and
Configuring a security policy.
What Is a Security Policy?
A security policy is a set of statements that controls traffic from a specified source to a specified destination using a specified
service. If a packet arrives that matches those specifications, the SRX Series device performs the action specified in the policy.
Network security policies are highly valuable for secure network functionality. Network security policies outline all network
resources within a business and the required security level for each resource. The Junos operating system provides a set of
tools to implement a network security policy within your organization. Security policies enforce a set of rules for transit traffic,
identifying which traffic can pass through the firewall and the actions taken on the traffic as it passes through the firewall.
Security Policies Chapter 31
Review: Packet Flow
The graphic reviews packet flow through the flow module of a Junos security platform.
When the device examines the first packet of a flow, based on incoming and outgoing zones, it determines the corresponding
security policy, and it performs a security policy lookup. The system checks the packet against defined policies to determine how
to treat the packet.
In this chapter, we focus on the security policies portion of the Junos OS.
Transit Traffic Examination
The Junos OS for security platforms always examines transit traffic by using security policies. As illustrated in the graphic, should
no match exist in the security policy, the default security policy applies to the packet. We highlight the default security policy in a
subsequent section.
Chapter 32 Security Policies
host-inbound-traffic Examination
If the destination of traffic is the devices incoming interface, security policies are not applicable. The only examination that
takes place is the list of services and protocols allowed into that interface using the host-inbound-traffic statement
within a zone definition. (See Chapter 3: Zones for details.)
The Junos OS examines security policies if the traffic destination is any interface other than the incoming interface. This process
is true regardless of whether the incoming interface and the destination interface are in the same zone (intrazone traffic) or in
different zones (interzone traffic).
The flowchart illustrates the order of packet examination. When the device receives traffic destined to itself, it first examines
whether the destination of the traffic is the incoming interface. If so, it skips the policy examination. Otherwise, the
corresponding security policies evaluate the traffic. If no policy match exists for the traffic, the default policy action applies. We
discuss the default security policy on the next page. If traffic matches a security policy that permits it, the device then examines
the list of services and protocols allowed into the destination interface within the corresponding zone, and applies the
corresponding action.
System-Default Security Policy
By default, the Junos OS denies all traffic through an SRX Series device. In fact, an implicit default security policy exists that
denies all packets. You can change this behavior by configuring a standard security policy that permits certain types of traffic, or
by configuring the default policy to permit all traffic as shown in the following screen capture.
[edit security policies]
user@srx# set default-policy permit-all
Factory-Default Security Policies

The factory-default template configuration file in branch security platforms has three preconfigured security policies (not to be
confused with the system-default security policy discussed in the previous paragraph):
1.
Trust-to-trust zone policy: Permits all intrazone traffic within the trust zone;
2.
Trust-to-untrust zone policy: Permits all traffic from the trust zone to the untrust zone; and
3.
Untrust-to-trust zone policy: Denies all traffic from the untrust zone to the trust zone.
Security Policy Conceptual Example
We now examine an example of a packet flow through a Junos security platform.

The devices interfaces are separated into three security zonesprivate, external, and public. The business requirement calls for
an SSH application to be allowed from Host B, located in the private zone, to Host D, located in the external zone. To meet the
requirement, we created the security policy illustrated in the graphic.
The following is the sequence of events that takes place:
1.
Host B initiates the SSH session to Host D.
2.
The Junos security device receives traffic and examines it using its security policy from the private zone to the
external zone. The security policy permits that traffic.
3.
The Host B-to-Host D flow triggers the creation of the reverse flow from Host D to Host B. The graphic identifies the
contents of this newly formed session. It consists of two flowssource to destination and destination to source.
4.
Host D sends the return traffic, from Host D to Host B. The device, using a pre-created session, permits the return
traffic through to Host B.
Policy Ordering
Because policies execute in the order of their appearance in the configuration file, you should be aware of the following:
Policy order is important.
New policies go to the end of the policy list.
You can change the order of policies in the configuration file using the Junos insert command.
The last policy is the default policy, which has the default action of denying all traffic.
Editing Security Configurations

Like any other Junos configuration stanza, you can delete, deactivate, activate, insert, annotate, copy, rename and search and
replace security policies.
What Is an ALG?
An ALG is a software process used to associate multiple connections from an application with the initial session that application
creates. Each ALG must be designed for a specific protocol, and all ALGs function slightly differently from each other.
The ALG module, which is part of the flow module on SRX devices, is responsible for Application-Layer-aware processing. The
ALG processing is performed in both the first-path and the fast-path. When the initial packet is received, the first path sets up
the ALG vector and the fast-path applies the ALG.
For an ALG to performs its role, it must do the following:
Inspect the packet for an embedded IP address and port information in the packet payload;
Open a gate for the IP address and port number to permit data exchange for the session; and
Perform Network Address Translation (NAT) processing if necessary.
FTP ALG Example
This graphic and the next several graphics provide an overview of the functionality of the FTP ALG during an active FTP session.
We begin our basic example by showing an FTP control session. By default, an FTP session uses both a control channel and a
data channel between the client and server. The control channel establishes from the client to the server using the well-known
TCP port 21.
FTP Data Session
Continuing with the FTP ALG example, the graphic shows the client successfully establishing a control connection, and the
server initiating a data connection originating from a port one lower then the control session. The server expects TCP port 20 for
the data connection, as this port is the default, well-known port.

However, because FTP uses a different connection for data transfers, it requires the intervention of the ALG. The initial FTP
request is initiated using port 21, which invokes the ALG.
Upon being invoked, the Junos OS FTP ALG opens a pinhole for server replies on the data channel. A pinhole is the opening of a
port to allow return traffic using the security policy that matches on the original traffic. After the control channel establishes
from client to server, the ALG creates a pinhole for the returning data channel, which is established from server to client.
Pinholes are common functions that are used by more than one ALG.
By default, the Junos OS uses the next lowest port for this transaction. With the use of the PORT command, the ALG parses the
statement and extracts the specified client port. A pinhole session holder can be created from the server data port to the new
client port.
FTP with the ALG Applied
As shown in this inset, with the FTP ALG applied, only the trust-to-untrust security policy is needed to allow traffic in both
directions. The trust-to-untrust security policy allows the initial client-to-server FTP control channel to establish using
port 21. The ALG allows for the return data channel to establish using port 20 from the same security policy.
FTP with the ALG Ignored

With the FTP ALG ignored, only the FTP control channel (port 21) is allowed to use the security policy trust-to-untrust,
which permits the initial FTP traffic. To allow the FTP data channel (port 20) from the server, policy untrust-to-trust is
needed to allow the return traffic. Another option is to create a custom application to allow passive FTP. You need only a single
security policy with passive FTP-the client initiates both control and data connections.
Supported ALGs and Behavior
The list of ALGs that the Junos OS supports is shown in the inset. A brief description of each ALG follows:
Domain Name System (DNS): The DNS ALG monitors the DNS reply packet. Once a reply packet returns from the
DNS server, the session closes.
FTP: For default FTP, the FTP ALG opens a pinhole for replies from server to client one port lower than the control
session. The FTP ALG monitors PORT, PASV and 227 commands. The FTP ALG also monitors EPRT, EPSV and 229
commands for IP version 6 (IPv6).
H.323: A number of dynamic ports must be determined to open the appropriate pinholes for the return traffic.
The ALG parses the various confirmation and response messages, and extract the network and transport
addresses that they contain. The ALG alters this data if NAT is in effect to replace public and private

addresses as needed. In addition, the ALG uses the embedded Transport layer address to open pinholes for
future communications to the peer client.
Media Gateway Control Protocol (MGCP): The MGCP ALG conducts voice over IP (VoIP) and MGCP signaling payload
inspection, provides stateful processing, performs NAT, and manages pinholes for VoIP traffic.
Point-to-Point Tunneling Protocol (PPTP): The PPTP ALG parses the control messages, looking for the outgoing
call request and outgoing call reply messages. The ALG opens up one gate to accept generic routing
encapsulation (GRE) traffic sent by the server and the other gate to accept GRE traffic sent by the client. The
ALG can support Port Address Translation (PAT) for PPTP.
Real-Time Streaming Protocol (RTSP): The RTSP ALG monitors the control connection, opens flows
dynamically for media streams, and performs NAT address and port rewrites.
Sun Microsystems Remote Procedure Call (SUNRPC): The SUNRPC ALG provides the functionality for handling
the dynamic transport address negotiation mechanism of the Sun RPC and to ensure program number-based
security policy enforcement. You can define a security policy to permit or deny all RPC requests, or to permit
or deny by specific program number. The ALG also supports route and NAT mode for incoming and outgoing
requests.
Microsoft Remote Procedure Call (MSRPC): The MSRPC ALG provides the functionality for handling the dynamic
transport address negotiation mechanism of the MSRPC, and to ensure universal unique identifier (UUID) based
security policy enforcement. You can define a security policy to permit or deny all RPC requests, or to permit or deny
by specific UUID number. The ALG also supports route and NAT mode for incoming and outgoing requests.
in (RSH): The RSH ALG handles TCP packets destined for port 514 and processes the RSH port command.
The RSH ALG also performs NAT on the port, in the PORT command and opens gates as necessary.
Session Initiation Protocol (SIP): The SIP ALG reads SIP messages and the Session Description Protocol (SDP)
content, and extracts the port-number information it needs to dynamically open pinholes to let the media stream
traverse the SRX device.
Skinny Client Control Protocol (SCCP): The SCCP ALG parses the remote IP address, the remote port in start
media transmission, and the open receive channel messages. The SCCP ALG then opens pinholes for the
return traffic.
Structured Query Language (SQL): The SQL ALG processes SQL Transparent Network Substrate (TNS)
response frame from the server side. It parses the packet and looks for the (HOST=ipaddress), (PORT=port)
pattern, and performs NAT and gate opening on the client side for the TCP data channel.
TALK: The TALK protocol uses UDP port 517 and port 518 for control channel connections. The talk program
consists of a server and a client. The server handles client notifications and helps to establish talk sessions.
The two types of talk servers are ntalk and talkd. The TALK ALG processes packets of both ntalk and talkd
formats. It also performs NAT and gate opening as necessary.
Trivial File Transfer Protocol (TFTP): The TFTP ALG processes the packet that initiates the request and opens a
gate to allow return packets to the port that sends the request.
Internet Key Exchange and Encapsulating Security Payload (IKE-ESP): The IKE-ESP ALG monitors IKE traffic
between the client and the server, and permits only one IKE Phase 2 message exchange between any given
client and server pair. Note that the IKE-ESP ALG is disabled by default.
ALG Configuration
You configure ALGs under the [edit security alg] hierarchy. Note that some ALGs have specific configuration options.
You can enable a disabled ALGfor example IKE-ESPunder this hierarchy as well. You can configure all ALGs for traceoptions.
This inset shows an example for the configuration options for the DNS ALG.
Applying ALGs
To apply an ALG to a custom application, configure
application-protocol under the [edit applications
application name] hierarchy. This configuration is needed for a
custom application to take advantage of the ALG. For example, when
creating a custom application for FTP, you must apply the ALG for it to
be associated with the custom FTP application. Use the application-protocol configuration option to also configure an
ALG to be ignored, which we cover later in the chapter.
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
Verifying ALGs
This inset shows the show security policies detailed command. The output indicates that the
trust-to-untrust policy has the FTP ALG applied to it. You can use other variations of this command for the same
information, which might be helpful if many policies are configured. The following screen capture provides another
example of how to show the details of a security policy:
user@srx> show security policies from-zone trust to-zone untrust policy-name
trust-to-untrust detail
Policy: trust-to-untrust, action-type: permit, State: enabled, Index: 6, Scope Policy:
0
Policy Type: Configured
Sequence number: 1
From zone: trust, To zone: untrust
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Destination addresses:
Security Policy Contexts

When defining a policy, you must associate it with a source zone, or incoming zonenamed the from-zone. Also, you must define
a destination zone, or an outgoing zonenamed the to-zone. Within a direction of source and destination zones, you can define
more than one policy, referred to as an ordered set of policies, which the Junos OS executes in the order of their configuration.
Recall that a zone is a collection of multiple logical interfaces with identical security requirements. The Junos OS always checks
all transit trafficintrazone and interzonethrough the use of security policies.
Security Policy Components

Within the defined context title, each policy is labeled with a user-defined name. Under the user-defined name is a list of
matching criteria and specified actions, similar to a Junos routing policy. One major difference is that each security policy must
contain a matching source address, destination address, and application. Actions for traffic matching the specified criteria
include permit, deny, reject, log, or count.
The Junos OS also uses policy to invoke the use of Intrusion Detection and Prevention (IDP) policies, the Unified Threat
Management (UTM) feature for branch devices, and firewall authentication. We discuss IDP and firewall authentication in detail
in subsequent chapters.
Policy Match Criteria
Each of the defined policies must include the following matching criteria:
Source addresses: This criterion can be in the form of address sets or individual addresses. You can group
individual addresses into address sets.
Destination addresses: This criterion can be in the form of an address sets or individual addresses. You can group
individual addresses into address sets.
Applications or application sets: This criterion can be user-defined or system-defined. The Junos OS supports
system-crafted default applications and application sets, referred to using the format junos-application,
where application is the name of the actual application. You can also define your own applications.
You must specify all matching components. If you omit any of these components, the Junos OS does not allow you to commit the
configuration.
Creating Address Book Entries
The inset illustrates the syntax that you must use when creating address book entries. An address book within a zone can
consist of individual addresses or address sets. An address set is a set of one or more addresses defined within an address
book. Address sets are useful when you must refer to a group of addresses more than once. If the matching criteria needs no

specific address, no address book entry is necessary. In this case, you can specify the configuration option any as the source or
destination address in a security policy.
IPv6 Addressing
In this inset, we show the syntax you must use when you create an IPv6 address book entry within a zone. You must enable the
inet6 flow-based option under the security forwarding-options hierarchy when adding an IPv6 address book
entry. After you issue a commit to activate inet6 flow-based, you must reboot the SRX device for the changes take effect.
If SRX devices are in a cluster, you must reboot both nodes. The following example shows how to verify the flow status of the SRX
device:
user@srx> show security flow status
Flow forwarding mode:
Inet forwarding mode: flow based
Inet6 forwarding mode: flow based
MPLS forwarding mode: drop
ISO forwarding mode: drop
Flow trace status
Flow tracing status: off
Creating a DNS Address Book Entry

The DNS address book entry allows for using
security policies to base the match criteria on a
domain name instead of an IP address. You
must configure the SRX device for a DNS server
for the DNS address book entry to allow the
specified domain name entry. This inset shows
how to configure a DNS address book entry and
a DNS server.
The following example is a detailed security policys output showing what to expect with a DNS address book entry. Under the
destination addresses, the domain name should be with the resolved IP address.
user@srx> show security policies policy-name name detail
Policy: name, action-type: permit, State: enabled, Index: 6, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: dc, To zone: untrust
Source addresses:
any-ipv4: 0.0.0.0/0
any-ipv6: ::/0
Destination addresses:
abc.com: 192.168.10.100/32

...
Defining Custom Applications
The Junos OS has many built-in applications, such as junos-rsh, junos-sip, junos-bgp, and so forth. You can customize
the list of predefined applications (thus expanding the overall list), which gives you the capability to support complex
applications.
[edit]
user@srx# show groups junos-defaults | match application | match junos
application junos-ftp {
application junos-tftp {
application junos-rtsp {
application junos-netbios-session {
application junos-ssh {
application junos-telnet {
...
To configure a custom application, define the application name, associate the application with a protocol and ports. Use the
application-protocol configuration option to associate the custom application with an application-level gateway (ALG). A
user-configured application has a timeout value associated with it. The Junos OS applies the timeout value to the created
session. Once the timeout expires, the software clears the session from the session table. You can modify the timeout value for
a specific application. Note that the new timeout value applies only to new sessionsnot to existing ones.
Viewing Predefined Applications

As the inset shows, use the show groups
junos-defaults applications configuration
mode command to view predefined applications. The
junos-defaults part of the command is hidden,
and therefore, you must fully type this part of the
command. Alternatively, the operational mode
command, show configuration groups
junos-defaults applications, provides the
same output.
On the inset, we show the predefined application junos-ftp.
Altering Predefined Applications

You might choose to alter predefined applications so that you permanently
change the defaults to settings you prefer. Although you can also create new
applications so that you do not alter the applications that are built in to the
Junos OS, doing so requires several additional steps and does not generally
warrant the time if you know that you will never want to use the built-in
applications with their default settings.
The following list provides some common reasons to alter predefined
applications:
You want to use a different port number for an application than that which is predefined, because not using
well-known ports might help you increase security.
You want to increase or decrease the predefined timeout value to alter how long an application can be inactive
before it times out.
You want an application to ignore the ALG, which effectively disables the ALG for that application, but still keep the
ALG enabled for other applications. (If you actually disable the ALG, the ALG is disabled for all applications.)
To alter predefined applications, create a new application with the same name as the built-in application. Create the new
application under the [edit applications] hierarchy. Remember that to view built-in application, issue the command
show groups junos-defaults applications.
The same options exist for altering a built-in application as for creating a custom application. You must configure only the
options you want to alter. The following example alters only the inactive timeout for the junos-ftp application from 1800
seconds to 3600 seconds; the other options stay as predefined.
[edit applications]
user@srx# show
application junos-ftp inactivity-timeout 3600;
Altering Predefined Applications Using Groups
You can alter predefined applications using a group configuration and applying it to the groupas long as the applications all
use the same IP protocol. Note, however, that you might find it difficult to find applications with enough in common to be able to
use a group configuration.
The inset illustrates how to create a group to alter the timeout for junos-ftp and junos-finger. The inset also shows that
the group is applied at the top of the configuration hierarchy using configuration mode. You can also apply the group at the
[edit applications] hierarchy as an alternative to the global configuration. The following is an example of applying the
group at the [edit applications] hierarchy:
[edit]
user@srx# show applications
apply-groups group-name;
Verifying the Altered Application
The output shows us that our group configuration for the application wildcard, <junos-f*> (which you can see in the previous
output), was successful. Note that the timeout value for both junos-ftp and junos-finger is now altered from its original,
default value.
Creating Policy Match Entries
You enter all policies under the from-zone...to-zone stanza for that particular traffic direction. The from-zone...to-zone
stanza associates the policies under it with a source zone and a destination zone. Under a specific zone direction, each security
policy contains a name, match criteria, and an action. This example focuses on match criteria. The system executes all policies
in the order of their appearance within a configuration file.
Basic Policy Actions

Each policy has a list of basic and advanced actions associated with it. The basic actions are the following:
permit: Allows traffic flow;
deny: Results in a silent packet drop; and
reject: Results in a packet drop and the sending of an Internet Control Message Protocol (ICMP) unreachable
message for UDP traffic and a TCP reset register suppression time (RST) message for TCP traffic.
Log and Count Traffic

For each of these actions, you can configure the Junos OS to log and count traffic as well. To view counters, use the show
security policies detail operational mode command. We discuss logging in detail in subsequent pages.
Advanced Permit Settings

Among the policy actions mentioned previously, the following advanced permit settings exist:
Firewall authentication;
IPsec VPN tunnel;
IDP; and
UTM features.
Firewall authentication enables you to restrict and permit users accessing protected resources that could be located in different
zones. The Junos OS offers two methods of firewall authentication:
Pass-through: Firewall users that are using FTP, Telnet, or the Hypertext Transfer Protocol (HTTP) to access
protected resources across the device receive authentication through a username and password. The Junos
security platform intercepts the session and then performs user authentication.
Web authentication: Firewall users use HTTP or HTTP over Secure Sockets Layer (HTTPS) to access an IP address of
the Junos security device, instead of the protected resource. The device acts as a proxy, authenticating the user
with a username and password and caches the information.
We discuss firewall authentication in more detail in the chapter titled, Firewall User Authentication.
If a policy associates with a preconfigured IPsec VPN tunnel, the tunnel creation occurs dynamically upon the receipt of the first
packet that matches such a policy. The policy-based IPsec VPN can be one of two typesIKE or manual. We discuss IPsec VPNs
in more detail in the chapter titled,IPsec VPNs.
A policy can associate with an IDP policy. IDP policies inspect traffic and enforce various attack detection and prevention
techniques. We discuss IDP in more detail in the chapter titled, Introduction to IDP.
In branch devices only, a policy can also associate traffic with UTM features such as antivirus, content filtering, and Web
filtering.
User Role Firewall Policies
Networks have used the IP address as a way of identifying users and servers. The strategy is based on the assumption that
users or groups of users connect to the network from fixed locations and use one device at a time. Wireless networking and
mobile devices require a different strategy. Individuals can connect to the network using multiple devices simultaneously. The
way in which devices connect to the network changes rapidly. It is no longer possible to identify a user with a group of statically
allocated IP addresses.

User role firewall security policies let you classify traffic based on the roles to which a user is assigned. Based on match criteria,
which includes the users role, you create policies to apply services that allow or block access to resources. The user role firewall
is similar to the identity-based Network Access Control (NAC) solution available with Unified Access Control (UAC) on the SRX
Series device. A user role firewall, however, does not require the Junos Pulse/Odyssey installation, and it supports agentless
transparent authentication.
User role information can be collected in several ways: locally on the SRX Series device, from a Junos Pulse Access Control
Service device, or by relaying authentication data from a third-party authentication server through a Junos Pulse Access Control
Service device to the SRX Series device.
Incorporating a third-party authentication server, such as WIndow Active Directory, into a user role firewall configuration can also
provide single sign-on (SSO) support. In this scenario, a MAG Series device must be used to relay authentication verification and
user role information from the Active Directory serve to the SRX Series device. This allows a browser-based user to authenticate
once and have that authentication communicated to other trusted servers in the domain as needed.
Using Global Policies

Security policies require traffic to enter one security zone and exit another security zone. This combination of a from-zone and
to-zone is called a context. Each context contains an ordered list of policies. Each policy is processed in the order that it is
defined within a context.
Security policies control traffic flow from one zone to another zone by defining the types of traffic permitted from specific
sources to specific destinations. This works well in most cases, but it is not flexible enough. For example, if you want to perform
actions on traffic but do not care about the zones you have to configure policies for each possible context. To avoid creating
multiple policies across every possible context, you can create a global policy. Global policies provide you with the flexibility to
perform actions on traffic without the restrictions of zone specifications.
You do not have to choose whether to use global security policies or regular security policies; you can use both at the same time
within a configuration. However, it is important to know that the regular security policies have a higher priority than global
policies. For example, if traffic matches a global policy and a regular policy, the action that the regular policy specifies is
honored.
Unlike other security policies, global policies do not reference specific source and destination zones. Global policies allow you to
regulate traffic with addresses and applications, regardless of their security zones. Global policies reference user-defined
addresses or the predefined address any. These addresses can span multiple security zones or you can define these address
in the global address book under the [edit security address-book global] hierarchy.
Then, you configure global policies under the [edit security global policy] hierarchy. Configuring a global policy is
similar to configuring a regular security policy, the only difference is the absence of the from-zone and to-zone criteria.
Using Global Policies
The graphic depicts a scenario in which a global policy can save you time and system resources. You would have to configure
three security policies to facilitate communication between the HR, Eng, and IT zones and the External zone. Also, for every

security policy that you create, a security context is created which uses system resources. Configuring individual security polices
in this manner does not scale well, especially in large deployments where there can be thousands of security zones.
Using a global security policy, as depicted in the graphic, can potential save you large amounts of time in configuring the SRX
device, and it can also reduce the system resource usage as well.
Policy Components Summary
The following is a summary of the policy components:
A security policy is positioned within the from-zone and the to-zone direction of traffic within the configuration;
Each policy has a set of matching conditions;
Each policy has a set of actions that the system performs upon success of all matching conditions;
Many security policies within the same direction of the flow can exist; and
Policy order is important, because policies execute in the order of their appearance in the configuration file.
Control Plane Logging

The Junos OS logs control plane events either locally or to an
external syslog device. Locally stored logs are stored on the
Routing Engine under the /var/log directory; you can view them
by using the show log log-name operational mode command.
To configure logs to be sent to an external syslog server, use the
host configuration option. The example shows the control plane
logging statements present in a factory-default configuration.
Branch Device Data Plane Logging
Data plane logging in Junos security platforms for the branch can be stored locally or on an external system log (syslog) server.
Use the session-close and session-init configuration options within a security policy to log the start and close of
sessions matching a policy. We suggest to use only session-close on production devices. Logging both session-close
and session-init will cause high CPU utilization on some SRX Series devices for the branch.
The output illustrates a sample log file configuration for branch devices. Logs are stored locally in the /var/log directory when
designated with a filename. To send logs to an external device, use the host IP-address configuration option.
The default facility and severity for data plane session logging is user info. To enable a Network and Security Manager (NSM)
device to be able to retrieve logs, name the log file default-log-messages, as shown in the output, and include the
structured-data configuration option.
High-End SRX Series Data Plane Logging
Data plane logging in high-end SRX Series devices can go to an external syslog device. The Junos OS supports limited local data
plane logging because of the high volume of session handling that a high-end SRX Series device supports. The inset illustrates
the configuration of data plane logging for high-end SRX Series devices.

Currently, the Junos OS supports one stream of logging traffic. Supported collection devices include UNIX syslogd-based servers
and the Juniper Networks Series Security Threat Response Manager (STRM).
Logging Sessions in Security Policy
Use the session-close and session-init configuration options to log the start and close of sessions matching a policy.
The inset illustrates the configuration of the policy log action.
Collecting Security Policy Statistics

Use the count security policy action to collect statistics and make them available using operational show commands. The
count security policy action is not necessary to enable statistics collection in security policy logs. Logs containing
session-close messages contain statistics by default. The case study later in this chapter provides examples of both forms
of statistics collection.
Operational Monitoring Commands
Various show commands are available for monitoring the application of security policy. The show security policies
command allows you to view details about an applied policy such as the policy index number, policy matching conditions, and
policy actions. Use the detail command option to view statistics associated with policy counters.
The show security flow session command displays active sessions on the device and each sessions associated
security policy. Note that this command output is categorized per Services Processing Unit (SPU) application-specific integrated
circuit (ASIC). The following output is from a services gateway containing two services processing cards (SPCs) and therefore,
four total SPUs. Only one session is active on the services gateway:
user@srx> show security flow session
0 sessions displayed
Session ID: 210000935, Policy name: permit-ftp/5, Timeout: 1768
In: 10.100.0.2/50054 --> 10.200.1.2/21;tcp, If: ge-1/2/1.10
Out: 10.200.1.2/21 --> 10.100.0.2/50054;tcp, If: ge-1/0/1.40
Tracing Security Policy
The configuration shown in the inset enables the tracing of security policy evaluation and sessions on a Junos security platform.
Use the packet-filter configuration option to log only details concerning selected sessions. Note that because of the
architectural design of Juniper Networks security and routing platforms, you can enable reasonably detailed tracing in a
production network without negative impact on overall performance or packet forwarding. However, a good practice would be to
deactivate traceoptions when not troubleshooting the device to reduce the impact on system resources.
Policy Scheduling
A policy scheduler is a method for
scheduling a policy execution for a
specified duration or a set of durations.
A policy scheduler is optional. A
scheduler supports system time
updates either through manual
configuration or through the Network Time Protocol (NTP) by synchronizing itself with the time changes.
Rules for Scheduling

The following rules apply to policy scheduling:
An individual policy can have only one scheduler applied;
Multiple policies can use the same scheduler; and
A scheduler must be referenced in a policy to become active. Without a defined scheduler within a policy, the policy
is always active.
Security Policy Scheduler Components

A security policy scheduler provides you with the flexibility to identify the start date and time and stop date and time for policy
enforcement. In particular, the scheduler components include the following:
Slot schedule: This component consists of the start date and time and the stop date and time of policy
enforcement; and
Daily schedule: This component consists of the start time, the stop time, the all-day option, and the exclude option.
Policy Scheduler Details
A policy scheduler turns on recurrently or once at the specified time. Recall that a policy scheduler activates and deactivates a
policy according to the scheduled time, which you configure. Once you create the scheduler, you must apply it to a policy. The
default behavior of a policy is to execute at all times.
Optionally Applying the

policy-rematch Statement
The default behavior of the Junos OS is to not
disturb sessions in progress when you make
configuration changes to security policies.
For example, you can modify an address field
or modify the actions of a policy used for
session examination. By default, because a
session was pre-established, it continues to
be operational without any interruptions. You
can change that default behavior by enabling
the policy-rematch statement. Once you
enable the statement, every time a
configuration change to a policy occurs, it
reflects in the sessions in progress.
Configuration changes, such as source
addresses, destination addresses, and application changes, cause policy re-evaluation as the system performs a policy lookup.
If the newly matched policy is not the policy referred to by the session, the session clears. If an IPsec VPN change occurs, the
Junos security platform clears the session.
The following list explains the actions that the Junos OS performs on impacted sessions in progress based on whether the
policy-rematch flag is enabled or disabled.
When the policy-rematch flag is enabled:
The software inserts a policy: no impact;
The software modifies the action field of a policy from permit to either deny or reject: all existing
sessions are dropped; and
The software modifies some combination of source address, destination addresses, and applications fields:
the Junos OS re-evaluates policy lookup.
When the policy-rematch flag is disabled (default behavior):
The software inserts a policy: no impact;
The software modifies the action field of a policy from permit to either deny or reject: all existing
sessions continue; and
The software modifies some combination of source address, destination addresses, and applications fields:
all existing sessions continue unchanged.
Note that irrespective of the value of policy-rematch policy flag, deletion of the policy causes the device to drop all
impacted existing sessions.
Case Study: Creating Policies
The next series of graphics present an example and configurations for a setup in which two zones existHR and Public. The
private PCs A and B, located in the HR Zone, must communicate with Server C in the Public Zone using a custom application set.
Restrictions are placed on the rest of the 10.1.0.0/16 network that are logged and counted.
Case Study: Entering Host Addresses into the HR Zone
The inset presents the configuration that adds host addresses belonging to zone HR. The hosts include PC_A and PC_B, whose
addresses are 10.1.10.5 and 10.1.20.5 respectively. The rest of the 10.1.0.0/16 subnet is also defined, which is named
all-10-1 in the address book. In addition, the PC_A and PC_B addresses are grouped into an address set named HR_PCs.
Case Study: Entering Host Addresses into the Public Zone
The inset presents the configuration that adds host addresses belonging to the Public Zone. The Public Zone has Server_C,
whose address is 1.1.70.250. The rest of the 1.1.7.0/24 subnet is also defined, named all-1-1-70 in the address book. In
addition, an address set, named address-Public, consists of the Server_C address for now.
Case Study: Adding New Applications

The inset presents the configuration of a new
application, HR-telnet, for the HR Zone. In the
configuration, source-port is an optional setting for
an application. The configuration shows that the new
application is added under the applications stanza.
In addition, the new application set, named
HR-Public-applications consists of two
predefined applications, junos-ftp and junos-ike,
and the newly defined HR-telnet application.
Case Study: Creating Policy Entries: Part 1

We must now define the policies from the HR Zone to the
Public Zone. We must define two policies.
The purpose of the first one, named HR-to-Public on the graphic, is to permit traffic from the HRzone to Public zone,
provided that its source address belongs to the address set HR_PCs, its destination address belongs to the address set
address-Public, and its application is part of HR-Public-applications. Matching traffic is logged and counted.
Case Study: Creating Policy Entries: Part 2
The graphic shows the definition of the next policy for the same directionfrom the HR Zone to the Public Zone. This policy
denies packets, logs, and counts packets for only the following cases:
The source address of the packet must be all-10-1;
The destination address must be all-1-1-70; and
The application must be junos-ftp.
If a packet does not match the previous policyHR-to-PublicorotherHR-to-Public, the default security policy
examines it, resulting in the device dropping it.
Case Study: Monitoring Security Policies: Part 1
The inset shows the output of the show security policies detail command for one of the policies in the case study.
We removed some content for brevity.
Case Study: Monitoring Security Policies: Part 2
The inset shows an example of the data plane log output resulting from live FTP traffic transiting the case studys security policy.
We captured the output on an external UNIX syslogd-enabled server.
Review Questions
Answers
1.
The basic components of a policy are: (1) policy name; (2) source zone and destination zone; (3) matching conditions, consisting of one or
many source addresses or sets, one or many destination addresses or sets, one or many applications or sets; and (4) actions.
2.
The default action for every policy set is to deny traffic.
3.
The policy scheduler enables the administrator to dynamically activate or deactivate a security policy.
4.
You can reorder policies using the Junos insert command.
Chapter 4: Firewall User Authentication

The purpose of firewall user authentication;
Implementing pass-through authentication;
Implementing Web authentication;
Using client groups; and
Monitoring firewall user authentication.
The Purpose of Firewall User Authentication
Firewall user authentication provides another layer of protection in the network on top of security zones, policies, and screens.
With firewall authentication, you can restrict or permit users individually or in groups. Users attempting to access a network
resource receive a prompt from the Junos operating system for a username and password even if a security policy is in place
permitting the traffic.
Users can be authenticated using a local password database or using an external password database. The Junos OS supports
RADIUS, Lightweight Directory Access Protocol (LDAP), or SecurID authentication servers.
The example in the inset illustrates a user (Host A) attempting to access a network resource belonging to the Public Zone. With
firewall user authentication configured, the user must first authenticate with the Junos security platform before accessing the
resource. In this example, the device can query an external authentication server to determine the authentication result. The
security policy must also allow traffic flow. Once the user receives authentication, subsequent sessions from the same source
IP address bypass firewall user authentication. This behavior is especially important when considering the usage of firewall
user authentication for a network that might have source-based Network Address Translation (NAT) employed.
Firewall User Authentication Chapter 41
Pass-Through Authentication
Two types of firewall user authentication are availablepass-through or Web authentication. Pass-through authentication must
first be triggered by Telnet, FTP, or Hypertext Transfer Protocol (HTTP) traffic. In this type of firewall authentication, the user
initiates a session to a remote network device or resource. If traffic matches the security policy configured for pass-through
authentication, the SRX Series Services Gateway intercepts the session. The user receives a prompt for a username and
password. If the authentication is successful, subsequent traffic from the same source IP address is automatically allowed to
pass through the device, provided it matches the applied security policy.
Web Authentication
Web authentication is valid for all types of traffic. With Web authentication configured, users must first directly access the Junos
security platform using HTTP. The user enters the address or hostname of the device into a Web browser and then receives a
prompt for a username and password. If authentication is successful, the user can then access the restricted resource directly.
Subsequent traffic from the same source IP address is automatically allowed access to the restricted resource, as long as
security policy allows for it.
Authentication Server Support
Local Authentication
The Junos OS supports local authentication on the Junos security platform itself as well as RADIUS, LDAP, and SecurID external
authentication servers. The local password database supports authentication and authorization.
RADIUS Authentication
The Junos OS supports RADIUS for authentication as well as authorization. The Junos security platform acts as a RADIUS client
and communication uses UDP. RADIUS uses a shared secret key to encrypt user information during the exchange.
LDAP Authentication
An LDAP server is another form of external authentication server. The Junos OS supports authentication only when utilizing an
LDAP server. The Junos OS is compatible with LDAP Version 3 and Microsoft Windows Active Directory.
SecurID Authentication
An RSA SecurID server can be used for external authentication. This method allows users to enter either static or dynamic
passwords as credentials. A dynamic password is a combination of a users PIN and a randomly generated token that is valid for
Chapter 42 Firewall User Authentication

a short period of time. The Junos OS supports SecurID servers for authentication only and does not support the SecurID
challenge feature.
Pass-Through Authentication
The inset illustrates the process used for pass-through firewall authentication. A user attempts to connect directly to a remote
network resource using either Telnet, HTTP, or FTP. The Junos security platform intercepts the first packet and stores it in
memory. The device prompts the end user for a username and password. If authentication is successful, a configurable banner
displays to the user, and the original buffered packet travels to its destination. The Junos OS allows subsequent traffic from the
same source IP address until the user is idle for 10 minutes. At this point, authentication must be performed again for further
traffic to pass through the device. The default idle timeout of 10 minutes is configurable as shown:
[edit access profile profile-name]
user@srx# set session-options client-idle-timeout ?
<client-idle-timeout> Time in minutes of idleness after which access is denied
Creating an Access Profile
The inset provides an example of a basic access profile. This example shows the configuration of a user-defined profile name.
One or more clients are configured within the profile, representing end users. The client-name represents the username. The
password is entered in plain-text format but displays in encrypted form when you view the configuration.
Associating the Access Profile with an Authentication Type
Once an access profile has been defined, it must be associated with pass-through firewall authentication. The inset shows a
basic example of this configuration. The Junos OS also allows you to set a customized banner that will display to the end user.
The Junos OS can display an initial login banner, a successful authentication banner, and a failed authentication banner when
configuring pass-through authentication.
Apply Pass-Through Authentication as Policy Action
Enable pass-through and Web authentication using security policies. To be subject to firewall user authentication, traffic must
align with the policys matching conditions and have an extended action of permit, specifying the type of firewall authentication
to use. The inset shows an example of applying pass-through firewall authentication to a security policy.
Web Authentication
The inset illustrates the process used for Web firewall authentication. A user that requires access to a remote network resource
must first access the Junos security platform directly using a Web browser. The device prompts the end user for a username and
password. If authentication is successful, a configurable banner displays and the user gains permission to access the remote

resource. The Junos OS allows subsequent traffic from the same source IP address until the user is idle for 10 minutes. At this
point, authentication must be performed again for further traffic to pass through the device. The default idle timeout of 10
minutes is configurable as shown here:
[edit access profile profile-name]
user@srx# set session-options client-idle-timeout ?
<client-idle-timeout> Time in minutes of idleness after which access is denied
Enabling the HTTP Process

To use Web authentication, the SRX Series device must initiate the httpd
process. The inset highlights the required configuration to enable this system
process for the device. The highlighted configuration allows HTTP access for
Web management using the J-Web user interface and also allows for the use of
Web authentication. You can also configure this feature to restrict access to an
individual interface or a group of interfaces. The security zone containing the
interface to be used for Web authentication (or for the J-Web user interface)
must allow HTTP traffic as host inbound traffic.
Enabling Interface for Web Authentication
The interface that users access for Web authentication must be enabled for authentication.
The inset illustrates a sample configuration for enabling Web authentication on the ge-0/0/0 interface. We recommend using a
secondary IP address as the Web authentication address. The Web authentication address must be in the same subnet as the
primary interface address. Use the preferred configuration option to ensure that traffic sourced from this interface continues
to use the primary address as its source address.
Creating an Access Profile

Web authentication can use the same profile as
pass-through authentication. The example in the
inset shows the configuration of a user-defined
profile name. One or more clients are configured
within the profile representing end users. The
client-name represents the username. The user
enters the password in plain-text format but it
displays in encrypted form when you view the
configuration.
Associating the Access Profile with an Authentication Type

The access profile must associate with Web authentication using the
same configuration structure as pass-through authentication. The
inset shows a basic example of this configuration. The Junos OS also
allows you to set a customized banner that will display to the end
user. Web authentication supports a customized banner for
successful authentication only.
Applying Web Authentication as Policy Action
Pass-through and Web authentication are enabled using security policies. To be subject to firewall user authentication, traffic
must align with the policys matching conditions and have an extended action of permit, specifying the type of firewall
authentication to use. The inset shows an example of applying Web firewall authentication to a security policy.
A Cleaner Method of Web Authentication

Directly accessing the device through a browser before
gaining access to a remote resource is burdensome. To
alleviate this burden, the Junos OS allows Web
redirection. The inset illustrates the configuration of Web
redirection. With Web redirection enabled, the device
responds to the user device with an HTTP redirect
message, which tells the user device to use HTTP to
access the Junos security platform at a particular
address. The Junos OS uses the address of the interface
on which the initial user request was received. You must
enable Web authentication for this interface and for the system itself, just as you would for standard Web authentication.
Using Client Groups
A client group is a list of groups associated with a client. Client groups allow for easier management of multiple firewall users.
Security policy references client groups in the same manner in which it references individual clients. The graphic shows a simple
conceptual example of using client groups to manage multiple users. The next two sections utilize this example for illustrating
the configuration of client groups.
Adding Client Groups to a User
The inset provides an example configuration of three users associated with various groups. A number of groups (contained in
square brackets in the example configuration) represent a client group. Groups are not configured elsewhere, thus the
utilization of the tab key can be beneficial to ensure that you do not inadvertently create extra groups.
Configuring a Policy to Use Client Groups
Once client groups have been organized, groups can be referenced in a security policy with firewall authentication. Groups can
be used in place of individual clients. The inset illustrates the use of a client group in a security policy. In this example, Group-A
from the previous page is subject to pass-through authentication.
Check Your Knowledge
In the referenced example configuration, firewall authentication is enabled and the security policy specifies only client group
Group-A. Client group Group-A associates with user1 and user2. Therefore, user1 and user2 have access to the engineering
remote network resource (if they authenticate successfully).
What if All Three Users Use the Same Source IP Address?

Firewall user authentication is based on the source IP address. As we discussed earlier in this chapter, once firewall
authentication is successful, subsequent sessions from the same source IP address are not subject to further authentication
within the idle timeout period. In this example, if user1 or user2 were to authenticate first, user3 would also be able to access
the remote engineering resource.
Default Client Groups
The Junos OS allows the configuration of a default client group to serve as a catch-all for all users within an access profile. This
setup allows ease of management by categorizing users in access profiles. If a user or client does not associate with a client
group and a default client group exists, the user associates with the default client group. The client group can consist of one or
more groups.
Adding Servers to the Access Profile
You configure external authentication server details within an access profile. The Junos OS supports only one external
authentication server for access profiles, but you can use it in conjunction with the local password database. You must specify
an authentication order if you plan to use an external server. The Junos security platform will try to authenticate with the first
method listed. If the configuration does not list the password database in the authentication order and the listed method of
external authentication is unreachable, the Junos OS still consults the local password database. However, if the listed external
authentication method fails, the Junos OS does not consult the local password database, denying user access.
Viewing the Authentication Table
The example in the inset illustrates how to view the current authentication table. This table contains a list of users and their
associated access profiles. It shows the source IP address, source and destination security zones, the authentication result, and
the current age of the idle timer. You can also sort the authentication table by source IP address or user ID by issuing the
command with the address or identifier command options as shown in the following output:
user@srx> show security firewall-authentication users ?
<[Enter]>
Execute this command
address
Locate authentication entry by ip address
identifier
Locate authentication entry by id
Viewing Authentication Table History
The inset shows how to view a historical authentication table. This table keeps a record of firewall authentication attempts in
brief form, including date and time stamps. This command also supports the use of the address and identifier command
options.
Review Questions
Answers
1.
The Junos OS supports RADIUS, LDAP, and SecurID external authentication servers.
2.
In pass-through authentication, the user attempts to access the remote network resource directly, and the Junos security platform intercepts
the session to perform firewall authentication, while buffering the session. The buffered session is released as long as authentication is
successful. In Web authentication, the user must first access an IP address belonging to the Junos security device using a Web browser; the
authentication is performed using this HTTP session. The user can then proceed to access the remote network resource as long as
authentication is successful. FTP, Telnet, and HTTP traffic trigger pass-through authentication, while an HTTP session must trigger Web
authentication.
3.
A client group is a list of groups associated with a client. Groups can be used in security policies in place of individual clients for ease of
management.
4.
Use the show security firewall-authentication history command to view a history of firewall authentication
attempts.
Chapter 5: Screen Options

Screen options and their meanings;
Various types of attacks prevented by Screen options;
Screen options advantages;
Configuration of Screen options; and
Applying and monitoring Screen options.
Networks Are Under Attack
Although basic network security issues have changed very little over the past decade, the network security landscape has
changed dramatically. Todays IT professionals must still protect the confidentiality of corporate information, prevent
Screen Options Chapter 51

unauthorized access, and defend the network against attacks. They also face new challenges as their networks become more
complex and dynamic. The following list examines some of these issues:
Ubiquitous Internet access: The growing availability of Internet access has made every home, office, and business
partner a potential entry point for an attack. The corporate network is vulnerable to attacks from both deliberate
attackers as well as remote users who might log onto the corporate network while unknowingly hiding an attack
within their sessions. The trend of working at home and using a work PC for personal use increases the possibility
of dangerous and annoying attacks such as spyware, phishing, and spam.
Internal attacks: While stopping external attacks remains a constant challenge, the attacks that originate from
inside the network by employees are equally challenging. Internal attacks can range from unauthorized server or
resource access to a disgruntled employee destroying or stealing proprietary information.
Regulatory compliance: As new national and industry regulations emerge, security is a continual emphasis.
Whether the requirement is to encrypt all data or simply to protect it from unauthorized access, complying with
these new regulations complicates matters for you as a security administrator.
Changing levels of trust: Remote employees, business partners, customers, and suppliers might have different
levels of access to corporate resources. You must take appropriate measures to protect the corporate network at
all these levels. While the number of applications to which remote users have access through the demilitarized
zone (DMZ) increases, companies are simultaneously trying to reduce costs by minimizing the application
instances between internal and external users. This approach makes it necessary for security policies to
accommodate application use by both groups.
Points of Vulnerability Equal Points of Control
The key to striking a balance between tight network security and the network access required by employees, business partners,
and customers is a layered security solution. A layered security solution gives you a complete set of tools you can deploy to
achieve end-to-end security from the remote site to the data center. If one layer fails, the next layer stops the attack, limits the
damage that might occur, or does both.
Layered security allows you to apply the appropriate level of resource protection to the various network entry locations based
upon your different security, performance, and management requirements. The following are vulnerable points in the network:
Remote access occurs when a user connects to the corporate network through a public or private connection. The
key security goal to pursue with remote access is the protection of content and user identity as they traverse the
network.
Chapter 52 Screen Options
Site-to-site communications, both employee and nonemployee, are the interactions between two offices of any type
or any size. The site-to-site security layers must protect resources at both sites from external threats such as
session hijacking, U-turn attacks, and Trojan or worm attacks launched from a trusted PC that has been
compromised. Internal attacks are increasingly common and can include unauthorized server access, improper
use of bandwidth, and planting of spyware.
The network perimeter represents the point at which external traffic gains initial access to the network, as well as
the point through which internal traffic traverses the Internet. With the diversity of traffic that the perimeter
represents, the security solution must protect against the widest range of attacks using an assortment of security
layers that can include a VPN, denial of service (DoS) protection, a firewall, antivirus scanning, an intrusion
detection service (IDS), and possibly antispam scanning.
At the heart of an enterprise is the network data center (or network core) where the applications and data that
drive day-to-day business reside. Financial, human resources, and manufacturing applications with supporting
data represent the company crown jewels and, if compromised, can sink even the most stable enterprise. The core
network security layers must protect these business-critical resources by preventing unauthorized user access,
containing internal attacks launched by disgruntled employees, and protecting against application-level attacks.
In conjunction with applying layered security to the network core, IT departments are increasingly deploying
security internally on LANs to prevent unauthorized user access to network resources, to encrypt and decrypt
communications, and to contain damage that might occur if an attack succeeds.
Attack Detection System: Screen Options

The most obvious element of the Junos operating system for security platforms is basic access control using security policies.
These policies define who and what has access to the network. The Junos OS uses stateful inspection to protect the network
from malicious content. With stateful inspection, Junos security platforms collect data such as source and destination IP
addresses, source and destination port numbers, and packet sequence numbers from TCP and UDP pseudosessions. The
device then maintains this data in state tables for future use in analyzing traffic.
Through the deployment of custom security zones, you can use the Junos OS not only to protect the perimeter of your network,
but also to provide segmentation of your internal infrastructure. Used internally, SRX Series Services Gateways provide
additional layers of access control to protect against the organization's sprawling definition of authorized user.
Using Screen options, Junos security platforms can protect against more than 30 different internal and external attacks,
including SYN flood attacks, UDP flood attacks, and port scan attacks. DoS attack protection leverages stateful inspection to
look for and then allow or deny all connection attempts that require crossing an interface on their way to and from the intended
destination.
When applied, Screen options pertain to traffic at its entry point. The Junos OS applies Screen checks to traffic prior to the
security policy processing, thereby resulting in less resource utilization.
Review: Packet Flow
Before discussing Screen options, we revisit packet flow through a Junos security platform. Note that Screen processing occurs
before any packet processing, which results in fewer resources used and better protection of the Junos security platform itself.
Stages of an Attack
To understand Screen option configuration, we must first discuss the stages of network attacks and the types of network
attacks. A network attack consists of three major stages. In the first stage, the attacker performs reconnaissance on the target
network. This reconnaissance might consist of many different kinds of network probes. In this information-gathering phase, the
attacker works to gather information about the target network, any open ports, and the operating systems in use.
In the second stage, the attacker launches an attack at the target network. To protect themselves, attackers must also conceal
the origin point of the attack and attempt to remove any evidence that an attack took place.
Depending on the type of attack, a third phase can occur. After infiltrating a trusted machine, the attacker can use that machine
as a point of origin for further invasion of the network. Traffic now appears to originate from the trusted system, which might not
be subject to the same security scans as an outside system.
IP Address Sweep
Attackers can better plan their attack
when they first know the layout of the
targeted network, possible entry
points, and constitution of their victims.
An address sweep occurs when one source IP address sends Internet Control Message Protocol (ICMP) packets to different
hosts. The purpose of this scheme is to send traffic to various hosts in hope that one replies, thus revealing an address to
target.
Port Scanning
A port scan occurs when one source IP address sends IP packets containing TCP SYN segments to different ports at the same
destination IP address. The purpose of this scheme is to scan services in hope that one port will respond, thus identifying a
service to target.
IP Options
RFC 791, Internet Protocol, specifies a set of options to provide special routing controls, diagnostic tools, and security. RFC
791 states that these options are unnecessary for the most common communications and, in reality, they rarely appear in IP
packet headers. When they do appear, they are frequently being put to illegitimate use.
OS Probes
An attacker might try to probe the targeted host to learn its operating system. Because TCP standards do not dictate how to
respond to anomalous traffic, different operating systems respond differently to anomalies. The response to the anomaly gives
the attacker information about the type of operating system running on a given host.
Evasion Techniques
Whether gathering information or launching an attack, the attacker generally tries to avoid detection. Although some IP address
and port scans are blatant and easily detectable, more advanced attackers use a variety of means to conceal their activity.
Forms of Denial of Service Attacks
The intent of a DoS attack is to overwhelm the targeted victim with a tremendous amount of fake traffic so that the victim
becomes so preoccupied processing fake traffic that it is unable to process legitimate traffic. In the case of a router or firewall
device, the goal of a DoS attack is to fill up the device session table so that no new sessions can be established. An attacker can
also launch a network DoS or a DoS targeting various operating systems.
This chapter explains each of the attacks and the ability of the Junos OS to handle these attacks.
Types of Attacks: Suspicious Packets
Attackers can craft packets to perform reconnaissance or launch DoS attacks. Sometimes the intent of a crafted packet is
unclear, but its crafted nature suggests that it is being put to an insidious use.
Screen OptionsBest Practices
Prior to analyzing Junos Screen options in detail, we discuss best practice suggestions for Screen option use.
You should understand the applications and their behavior within your network before you begin implementing features that
might have an impact on legitimate traffic. Furthermore, you must understand the traffic patterns traversing your network. To
determine appropriate thresholds for limit-based Screen functions, you must first know what is typical of your network. For
example, if you want to enable SYN flood protection, you must first determine what constitutes an acceptable number of
connection requests. This determination requires a period of observation and analysis to establish a baseline for typical traffic
flows. You must also consider the maximum number of concurrent sessions required to fill up the session table of the particular
Junos security platform you are using. To see the maximum number of sessions that your session table supports, use the CLI
command show security flow session summary. Remember the output of this command reports statistics for each
Services Processing Unit (SPU) separately.

You can use the alarm-without-drop statement, as illustrated in the inset, to gather the traffic going to and through your
Junos security platform. The gathered information might help you to better understand your networks vulnerabilities. Typically,
you want to deploy Screen options only in vulnerable zones.
IP Address Sweep and TCP Port ScanThe Attack

An address sweep occurs when one source IP address sends a predefined number of ICMP packets to various hosts within a
predefined interval of time. The purpose of this attack is to send ICMP packets, which are typically echo requests, to various
hosts, hoping that at least one host replies. Once attackers receive a reply, they uncover an address, which becomes a target.
Port scanning occurs when one source IP address sends IP packets containing TCP SYN segments to a predefined number of
different ports at the same destination IP address within a predefined time interval. This attack attempts to scan the available
services hoping that at least one port responds, thereby identifying an attack target.
IP Address Sweep and TCP Port ScanThe Defense

The Junos OS internally logs the number of ICMP echo request packets from one remote source. You can set up a threshold
interval, ranging from 1000 to 1,000,000, measured in microseconds for those ICMP packets. The default threshold value is
5000. By using the default settings, if a remote host sends ICMP echo request traffic to 10 addresses in 0.005 seconds (5000
microseconds), the Junos security platform flags that remote host as an address sweep attacker. The flagging process results in
the denial of all further ICMP echo requests from that host for the remainder of the configured threshold time period.
For TCP port scanning protection, the Junos OS internally logs the number of different ports scanned from one remote source.
The configured threshold value is in microseconds, ranging from 1000 to 1,000,000. The default threshold value is 5000
microseconds. The Junos OS flags the traffic as an attack when 10 ports are scanned within the threshold value. Once port
scanning detection triggers, the Junos OS silently drops all further packets from the remote source for the remainder of the
configured threshold time period.
IP Address Sweep and Port ScanningScreen Options
The inset illustrates an IP address sweep or port scanning attack. During an IP address sweep attack, the attacker, using one
source IP address, sends ICMP packets to different hosts in hopes that at least one host replies, thereby uncovering an address
to target.

During a port scanning attack, the attacker, using one source IP address, sends IP packets containing TCP SYN segments to a
defined number of different ports at the same destination IP address within a defined interval. The attacker hopes that at least
one port responds, thereby uncovering a service to target.
To block IP address sweeps or TCP port scans originating in a particular security zone, you must perform the configuration
illustrated in the inset. Note that this configuration only defines the Screen optionit does not activate it. To activate the Screen
option, you must apply it within a security zone. We address this topic later in the chapter.
IP OptionsThe Attack
RFC 791 specifies a set of options within an IP packet, providing special routing controls, diagnostic tools, and security. Within
an IP packet header, these options come after the destination address field. Although the original intent for these options was to
enhance network functionality, most common communications do not require them. As the Internet expanded and continues to
expand, attackers have started abusing the options field of a packet, causing problems to networks and network devices. An
attacker can abuse the record route, timestamp, security, and stream ID fields.
IP OptionsThe Defense
To compensate for the vulnerability that these IP options fields create, the Junos OS tracks packets that have any of these
option fields used, flags them as a network reconnaissance attack, and records the event. You can view the events in the Screen
counters list for the ingress interface.
IP OptionsScreen Options
The inset illustrates an IP packet header, highlighting the options field. An attacker can misuse bits within the options field to
cause problems with networks. You can define Screen options to detect the IP options that an attacker can use. These IP
options fields include record route, timestamp, security, and stream ID. The Junos OS flags an event in which a device
configured with the appropriate Screen options receives a packet with any of these IP options. The Junos OS marks the event as
a network reconnaissance attack and records the associated ingress interface.
The inset illustrates the syntax for this Screen option definition. You can configure each of the options independently. Note that
this configuration only defines the Screen optionsit does not activate them. To activate the Screen options, you must apply
them within a security zone. We address this topic later in the chapter.
Operating System ProbesThe Attack

Prior to launching an exploit, an attacker might probe the targeted host, trying to learn its operating system. Various operating
systems react to TCP anomalies in different ways. With that knowledge, an attacker can decide which further attack might inflict
more damage to the device, the network, or both.
Operating System ProbesThe Defense

The Junos OS configured with the appropriate Screen options blocks operating system probes by detecting any of the following
invalid TCP flag settings:
Both SYN and FIN flags set;
FIN flag set and ACK flag not set; or
No flags set.
TCP traffic matching any of these criteria is immediately, and silently, dropped.
Operating System ProbesScreen Options
The inset illustrates the TCP header, highlighting the SYN and FIN flags, which an attacker might use to launch the attack. The
inset also illustrates the configuration of Screen options designed to block these probes. You configure each statement
independently as follows:
To detect the condition when both SYN and FIN flags are set, use the syn-fin configuration option;
To detect the condition when the FIN flag is set and the ACK flag is not set, use the fin-no-ack configuration
option; and
To detect the condition when no flags are set, use the tcp-no-flag configuration option.
Note that this configuration only defines the Screen optionsit does not activate them. To activate the Screen options, you must
apply them within a security zone. We address this topic later in the chapter.
IP SpoofingThe Attack
IP address spoofing is one of the earliest and most well known attacks. An attacker simply inserts a fake source address into the
packet header source address field in an attempt to make the packet appear as if it is coming from a trusted source.
IP SpoofingThe Defense
The Junos OS provides IP address spoofing detection with the help of forwarding table entries. The Junos OS compares the
source IP address of an incoming packet with the closest prefix match found in its forwarding table. If the interface associated
with that prefix is different from the ingress interface of the packet, the software concludes that the packet has a spoofed
source IP address and discards it. Once it detects IP spoofing, the Junos OS silently drops all spoofed packets.
IP Spoofing DetectionScreen Option
The graphic illustrates an IP spoofing attack in which the attacker uses an IP address belonging to the range of IP addresses
within the private zone. The Junos OS compares the source IP address 168.10.10.1 of the incoming packet with the closest
match prefix found in its forwarding table, which is 168.10.10/24. It then detects that the interface associated with prefix
168.10.10/24 is different from the ingress interface of the packet, which is ge-1/0/0. The software concludes that the packet
has a spoofed source IP address and discards it.
To set up the Junos IP spoofing Screen option, you must perform the configuration shown in the inset. Note that this
configuration only defines the Screen optionit does not activate it. To activate the Screen option, you must apply it within a
security zone. We address this topic later in the chapter.
IP Source Route OptionsThe Attack

Source routing allows users to specify the packets desired path when traversing a network. This feature provides additional aid
to users during network troubleshooting.
Unfortunately, over the years, attackers have started to abuse source route options. They use the fields to hide their true
address and access restricted areas of a network by specifying a different route.
IP Source Route OptionsThe Defense

Depending on the configuration, the Junos OS either blocks any packets with loose or strict source route options settings, or
detects those options as being set, and records them. If you choose to block the suspect packets, the software silently discards
the packets.
IP Source Route OptionsScreen Options
Using the illustration shown in the inset, we assume that network 3.3.3.0/24 checks for spoofed IP addresses. The attacker,
who is aware of this checking, wants to direct traffic through network 5.5.5.0/24. The attacker spoofs the source address to be
part of network 5.5.5.0/24, and by using the loose source option, directs the packet through network 5.5.5.0/24. Because the
packet came from the 5.5.5.0/24 network and has the source address of that subnet, it seems to be valid. However, it has the
loose source route option set. We also assume that you enabled the Screen option that discards the packets with the source
route option set. As a result, when the packet arrives at the ge-1/0/0 interface, the Junos security platform rejects it.
To set up the Junos IP source route options Screen options, you must perform configuration as shown in the inset. You can
configure each of the options independently. Note that this configuration only defines the Screen optionsit does not activate
them. To activate the Screen options, you must apply them within a security zone. We address this topic later in the chapter.
Goals of DoS Attacks

If attackers discover a firewall, they might launch a DoS attack against it. In fact, many attackers consider the successful DoS
firewall attack to be equivalent to a network attack because a firewall under DoS stops sending any traffic to and from a
protected network.
Firewall and Router Device DoS Attacks

An attacker might use two methods in an attempt to immobilize a Junos security platform. Because the Junos OS for security
platforms is a session-based operating system in which each packet flow creates a session, DoS attacks attempt to fill up the
session table in the hope that the device will reach its session table limit. Attackers can use two methods to fill up the session
table: session table flood and SYN-ACK-ACK proxy flood.
Network DoS Attacks

A network DoS attack results in the flooding of many network resources with enormous amounts of some combination of SYN,
ICMP, and UDP packets. Depending on the learned intelligence information, an attacker might target a specific host or a specific
network segment for attacks. The Junos OS has the capability to mitigate those attacks, which we discuss in the upcoming
pages.
OS-Specific DoS Attacks

Should attackers identify an OS in use, they might launch an OS-specific DoS attack, focusing on one-packet or two-packet kills.
These attacks include the Ping of Death attack, the Teardrop attack, and the WinNuke attack. The Junos OS has the capability to
mitigate these attacks, which we discuss in the upcoming pages.
Firewall and Router Device DoS:

Session Table FloodThe Attack
The inset lists some of the forms that session
table floods can take.
Firewall and Router Device DoS: Session Table FloodThe Defense

To control session table floods, the Junos OS offers the ability to set up a source-based session limit so that it can prevent
attacks such as the Nimda virus (which infects servers and then generates massive amounts of traffic from those servers). By
recognizing that all connection attempts originate from the same source IP address, the Junos session table flood control also
mitigates any attempts to fill up the session table of the attacked Junos security platform.
In addition to the source-based session limit, the Junos OS offers the flexibility to limit the number of concurrent sessions to the
same destination IP address, which protects your device from a distributed denial of service (DDoS) attack. DDoS attacks can
come from hundreds of various hosts, known as zombie agents, which are under the control of an attacker.
Session Table FloodScreen Option
The inset illustrates the required configuration to limit the number of concurrent sessions based on source IP address,
destination IP address, or both.
The Junos OS offers a default maximum number for a source-based or destination-based session limit, which is 128 concurrent
sessions. The valid range of sessions depends upon the type of Junos security platform.
Note that the configuration shown only defines the Screen option. To activate the Screen option, you must apply it within a
Firewall and Router Device DoS: SYN-ACK-ACK Proxy FloodThe Attack
A SYN-ACK-ACK attack uses TCP connections. The attacker, using a seemingly normal TCP connection, sends the SYN-ACK-ACK
pattern, hoping that the targets will respond and immobilize themselves. In the illustration shown on the graphic, a malicious
user initiates a Telnet connection. The user sends a SYN segment to the Telnet server behind the Junos security platform. The
Junos OS intercepts the SYN segment, creates an entry in its session table, and proxies a SYN-ACK segment to the user. The
user replies with an ACK segment. At this point, the initial three-way handshake is complete. The server sends a login prompt to
the user. The malicious user does not log in. Instead, such a user continues to initiate SYN-ACK-ACK sessions, leading the
devices session table to its limit, which can result in rejecting legitimate connection requests.
SYN-ACK-ACK Proxy Flood: The Defense
SYN-ACK-ACK proxy protection enables a Junos security platform to detect malicious intent behind a seemingly normal TCP
connection. Because the device acts as a proxy for a TCP connection, creating a session table and proxying a SYN-ACK segment
to the sender, it can detect SYN-ACK-ACK sessions appearing after the success of the initial session setup. The Junos OS rejects
further connection requests from an IP address after the number of connections from that address reaches the SYN-ACK-ACK
proxy threshold. The default value of the proxy threshold is 512 connections from a single IP address. The configured threshold
can range from 1 to 250,000 connections.
The inset illustrates the syntax required to configure the SYN-ACK-ACK proxy flood Screen option, limiting the number of
concurrent TCP sessions from a single source.
Note that this configuration only defines the Screen optionit does not activate it. To activate the Screen option, you must apply
it within a security zone. We address this topic later in the chapter.
Network DoS: SYN FloodThe Attack

A SYN flood occurs when a network resource becomes overwhelmed with SYN segments initiating uncompleted connection
requests to the point where it cannot accept legitimate connections. Very often a SYN flood attack inundates a site with SYN
segments containing forged or spoofed IP source addresses with nonexistent or unreachable addresses, thereby forcing the
targeted network resources to respond with SYN/ACK segments to those addresses, then wait for responding ACK segments. As
the SYN/ACK segments travel to nonexistent or unreachable IP addresses, a response never occurs, thus leading to a
connection timeout. SYN floods also fill up the memory buffer of the targets, potentially disrupting the operating system. A SYN
flood is usually directed at one or more network resources resulting in a network DoS.
Network DoS: SYN FloodThe Defense

The Junos OS can prevent SYN floods by limiting the number of SYN segments per second permitted to pass through the Junos
security platform. You can set the attack threshold based on the destination address, source address, or both. This behavior
shields hosts on the protected network from incomplete three-way handshakes. The next two pages list the specifics of these
protection schemes.
SYN FloodsScreen Options
The inset illustrates the Junos Screen options that you can implement to handle SYN floods.
Note that the illustrated configuration only defines the Screen option. To activate the Screen options, you must apply it within a
You can set up the following threshold parameters for proxying uncompleted TCP connection requests:
Alarm threshold: This threshold is the number of proxied, half-complete TCP connection requests per second
before an alarm logs. This counter begins after the below attack threshold triggers.The default and configurable
range varies by device type.
Attack threshold: This threshold is the number of SYN segments per second required to trigger the SYN proxy
mechanism. Although you can set any threshold number within a specified range, we recommend that you
determine normal traffic patterns at your sites. The default and configurable range varies by device type.
Source threshold: This threshold is the number of SYN segments received per second from a single source IP
address, regardless of the destination IP address and port number. Once requests reach the threshold, further
connection attempts drop. The default and configurable range varies by device type.
Destination threshold: This threshold is the number of SYN segments received per second for a single destination
IP address and destination port pair. Once requests reach the threshold, further connection attempts to the
destination drop. The default and configurable range varies by device type.
Timeout: This parameter is the maximum length of time before a half-completed connection drops from the queue.
The default is 20 seconds, and the range is 150 seconds.
Although these threshold parameters are independent of each other, you can combine the Screen options in the configuration
for better protection against attacks.
SYN Cookie Advantages

As mentioned previously when we discussed SYN floods, SYN segments directed at network resources can render a network
segment unusable. The SYN cookie feature helps Junos security platforms ensure receipt of a valid SYN cookie response prior to
allowing processing of a new TCP connection flow, thereby avoiding the invoking of resource-intensive actions such as route and
session lookups. A SYN cookie is stateless, and as such it does not set up a session, which requires policy and route lookups.
This stateless nature is the prime advantage of using a SYN cookie over the traditional SYN proxying mechanism.
SYN Cookie Details

The SYN cookie was originally invented by D. J. Bernstein and Eric Shenk. Its purpose is to minimize the impact of spoofed SYN
flood attacks. The SYN cookie uses a cryptographic hash to generate a unique TCP initial sequence number (ISN) when it
receives a SYN segment. The hash uses a counter, local address, foreign address, and local and foreign ports to generate the
cookie. The Junos OS then sends a SYN/ACK segment back with this cookie as an ISN. After it receives the ACK segment back,
it cryptographically verifies whether it is a valid ACK segment based on the cookie.
SYN Cookie Handling
The graphic illustrates how a TCP connection establishes when a SYN cookie is active. Once the SYN cookie is enabled, the
Junos security platform becomes the TCP-negotiating proxy for the destination host. It replies to each incoming SYN segment
with a SYN/ACK segment containing an encrypted cookie as its ISN. If there is no response to the packet containing the cookie,
the software notes the attack as an active SYN attack, thereby stopping it.
However, if the initiating host responds with a TCP packet containing the cookie plus 1 in the TCP ACK field, the software
extracts the cookie, subtracts 1 from the value, and recomputes the cookie to validate that it is a legitimate ACK message.
If the cookie is legitimate, the software starts the TCP proxy process by setting up a session and sending a SYN to the
destination host with the source information from the original SYN message. When the Junos OS receives a SYN/ACK from the
destination host, it sends ACK messages to the destination and the originating hosts. Now the connection establishes and the
two hosts can communicate directly.
ICMP FloodThe Attack

An ICMP flood typically occurs when ICMP echo request messages overload the victim, causing resources to stop responding to
valid traffic.
ICMP FloodThe Defense

The Junos OS allows you to set up a threshold, which, once exceeded, invokes the ICMP flood attack protection feature. Once
requests exceed the threshold value (set in packets per second), the software ignores any further ICMP echo request messages
for the remainder of that second plus the next second. The default and configurable range varies by device type.
UDP FloodThe Attack

UDP flooding occurs when an attacker sends IP packets containing UDP datagrams with the purpose of slowing down the target
to such a degree that it cannot accept any valid connections.
UDP FloodThe Defense

Junos UDP flood protection enables you to set up the threshold value, which, once exceeded, invokes the UDP flood attack
protection feature. The default value and configurable range are in packets per second and vary by device type.
ICMP and UDP Flood HandlingScreen Options

The graphic illustrates an attacker trying to overload the target with an ICMP flood, a UDP flood, or both. The insets illustrate the
configuration syntax for ICMP and UDP flood protection. Note that the configuration shown only defines the Screen options. To
activate the Screen options, you must apply them within a security zone. We address this topic later in the chapter.
Network DoS: LAND AttackThe Attack

A LAND attack occurs when an attacker sends spoofed SYN packets containing the IP address of the target as both the
destination and the source IP address. A receiving system responds by sending the SYN-ACK packet to itself, creating an empty
connection that lasts until it reaches the session idle timeout. Flooding a system with such empty connections can overwhelm
one or more network resources resulting in a network DoS.
Network DoS: LAND AttackThe Defense

When you enable the Junos Screen option to block LAND attacks, the Junos OS combines elements of the SYN flood defense
and IP spoofing protection to detect software and block any malicious attempts of this nature.
LAND AttackScreen Option
The graphic illustrates the impact of the LAND attack on network resources.
Once you enable the LAND attack Screen option, the network is protected from the attack.
The graphic illustrates the configuration syntax for the LAND attack Screen option. Note that the illustrated configuration only
defines the Screen option. To activate the Screen option, you must apply it within a security zone. We address this topic later in
the chapter.
PC-Based Operating System DoS AttacksThe Attacks

The Ping of Death is an OS-targeted attack. It uses an oversized ICMP packet (larger than 65,507 bytes), which can trigger a
wide range of adverse OS reactions, including DoS, crashing, freezing, and rebooting.
Teardrop attacks exploit the reassembly of fragmented IP packets. One of the fields in the IP header is the fragment offset field,
which indicates the starting position of the data contained in a fragmented packet relative to the data of the original
unfragmented packet. When the sum of the offset and size of one fragmented packet differ from that of the next fragmented
packet, the packets overlap. A server attempting to reassemble such a packet can crash.
WinNuke is a DoS attack targeting any computer on the Internet running Windows. The attacker sends a TCP segment, usually to
NetBIOS port 139 with the urgent flag set, to a host with an established connection. This TCP segment introduces a NetBIOS
fragment overlap, which causes many machines running Windows to crash.
PC-Based Operating System DoS AttacksThe Defense

To handle the Ping of Death attack, the Junos Screen option detects oversized and irregular ICMP packets, even when the
attacker hides the total packet size by purposefully fragmenting it. To handle the Teardrop attack, the Junos Screen option
detects the discrepancy in a fragmented packet and drops it. To handle the WinNuke attack, the software detects the urgency
flag, unsets it, clears the pointer, and forwards the modified packet. It then logs the attempted WinNuke attack event.
PC-Based OS DoSScreen Options
The inset illustrates the syntax for configuring the Ping of Death, Teardrop, and WinNuke Screen options.
Note that the illustrated configuration only defines the Screen options. To activate the Screen options, you must apply them
within a security zone. We address this topic later in the chapter.
ICMP AbnormalitiesThe Attack

ICMP, when used properly, provides an excellent aid for error reporting and network probe capabilities. Typically, ICMP packets
have very short messages. Therefore, typically, ICMP packets do not fragment.
ICMP AbnormalitiesThe Defense

The Junos OS blocks any fragmented ICMP packet. In addition, the software drops ICMP packets with a length greater than
1024 bytes.
ICMP Abnormalities DetectionScreen Option
The graphic illustrates an IP packet header, highlighting the protocol field, which is equal to 1 for ICMP, the total packet length
field, the fragment offset field, and the M (more fragments) field. Once you set the ICMP abnormalities detection Screen option,
the Junos OS blocks any ICMP packets that have the M flag set or have an offset value indicated in the fragment offset field.
Furthermore, the Screen option can include blocking unusually large ICMP packets (> 1024 bytes). To set up this Screen option,
you must perform the configuration shown in the inset.
Note that this configuration defines only the Screen option. To activate the Screen option, you must apply it within a security
zone. We address this topic later in the chapter.
IP Packet FragmentsThe Attack

As packets traverse different networks, it is sometimes necessary to fragment them based on the maximum transmission unit
(MTU) for each network. IP fragments might contain an attackers attempt to exploit the vulnerabilities in the packet reassembly
code of specific IP stack implementations. When the victim receives these packets, the results can range from processing
packets incorrectly to crashing the entire system.
Bad IP OptionsThe Attack

Some attackers can abuse the IP option fields, the original intent of which was (and still is) to provide special routing controls,
diagnostic tools, and security. By misconfiguring these options, attackers produce either incomplete or malformed fields within
a packet. Attackers can use these malformed packets to compromise hosts on the network.
IP Packet Fragments and Bad IP OptionsThe Defense

Once you define the corresponding Screen option, the Junos OS detects and drops all IP packet fragments or packets with
incorrectly formatted IP options that it receives at the interfaces bound to the Screen options protected zone.
IP Packet Fragments and Bad IP Options DetectionScreen Option
The graphic illustrates an IP packet header and highlights the more fragment (M), fragment offset and IP options fields. Using
the block-frag Screen option, the Junos OS checks whether the M field is set or if a nonzero value is in the fragment offset
field. If it finds any of these values set, it begins blocking fragmented IP packets.
Attackers can configure the IP options field incorrectly, resulting in incomplete or malformed fields. To set up the bad IP options
Screen option, you must perform the configuration shown in the inset.
Note that this configuration only defines the Screen option. To activate the Screen option, you must apply it within a security
Unknown ProtocolsThe Attack

IPv4 protocol field values of 137 or greater are currently unassigned and should be used only for nonstandard or experimental
protocols. Unless your network uses a nonstandard or experimental protocol, you should block packets containing an IPv4
protocol field value of 137 or greater.
Unknown ProtocolsThe Defense

Once you define the corresponding Screen option, the Junos OS detects and drops any packet that uses an unknown protocol.
Unknown ProtocolsScreen Option
The graphic illustrates an IP packet header and highlights the protocol field containing the protocol number. To set up the
unknown protocols detection Screen option, you must perform the configuration shown in the inset.
SYN FragmentsThe Attack

IP encapsulates a TCP SYN segment into an IP packet that initiates a TCP connection. Because the purpose of this packet is to
initiate a connection and invoke a SYN/ACK segment in response, the SYN segment typically does not contain any data.
Furthermore, because the IP packet is small, no legitimate reason exists for it to fragment. A fragmented SYN packet is
anomalous, and as such, it is suspect. When a victim receives these packets, the results can range from processing packets
incorrectly to crashing the entire system.
SYN FragmentsThe Defense

Once you define the corresponding Screen option, the Junos OS detects and drops all received SYN fragments.
SYN FragmentsScreen Option
The grpahic illustrates IP and TCP headers and highlights the M and fragment offset fields, which are part of the IP header, and
the SYN flag, which is part of the TCP header. Using the syn-frag Screen option, the Junos OS checks SYN segments to see
whether the M field is set or if a nonzero value is in the fragment offset field. If it finds SYN fragments, it begins blocking the SYN
fragment packets.
To set up the SYN fragment Screen option, you must perform the configuration shown in the inset.
Syntax for Screen Options Commands
The inset illustrates the Junos OS syntax that you must use when configuring Screen options.
First you must define the Screen options. Then you must apply these options to the desired zone. Recall that the Junos OS
applies Screen options at the ingress zone of the Junos security platform prior to applying any security policy or route lookup.
Case Study: Protecting the Private Zone
Consider the example illustrated on the graphic. Two zones exist in this network: private and public. The objective is to use
Screen options to protect the private zone from ICMP abnormalities, ICMP floods, and session table floods.
Case Study: Step 1Creating the Screen Option

The inset illustrates the creation of a Screen option named Protector,
which lists the necessary options needed to meet the objective from the
previous inset. The following list describes the behavior of each Screen
option:
icmp fragment: Blocks any ICMP packets that have the More
Fragments flag set or that have an offset value indicated in
the offset field.
icmp large: Blocks any ICMP packets with a length greater

than 1024 bytes.
icmp flood threshold: Ignores any ICMP packets received

above the configured threshold. This protection remains in
effect for the duration of the second when the threshold is
reached, as well as the following second.
source-ip-based session limit: Limits the number of sessions

from one source IP address to the specified number.
Note that by enabling Screen protection from large ICMP packets combined
with ICMP fragmented packets, you are also automatically enabling
protection from the ping of death attack.
Case Study: Step 2Applying the Screen Option
The inset illustrates the application of the Screen option to the public zone.
Attack Monitoring: Part 1
You can monitor Screen statistics using the show security screen statistics zone zone-name command. You
can tell which values are incrementing by issuing the command multiple times.
The inset shows the result of the show security screen ids-option screen-name command, which displays the
Protector Screen option content. Note the correspondence between the actual configuration of the Protector Screen
option and the monitoring show security screen ids-option screen-name command.
The inset illustrates an example traceoptions configuration for monitoring Screen options operations. After committing the
configuration, you can view the resulting trace file using the show log filename command.
Review Questions
Answers
1.
The purpose of Screen options in the Junos OS is to offer better network protection to the networks behind the Junos security platform,
and to the device itself, from malicious information or attacks.
2.
The available Screen options include IP address sweep detection, port scanning detection, network investigation triggering, operating
system probe blocking, abnormal SYN and FIN flags setting detection, IP spoofing detection, bad IP source route options detection,
ICMP abnormalities detection, and DoS attack detection.
3.
Beyond offering network and host protection against malicious attacks, the main advantage of using Screen options is that the Junos OS
performs Screen checks prior to security policy processing, which results in fewer resources used for malicious packet processing.
4.
There are two main goals for a DoS attack: immobilizing hosts and immobilizing networks.
5.
Apply Screen options under the security zones configuration stanza.
Chapter 6: Network Address Translation

The purpose and functionality of Network Address Translation (NAT) and Port Address Translation (PAT);
NAT processing;
Configuration of source NAT
Configuration of destination NAT;
Configuration of static NAT; and
Monitoring and verifying NAT operation.
Network Address Translation
Historically, the NAT concept was born because of the shortage of public IPv4 addresses. Many organizations moved to deploy
so-called private addresses using the IPv4 private addressing space, as identified in RFC 1918. These addresses include the
following ranges:
10.0.0.010.255.255.255 (10.0.0.0/8 prefix);
172.16.0.0172.31.255.255 (172.16.0.0/12 prefix); and
192.168.0.0192.168.255.255 (192.168.0.0/16 prefix).
Because private addresses are not routable within the public domain, edge network devices can deploy the NAT feature to
replace private, nonroutable addresses with public addresses prior to sending traffic to the public network and vice versa.
Translation consists of replacing the IP address (NAT), port numbers (PAT), or both, depending on the configuration.
Network Address Translation Chapter 61

While primarily deployed to translate private addresses to public addresses, NAT can translate from any address to any other
address, including public to public and private to private addresses.
You can use PAT in conjunction with NAT. Specifically, PATs invaluable benefit is that several hosts can use a single public
address. In this situation, PAT enables a unique host and application match during the NAT process.
Review: Packet Flow
A security platform running the Junos operating system implements NAT and PAT into both first path and fast path flows
processing. The graphic reviews the NAT process position within the overall packet flow. Note that destination NAT and source
NAT occur separately in the first path packet flow.
In the first path, NAT is distributed depending on the kind of translation to be done to accommodate the different use cases
relevant to each NAT type. For instance, destination and static NAT are processed before route lookup and security policy
processing, which eliminates the need to install fictitious routes in the routing table.
NAT and PAT Processing
During first packet processing, a combination of destination and source IP address information and port translation information
set up occurs. In first packet processing, destination NAT processing occurs before security policy and route lookups while
source NAT processing occurs after security policy and route lookups. Based on the first packet of a session, the Junos OS
installs NAT and PAT information into the session table for fast path processing. This information speeds up subsequent packet
processing.
The design is such that firewall administrators only need to be concerned with the actual endpoints involved in the
communication.
Chapter 62 Network Address Translation
Three Basic Types of NAT
Three basic types of NAT existsource NAT, destination NAT, and static NAT. Destination NAT translates the destination IP
address of a packet. Source NAT translates the source IP address of a packet. Static NAT allows connections to be originated
from either side of the network, but is limited in that only one-to-one translations are possible. Both destination and source NAT
can deploy either static or dynamic address mapping.
Combination of Destination and Source NAT and PAT

Destination and source NAT and PAT can co-exist within the same platform. You can deploy both source and destination NAT and
PAT simultaneously, applying each within its own flow direction.
Dynamic Versus Static Address Translation and Port Translation

Dynamic address translation implies that the association between the original address and port and the translated address and
port is not fixed. On the other hand, static address translation implies that the association between the original address and
port and the translated address and port is fixed and has a one-to-one mapping. We address this topic in more detail later in the
chapter.
Source IP Address and Port Translation
Source IP address and port translation imply that the SRX Series device translates the source IP address to a different
IP address, the port number to a different port number, or both.
Three Options for Source NAT and PAT

The Junos OS supports three methods to perform source NAT and PAT:
Interface-based source NAT, which is the translation of the original source IP address to the egress interfaces
address always employing PAT;
Standard pool-based NAT, which is a dynamic mapping of the original source address to an address from a
user-defined pool with or without PAT; and
Source NAT with address shifting, which is a one-to-one mapping of the original source address to a user-defined
pool performed by shifting the IP addresses without PAT.
Matching Conditions
Traffic requiring source NAT application is subject to a two-layer matching scheme. Similar to security policy, the Junos OS
creates source NAT rules under a context indicating traffic direction. The directional context is the first layer of matching. NAT
rules are organized in rule-sets. For source NAT, each rule-set contains this context by requiring a from clause and a to clause.
The from and to clauses indicate an interface, zone, or routing-instance. If rule-sets overlap by targeting the same traffic, the

rule-set with the most specific context takes precedence. Interfaces are the most specific context, while routing-instances are
the least specific.
The second layer of matching is performed within NAT rules using a match option. These options include source-address
and destination-address. This information is evaluated using packet headers.
NAT Rule Actions

Traffic that matches a directional context and NAT rule-matching conditions is subject to a NAT action. Source NAT actions are
specified using a then clause and include off, pool (followed by a user-defined pool name), and interface (followed by a
user-defined interface name including the logical unit).
Overlap
Static source NAT (reverse mapping of static destination NAT) rules take precedence over dynamic source NAT rules.
Note the following general guidelines regarding addresses, rule-sets, or rules that overlap:
Addresses used for NAT pools, whether it be source NAT pools or destination NAT pools, should never overlap;
If more than one rule-set matches traffic, the rule-set with the most specific context takes precedence; and
Within a rule-set, the ordering of rules is significant. Rules evaluation occurs sequentially. In other words, if traffic
matches two rules within the same rule-set, the first rule listed in the configuration is the only rule applied.
Use the Junos insert command to adjust rules within a rule-set.
Live Configuration Changes

If a change is made to a NAT rule or pool that is currently in use, the Junos OS tears down the session once the change is
committed. The Junos OS re-initiates the session as soon as it receives further matching traffic.
Interface-Based Source NAT Sample Topology
The graphic illustrates a sample topology that demonstrates interface-based source NAT using the Junos OS. Using the topology
shown in the graphic, we will enable interface-based source NAT for traffic sourced from the network attached to the ge-0/0/2.0
interface with a destination belonging to the Untrust zone. The traffic should be translated to use the egress interface address
1.1.70.5.
Interface-Based Source NAT Configuration
The inset illustrates the required configuration to enable interface-based source NAT for the given example. Pools are not
necessary for this configuration. Interface-based NAT requires a rule-set to associate with a directional context. In this example,
traffic from the network attached to the ge-0/0/2.0 interface that has a source address belonging to the 0.0.0.0/0 prefix
translates to a source address of the egress interface.
Verifying the Result
Use the show security flow session command to observe NAT translation. The output shows traffic entering the device
using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. The return traffic from this flow travels to the
translated public address 1.1.70.5.
The show security nat source summary command provides a quick look at the rule-set, rule, context, and rule action
resulting from this configuration.
Pool-Based Source NAT Sample Topology With PAT
The graphic illustrates an example topology that demonstrates pool-based source NAT and PAT using the Junos OS. Using the
topology shown in the graphic, you will enable pool-based source NAT with PAT for traffic destined to the Untrust zone and
sourced from the Trust zone. Only traffic belonging to the 10.1.10/24 network should be translated. The traffic should be
translated to a public source IP address of 207.17.137.229.
Pool-Based Source NAT Configuration With PAT
The inset illustrates the required configuration to enable source NAT and PAT for the given example. Junos pool-based NAT
requires a user-defined address pool and a rule-set that associates with a directional context. In this example, traffic from the
Trust zone destined to the Untrust zone and with a source address belonging to the prefix 10.1.10/24 translates to a source
address of 207.17.137.229. In the Junos OS, PAT is automatically enabled for pool-based source NAT.
using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. Source address translation occurs and the
return traffic is sent to the public address 207.17.137.229.
The show security nat source summary command provides a quick way to look at existing source NAT rules and pools.
In this case, the source NAT pool contains a single address, and PAT is enabled by default. The source NAT rule illustrates the
parameters set by the configuration with an associated action of translation using Pool A.
PAT Is Default
As illustrated in the previous example, the Junos OSs implementation of source NAT
enables PAT by default. Because PAT is enabled and the number of available ports is
near 64,000, it is rare that a source NAT pool will exhaust.
Address Persistence
Regardless of the large available source NAT pool, there is no guarantee that the
Junos OS will use the same source IP address for different traffic types associated
with the same source host. To ensure the use of the same address, configure the address-persistent global source NAT
option as shown in the inset.
Pool-Based Source NAT Sample Topology Without PAT
The graphic illustrates a sample topology that demonstrates pool-based source NAT without PAT using the Junos OS. Using the
topology shown in the graphic, we will enable pool-based source NAT without PAT for traffic destined to the Untrust zone and
sourced from the Trust zone. Only traffic belonging to the 10.1.10/24 network should be translated. The traffic should be
translated to a public source IP address range consisting of the 207.17.137/24 network.

Disabling PAT dramatically reduces the number of addresses available in a source pool. Recall that previously, using PAT,
approximately 64,000 variations were available per address. Without PAT, each address in the source pool must use its original
source port, which can lead to higher pool utilization. To combat this problem, we will enable a backup method to use the egress
interface address if a pool is exhausted of addresses. We refer to this backup method as an overflow pool. An overflow pool can
use the egress interface (as in this example) or a separate user-defined pool. In either case, the overflow pool must have PAT
enabled, which is the mandated default for interface-based NAT.
Pool-Based Source NAT Configuration Without PAT
The inset illustrates the required configuration to enable source NAT without PAT for the given example. Junos pool-based NAT
Trust zone destined to the Untrust zone and with a source address belonging to the 10.1.10/24 prefix translates to a source
address belonging to the 207.17.137/24 prefix. PAT is explicitly disabled and an overflow pool is defined using the egress
interface address, in case pool A becomes exhausted of all available addresses. Recall that interface-based source NAT uses
PAT by default.
using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. Source address translation is performed, and
the return traffic is destined to the public address 207.17.137.127.
The show security nat source summary command provides a quick way to look at existing source NAT rules and pools.
In this case, the source NAT pool contains the 207.17.137.1 through 207.17.137.254 address range and PAT is disabled. The
source NAT rule illustrates the parameters set by the configuration with an associated action of translation using pool A.
Pool Utilization
If the Junos OS runs out of addresses in a source NAT pool, further packets requiring translation will drop. We already discussed
one method to overcome this problemusing an overflow pool. While an overflow pool is a handy tool, you likely also want to
know that this situation has occurred so that you can take measures to increase the pool size or evaluate the usage patterns.
The Junos OS provides a pool utilization alarm for monitoring pool usage. The utilization alarm is disabled by default. The inset
shows the configuration for the pool utilization alarm, which is global to the source NAT stanza. The values represent a
percentage of pool utilization. Once pool utilization reaches the raise-threshold (in this case, 50%), the Junos security platform
sends an SNMP trap notification to a configured network management station. If traffic falls below the clear-threshold, the
Junos OS sends an SNMP trap to the network management station. Note that while the pool utilization alarm is disabled by
default, if configured, the default setting for the clear-threshold is 80 percent of the raise-threshold.
Source NAT with Address Shifting Sample Topology
The graphic illustrates a sample topology that demonstrates source NAT with address shifting using the Junos OS. Using the
topology shown in the graphic, we will enable source NAT with address shifting for traffic destined to the Untrust Zone and
sourced from the Trust Zone. Only traffic belonging to the 10.1.10/24 network should be translated starting with the 10.1.10.5
address for shifting purposes. The traffic should be translated to a public source IP address range consisting of the 207.17.137/
24 network.
By definition, this type of translation is one-to-one, static, and without PAT. If the original source address range is larger than the
address range in the user-defined pool, packets might drop. Use the previously discussed tools to assist in this situation.
Source NAT with Address Shifting Configuration
The inset illustrates the required configuration to enable source NAT with address shifting for the given example. Junos source
NAT with address shifting requires a user-defined address pool and a rule-set that associates with a directional context. In this
example, traffic from the Trust Zone destined to the Untrust Zone and with a source address belonging to the 10.1.10/24 prefix
translates to a source address belonging to the 207.17.137/24 prefix. The 10.1.10.5 address is configured as the
host-address-base and serves as a starting point for address shifting.
using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. Source address translation is performed, and
the return traffic travels to the public address 207.17.137.1.
The show security nat source pool all command illustrates the pool of translated addresses. In the example, the
full range of the pool is listed and the output shows that 254 total addresses are available. The 10.1.10.5 address shows as the
base starting address for address shifting. The output also illustrates that PAT is disabled for this type of address translation.
You can view this output for an individual address pool by specifying the pool name instead of using the all option.
Check Your Knowledge
The off NAT action is useful for detailed control. The configuration shown in the inset represents how you might use a NAT off
action. In this example, all traffic sourced from the 10.1.10.0/24 network, with the exception of traffic destined to the
172.18.20.0/24 has source NAT applied to it. Recall that the ordering of rules within a rule-set is significant. In the example,
traffic matching the directional context (from the trust zone to the external zone) is first evaluated by rule 1 and then
evaluated by rule 2.
Destination IP Address and Port Translation
Destination IP address and port translation imply that the device translates the destination IP address to a different IP address,
the destination port number to a different port number, or both.
Options for Destination NAT and PAT

The Junos OS uses standard pool-based NAT to perform destination NAT and PAT. This is a one-to-one mapping using address
pools. PAT can also be implemented when using standard pool-based NAT.
VoIP ALGs
Voice over IP (VoIP) application-level gateways (ALGs) dynamically generate the allow-incoming table for packets from the
public network into the private network. The table contains the list of dynamically generated addresses for voice traffic.
Matching Conditions
Traffic that requires destination NAT is subject to a two-layer matching scheme. Similar to security policy, NAT rule creation
occurs under a context indicating traffic direction. The directional context is the first layer of matching. NAT rules are organized

in rule-sets. Each rule-set contains this context by requiring a from clause. The from clause can indicate an interface, zone, or
routing-instance. If rule-sets overlap by targeting the same traffic, the rule-set with the most specific context takes precedence.
Interfaces are the most specific context, while routing-instances are the least specific.
The second layer of matching occurs within NAT rules using a match option. These options include source-address,
destination-address, and destination-port number. An exception to this second layer of matching is static
destination NAT, which supports only the destination-address match option. This information is evaluated using packet
headers.
NAT Rule Actions

Traffic that matches a directional context and NAT rule-matching condition is subject to a NAT action. NAT actions are specified
using a then clause and include off, pool (followed by a user-defined pool name), and static-nat prefix (followed by
a user-defined address prefix). A destination NAT pool can contain a maximum of one address or address-range and one port.
Overlap
Static NAT rules take precedence over dynamic destination NAT rules.
Note the following general guidelines regarding addresses, rule-sets, or rules that overlap:
Addresses used for NAT pools, whether it be source NAT pools or destination NAT pools, should never overlap;
If more than one rule-set matches traffic, the rule-set with the most specific context takes precedence; and
Within a rule-set, the ordering of rules is significant. Rules evaluation occurs sequentially. In other words, if traffic
matches two rules within the same rule-set, the first rule listed in the configuration is the only rule applied.
Use the Junos insert command to adjust rules within a rule-set.
Live Configuration Changes

If a change is made to a NAT rule or pool that is currently in use, the Junos OS tears down the affected session once the change
is committed. The Junos OS re-initiates the session as soon as it receives further matching traffic.
Pool-Based Destination NAT Sample Topology
The graphic illustrates a sample topology that demonstrates pool-based destination NAT using the Junos OS. Using the topology
shown in the graphic, we will enable pool-based destination NAT for traffic destined to 100.0.0.1 coming from the Untrust Zone.
The traffic should be translated to a private IP address of 10.1.10.5.
Pool-Based Destination NAT Configuration with a Single Address
The inset illustrates the required configuration to enable destination NAT for the given example. Junos pool-based NAT requires
a user-defined address pool and a rule-set that associates with a directional context. In this example, traffic from the Untrust
zone with a destination address of 100.0.0.1 translates to a destination address of 10.1.10.5. This example includes a pool with
only one available address and no port translation.
Pool-Based Destination NAT Configuration with an Address Pool
The inset illustrates the required configuration to enable destination NAT for the given example. The Junos OS pool-based NAT
Untrust zone with a destination address of 100.0.0.1 translates to a destination address within a range of 10.1.10.5 to
10.1.10.6. There is no port translation.
Pool-Based Destination NAT Configuration with PAT
The inset illustrates the required configuration to enable destination NAT and PAT for the given example. Junos OS pool-based
NAT requires a user-defined address pool and a rule-set that associates with a directional context. In this example, traffic from
the Untrust zone with a destination address of 100.0.0.1 and a destination port of 80 translates to a destination address of
10.1.10.5 and a destination port of 8080.
Result of NAT With PAT
using the public destination address 100.0.0.1 and destination port of 80 from a public host at 1.1.70.6. The return traffic from
this flow originates with the private address 10.1.10.5 and private port 8080.
The show security nat destination pool all command illustrates the pool of translated addressesin this case a
single addressand the translated port number. You can also view this output for an individual address pool by specifying the
pool name instead of using the all option.
Use the show security nat destination rule all operational mode command to view NAT rules as the Junos OS
programs them. The output in the inset illustrates the rule. You can verify traffic translation by this rule by the translation hits
counter.
You can also view this output for an individual NAT rule by specifying the rule name instead of using the all option.
Static NAT Sample Topology
The graphic illustrates a sample topology that demonstrates static NAT using the Junos OS. Using the topology shown in the
graphic, we discuss enabling static NAT for traffic destined to 100.0.0.1 coming from the Untrust zone. The traffic should be
translated to a private IP address of 10.1.10.5.
Static Destination NAT Configuration
The inset illustrates the required configuration to enable static NAT for the given example. Junos static NAT requires a rule-set
association with a directional context. In this example, traffic from the Untrust Zone with a destination address of 100.0.0.1
translates to a destination address of 10.1.10.5
Use the show security flow session command to observe NAT translation. The output shows traffic entering the Junos
security platform using the public address 100.0.0.1 from a public host at 1.1.70.6. The return traffic from this flow originates
with the private address 10.1.10.5.
Static Source NAT
The inset illustrates the creation of a second session. Once static NAT is enabled and a session triggers, the Junos OS
automatically creates a reverse static source NAT session. Neither the destination static NAT session, nor the source static NAT
session creation occurs until traffic that matches the NAT rule actually traverses the device.
Dropping Non-NAT Traffic
Because NAT processing has been separated from security policies, both translated and untranslated addresses might match
policies. In this network, the Junos device performs destination NAT to allow Internet connections to Host A. Traffic sent to the
public address of the server and to the private address of the server seem the same to the policy engine. To overcome this
challenge, whenever destination NAT or static NAT is used, the policy engine is informed that traffic has been translated, which
allows policies to explicitly drop translated or untranslated traffic as shown in the example in the inset.
When to Use Proxy ARP
The Junos OS for security platforms requires a proxy Address Resolution Protocol (ARP) configuration whenever translated traffic
belongs to the same subnet as the ingress interface. This task is not automatic and you must configure it as needed.
When a network device needs to send a packet to a destination IP address using Ethernet, the device sends an ARP request to
obtain the Layer 2 MAC address associated with the destination IP address. Once that association is in place, the sending
device typically stores this information in memory and subsequently addresses Ethernet frames to the appropriate Layer 2 MAC
address. Without proxy ARP, if an interface receives an ARP request for an address other than its own, it ignores the packet. It
assumes the packet is meant for another device attached to the same broadcast media. Using proxy ARP, the interface acts as

a proxy for the destination by replying to ARP requests on behalf of the intended destination. Packets destined for the intended
destination then travel to the proxying device, which can then forward the packets to the actual destination.
The inset illustrates the configuration hierarchy and options for NAT proxy ARP.
Proxy ARP Example
The graphic illustrates a sample situation requiring proxy ARP and the associated configuration. In the example, the device
performs source translation for traffic from the Trust Zone, translating the private source address to a public source address in
the 1.1.70.10 to 1.1.70.100 address range. The NAT source pool belongs to the same subnet as the public interface. For return
traffic to successfully reach the 10.1.10.5 host, the device must perform proxy ARP for the 1.1.70.101.1.70.100 address
range.
Key Monitoring Commands
The inset lists four operational mode show commands used to verify and monitor NAT operation. We repeatedly illustrate these
commands throughout examples in this chapter. You can use the show security nat commands for source or destination
NAT.
Traceoptions for NAT Operation
Traceoptions are available for a more detailed view of NAT operation. The traceoptions log is stored as /var/log/security-trace by
default, or optionally, the user can define a different log name.
NAT internal operation consists of two main componentsthe Packet Forwarding Engine (PFE) and the Routing Engine (RE). The
PFE is divided into two elementsthe ukernel element and the real-time element. Traceoptions flags can be set to trace NAT
operation within the PFE ukernel, the PFE real-time element, or within the RE. The output that follows lists all the available flags
for tracing NAT operation.
[edit security nat traceoptions]
user@srx# set flag ?
Trace everything
all
destination-nat-pfe Trace destination nat events on PFE-ukernel side
destination-nat-re
Trace destination nat events on RE side
destination-nat-rt
Trace destination nat events on PFE-RT side
source-nat-pfe
Trace source nat events on PFE-ukernel side
source-nat-re
Trace source nat events on RE side
source-nat-rt
Trace source nat events on PFE-RT side
static-nat-pfe
Trace static nat events on PFE-ukernel side
static-nat-re
Trace static nat events on RE side
static-nat-rt
Trace static nat events on PFE-RT side
Review Questions
Answers
1.
Destination NAT processing occurs before security policy processing and source NAT processing occurs after security policy processing.
2.
Static source NAT is supported in one of two waysusing source NAT with address shifting or the automatic creation of a return session
when using static destination NAT.
3.
The NAT off action is for detailed control within NAT rule-sets.

4.
A NAT proxy ARP configuration is necessary when the translated address belongs to the same subnet as the ingress interface.
5.
The commands used to monitor NAT operations are show security flow session, show security nat source
summary (or show security nat destination summary), show security nat source pool (or show
security nat destination pool), and show security nat source rule (or show security nat
destination rule).
Chapter 7: IPsec VPNs

Various types of virtual private networks (VPNs);
Major security concerns;
IP Security (IPsec) VPNs and their functionality;
IPsec VPN configuration using policy-based and route-based methods; and
IPsec VPN monitoring.
The Meaning Behind VPNs

VPNs are used to transport private network traffic over a public network infrastructure. The term VPN has been used broadly in
the networking industry for decades. For instance, the networking industry has referred to X.25, Frame Relay, and ATM
infrastructures as VPN networks. As the Internet spread and as carriers and service providers migrated all their service
offerings to IP, new forms of VPNs emerged.
Types of VPNs Today

We can subdivide these new forms of VPNs into three categories:
Clear-text VPNs: These VPNs include Layer 3 VPNs, Layer 2 VPNs (Kompella and Martini implementations), and
virtual private LAN service (VPLS). These VPNs rely on MPLS services and the use of signaling protocols over IP.
Secure VPNs: These VPNs are IPsec VPNs, carrying payload over IP securely. We will discuss these VPN types in
this chapter.
Combination of clear-text and secure VPNs: These VPNs are based on Layer 3 VPNs, built on MPLS technology,
and compounded with IPsec security.
IPsec VPNs Chapter 71
Secure VPNs
A network device that builds secure VPNs must be able to perform the following actions:
Encrypt the original packet so that it cannot be easily decoded should it be intercepted on the public network;
Verify the original payload ensuring data integrity; and
Authenticate the originating device as a member of the VPN, rather than a random device operating on the public
network.
This chapter focuses on end-to-end static IPsec VPNs. However, note that security platforms running the Junos operating system
also support end-to-site dynamic VPNs and VPN establishment using the NetScreen Remote VPN client. See the Juniper
Networks technical documentation at http://www.juniper.net/techpubs for further information on these features.
Security Concerns
Three driving concerns exist for network security: confidentiality, integrity, and authentication.
Confidentiality: Online banking, credit card information, or a companys competitive informationhow do we keep
this information secure from the man in the middle? We want information stored in such a way that if someone
were to capture this datagram, the information would appear meaningless.
Integrity: Even though the information might be secure and hidden, meaning that someone might not be able to
determine or understand its contents, it could still be possible for someone to change it. Someone could tweak bits
to change the data from what was originally sent through the network. So how do we ensure that if the data is
compromised, the remote station recognizes this fact and refuses to process the information?
Authentication: How does the remote station verify that the information came from the device from which it
expected it to come? You do not want to be communicating and sending critical information to the wrong recipient!
ConfidentialityData Encryption
The first of the three VPN security concerns is confidentiality.
Encryption provides data confidentiality. Encryption is the method of taking user datareferred to as plaintextand converting it
into unreadable or secret data named ciphertext. An encryption algorithm and keys (strings of bits that seed the encryption
process) are applied to the data, resulting in ciphertext.
Chapter 72 IPsec VPNs

To reverse the process and decrypt the ciphertext, you must know both the encryption algorithm and encryption key. You can
decrypt encrypted data in one of two ways:
Symmetric key encryption: This method uses the same key for both encryption and decryption; and
Asymmetric key encryption: This method uses a private key for encryption and a mathematically related public key
for decryption.
The cipher strength depends on the key size; the larger the key, the more secure the cipher output. The trade-off is in processing
timelarger keys use more computational cycles to encrypt and decrypt.
ConfidentialitySymmetric Key Encryption
Symmetric key encryption is the most straightforward form of encryption with the least amount of overhead. We refer to it as
symmetric because the key used to encrypt the data is the same key used to decrypt the data. Thus, the same key must be
known on both sides of a connection.
Symmetric key sizes range from 40 bits1024 bits. These keys are considered to be very fast because they are not very long,
and they are widely used for bulk data encryption. However, because the key must be known to both the sender and the
receiver, key management is a problem when using symmetric keys.
Examples of symmetric key encryption include Rivest Cipher 4 (RC4), Data Encryption Standard (DES), Advanced Encryption
Standard (AES), and Blowfish.
Public Key Encryption
The public, asymmetric key encryption method requires a pair of mathematically related keys. One of the keys is kept secret and
known only to the owner; this key is the private key. The owner distributes the other key widely and anyone can access it; this key
is the public key. You can only decrypt data encrypted by the private key by using the corresponding public key, and vice versa.
The keys are mathematically related such that it is almost impossible to derive one key out of another.

Public key sizes range from 512 to 2048 bits. Because of the large size, these keys are extremely slow and generally not
feasible for bulk data encryption. However, public keys are widely used for user and device authentication (for example, digital
certificates). An example of public, asymmetric key encryption is RSA.
Integrity
Now that we have the data encrypted as it traverses the Internet, we must ensure that the data is not subject to modification
along the way. Even though a novice hacker might not be able to crack the encryption algorithm and key, the hacker can still
wreak havoc by modifying bits that the encrypted payload carries. If this modification happens, the decrypted output does not
match the original data. Who knows what the consequences might be!
Hashing solves this problem by creating a fingerprint of the data, similar to a cyclic redundancy check (CRC) checksum. Before
data travels, it traverses a hashing engine that produces a fixed-length hash output. It places the hash in a field in the packet
along with the data before it travels over the network. The destination device takes the same data and runs it through the same
hashing algorithm, calculating its own hash. The destination device then compares the hash that it calculated against the hash
carried in the packet. The same hash in both locations proves data integrity in transit. If the hashes do not match, the packet
drops.
The Junos OS supports MD5, SHA1, and 256-bit SHA2 hashing.
One-Way Hash Algorithms
A hash function must have two basics properties:
You should not be able to calculate the original data from the hashed output. This property ensures that you cannot
derive the plaintext from the ciphertext.
It must be mostly collision resistant. A collision occurs when two different inputs give the same output. It must not
be possible to predict a different input value that gives the same output. This property is necessary because the
purpose of hashing is to verify that the data has not changed.
To see how it is possible to create a one-way function, think of the example in the inset, which shows a modulus operation. Given
the value of 3, it is not possible to determine the original value because an infinite range of possible answers exists.
However, this example is not suitable as a real-world hash function because it does not satisfy the collision-resistant
requirementa malicious person can change the plaintext by any multiple of the modulus number and know that the hashed
value remains the same.
The most secure and widely used hash function is the Secure Hash Algorithm 1 (SHA-1). SHA-1 is preferred over Message Digest
5 (MD5), although MD5 is still widely supported. These functions produce a fixed-length output that is useful when working with
IP packets because the overhead of transmitting the hash value is predictable.
IntegrityThe Hash Process
The following list outlines the hash process:

1.
The sender runs the data through the hash process.
2.
The sender appends the hash value to the data and sends both the data and the hash value to the receiver.
3.
The receiver separates the data and the hash value.
4.
The receiver hashes the data.
5.
The receiver then compares the calculated hash value to the received hash value. If the hash values match, the
data is unaltered.
Source Authentication
Encryption protects the packet contents from being viewed on the public network. Hashing verifies that the data is unaltered.
But how do you validate the source of the data?
The software performs source authentication using the Hashed Message Authentication Code (HMAC). The sender appends a
secret preshared key to the data, then performs the hash function. For hashes to successfully match, the receiver must append
the same key value to the data before performing the hash function. The key itself never transmits along with the data.
HMAC Authentication
The following list outlines hashing with HMAC:

1.
The sender appends the preshared key to the data, then performs the hash function.
2.
The data and hash value travel to the receiver.
3.
The receiver separates the data and the hash value.
4.
The receiver appends the preshared key to the data, then performs the hash function.
5.
The receiver then compares the calculated hash value to the received hash value. If the hash values match, the
data is unaltered. If the hash values do not match, either the data itself is corrupt, or the keys did not match,
meaning the source is invalid. Either way, the receiver discards the packet.
Key Exchange
As we already discussed, both encryption and authentication are dependent on security keys, which leads to the problem of key
exchange. If keys must be the same on both sides of a connection, how can you securely exchange key information?
One option is to manually configure the keys on both sides of the connection. Manual key configuration is straightforward, but
misconfigurations, especially when each device has a different administrator, are common. Furthermore, manual configuration
usually means that keys rarely change, which is itself a potential security issue; given a large enough sample, any code can be
broken.
Automating the key exchange process is a good idea, but we must overcome the problem of sending keys across a public
network. Anyone intercepting the key has the ability to decode the data.
The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The Diffie-Hellman algorithm is a method
whereby two parties can agree upon a secret key known only to them. The strength of the technique is that it allows the
participants to create the secret value over an unsecured medium without exchanging the secret value itself. This method also
makes it impossible to perform reverse generation of the secret if it is somehow intercepted.
Diffie-Hellman Groups
Diffie and Hellman proposed five groups of prime numbers and generator values to use in their key exchange algorithm. Each
group generates unique keys using a combination of exponential and modulus calculations.

The Junos OS supports Diffie-Hellman (DH) Groups 1, 2, and 5. The larger the prime numberthe stronger the keyand the
more computationally intensive the calculation. Diffie-Hellman Group 1 uses a 768-bit prime number. Diffie-Hellman Group 2
uses a 1024-bit prime number. Diffie-Hellman Group 5 uses a 1536-bit prime number.
You must configure both tunnel peers to use the same DH group; otherwise, the key generation process fails.
The DH Key Exchange Process
Using the same DH group, each Junos security platform creates unique public and private keys. These keys are mathematically
related by means of the DH algorithm.
The public key values exchange across the network. Each peer then runs its local private key and the received public key value
through the DH algorithm to compute a common session key. The session key itself never passes across the network.
IPsec Overview
IPsec is a set of standards that defines how the encryption, validation, and authentication methods we just discussed are
actually implemented in networks. IPsec works at Layer 3; it supports both unicast and multicast traffic.
IPsec: A Two-Step Process

IPsec VPNs consists of two major steps:
1.
IPsec tunnel establishment: You can manually establish an IPsec tunnel or the Internet Key Exchange (IKE) protocol
can do it dynamically.
2.
IP traffic processing: During this step payload protection takes place using security parameters defined in the
tunnel establishment phase.
We cover the first stepIPsec tunnel establishment using IKEon the next several pages.
Step 1: Tunnel Establishment Using Internet Key Exchange

IKE is a secure key management protocol used by IPsec to have information exchanged in a secure and dynamic manner with
little or no intervention. The IKE proposal exchange is Phase 1 of the IPsec tunnel establishment process. The following
attributes exchange between IPsec peers as a part of the IKE process:
Encryption algorithm;
Hash algorithm;
Authentication method; and
Diffie-Hellman group.
Once IPsec peers negotiate these attributes, they secure future attribute exchanges used to protect data. IKE exchanges
authenticate using one of the following methods:
Preshared keys;
Digital signatures; or
Public key encryption.
IKE is preferable to manual keys in IPsec implementations because of the ease of management and scalability.
Security Associations
A security association (SA) is a set of policies and keys used to protect information. SAs establish upon the successful
completion of IKE negotiations. An SA is uniquely identified by the security parameter index (SPI) value, the tunnel destination
address, and the security protocolEncapsulating Security Payload (ESP) or authentication header (AH)in use. The lifetime of
an SA can be based on either a time value or a value determined by the volume of traffic protected by the proposal.
SA Database
SAs are stored in a security association database. Each entry includes the name of the particular VPN, the remote gateway IP
address, the SPIs for each direction, the agreed-upon security protocol, encryption, and authentication algorithms and keys.
IKE Phases
IKE tunnel establishment happens in two phases:
Phase 1 establishes a secured channel between gateways for Phase 2 negotiations to occur. The Diffie-Hellman
key exchange algorithm establishes a shared key for encryption.
Phase 2 establishes the specific VPN connections. SAs are negotiated on behalf of IPsec to determine the
encryption and authentication algorithms to use when sending user data. The SA is identified by a unique SPI that
is also negotiated during Phase 2.
A single Phase 1 channel can establish multiple Phase 2 SAs or VPNs. If wanted, a second Diffie-Hellman exchange can be
performed during Phase 2 to negotiate a new tunnel key. Because of the encryption on this exchange, it is named Perfect
Forward Secrecy (PFS).
IKE Phase 1: Main Mode
IKE main mode is used when both tunnel peers have static IP addresses. The Phase 1 exchange determines the following
attributes:
Hash algorithm;
DH group; and
Authentication method:
Preshared keys;
Digital signatures; and
Public key encryption.
The first two messages validate the peer configuration (by checking the cookie against the locally configured peer IP address)
and negotiate the parameters listed previously. Both tunnel peers must have at least one configured matching proposal for
Phase 1 exchange success.
The next two messages exchange Diffie-Hellman public key values and nonces necessary to compute the shared key.
The last two messages send simple identification information using the negotiated key; these messages validate that the key
calculation was correct.
For Message 1 and Message 2, peers exchange cookies and SA proposals. Cookies are 8-byte pseudo-random numbers
generated by the sending machine (I=initiator) and receiving machine (R=receptor). Every cookie is unique to the machine and
to each particular exchange. These cookies guarantee uniqueness and replay protection by hashing the sender's IP address,
port, protocol, and timestamp, which results in a unique identifier known only to the originator. Hence, they are included in every
IPsec packet and used to identify communication. In turn, the receptor inserts its known cookie in Message 2 if it accepts the SA
proposal.
An IPsec SA proposal contains the following:
Phase 1 authentication method (main mode or aggressive mode);
DH group number;
Authentication algorithm; and
Key lifetime.
For Message 3 and Message 4, the DH public values exchange to create a common session key. Nonces, which are essentially
random numbers, also exchange at this time for use as seeds for keys generated later.
After both sides exchange their DH public values, a key is created on each side to encrypt the rest of the IKE Phase 1 messages.
The session key is a result of the exchanged public keys traveling to each partner.
Messages 5 and 6 use the pre-shared key in the HMAC algorithm.
IKE Phase 1: Aggressive Mode
IKE aggressive mode is used when one of the tunnel peers has a dynamic IP address that could be a remote end user dialing in
to the Internet, or a remote site using DHCP to acquire an IP address. (Main mode cannot be used because the first two
messages validate peer IP addresses. In the case of a dynamic host address, the peer cannot preconfigure the address.)
Phase 1 aggressive mode must initiate by the device with the dynamic IP address. The first two messages negotiate policy and
exchange DH public values and nonces. In addition, the second message authenticates the responder; the ID hash is compared
with the locally configured peer ID.
The third message authenticates the initiator and provides a proof of participation in the exchange.
IKE Phase 2: Quick Mode
Once Phase 1 is complete, proposals exchange to establish a specific VPN. The following attributes are negotiated in Phase 2:
Security protocol (ESP or AH);
Tunnel mode or transport mode;
Proxy IDs; and
Optional DH group.
Upon successful completion of quick mode, user data encrypts between the configured IPsec peers. Both tunnel peers must
have at least one matching proposal configured for Phase 2 exchange success.
The result of Phase 2 is to create an IPsec VPN for user data to securely transmit through the network.
For Message 1 and Message 2, a Phase 2 proposal list exchanges. The list contains encrypted and authenticated information
that determines the algorithms and keys for encrypting and authenticating user data. The Phase 2 proposal list contains the
following items:
ESP or AH;
DH group number (0 for no PFS);
Authentication algorithm;
Key lifetime;
Proxy ID (policy rule); and
DH public keys (optional if using PFS).
Message 3 acknowledges information sent from quick mode Message 2 so that the Phase 2 tunnel can establish.
IPsec: A Two-Step ProcessStep 2
Now that we have covered the tunnel establishment step of the IPsec process, we cover the next stepIPsec traffic processing.
Once the IPsec tunnel establishes, the devices are ready to send the payload using the IPsec attributes and protocols, which
ensure payload protection.
Goal of IPsec Traffic Processing

During the IPsec traffic processing step, the devices have one goalto ensure traffic protection. The most commonly used IPsec
mode is ESP tunnel mode.
IPsec Modes
IPsec handles the payload using one of two modestransport or tunnel.
We discuss each mode in the next few pages.
IPsec Protocols
IPsec uses two protocols to ensure payload securitythe AH protocol
and the ESP protocol. Again, we discuss each of these protocols in the
next few pages.
IPsec Modes
You can implement IPsec in the following two modes:
Tunnel mode: This mode is the most commonly implemented method. Tunnel mode is implemented between IPsec
gateways or an IPsec gateway and a remote client providing secure access to the networks behind the gateway. In
this method, end systems need not be aware of the IPsec protocol suite. All encryption and decryption takes place
on the IPsec gateways on behalf of the hosts behind the gateway.
Transport mode: This mode is implemented between IPsec end systems. End systems should be aware of the IPsec
protocol suite. They do all the encryption and decryption of data.
IPsec Protocols
Two protocols exist that IPsec can use to ensure payload securityAH protocol and ESP:
AH provides only data integrity, authentication, and antireplay services. AH is identified by IP protocol number 51. It
uses MD5 or SHA-1 to provide data integrity services. AH provides no encryption of data in the packets.
ESP provides data confidentiality, data integrity, authentication, and antireplay services. It does not use a transport
protocol like TCP or UDP; it rides directly on top of IP using protocol number 50. ESP uses symmetric key algorithms
like DES, triple Data Encryption Standard (3DES), or AES, and hash methods like MD5 and SHA-1 to provide
security services. Antireplay services ensure that third parties cannot capture and retransmit datagrams. By
checking sequence numbers, a receiver can determine receipt of a packet and can discard any repetitions.
Example: Tunnel Mode AH Packets
AH authenticates only the immutable fields in the IP header. Fields like time to live (TTL) and type of service (ToS) change during
packet transit, so these fields do not receive authentication. The new IP header contains protocol number 51, signifying AH.
The AH header contains the following items:
Next header: Information on the next expected segment;
Payload length: Indicates the size of the payload;
SPI: An arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH),
uniquely identifies the security association for this datagram; and
Sequence number: An unsigned 32-bit field containing a monotonically increasing counter value (sequence
number). It is used to detect antireplay.
Example: Tunnel Mode ESP Packets
In tunnel mode, the ESP header inserts between the new IP header and the original IP header. The new IP header contains
protocol 50, representing ESP. The ESP header contains the following information:
SPI: An arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP),
uniquely identifies the security association for this datagram; and
Sequence number: An unsigned 32-bit field containing a monotonically increasing counter value (sequence
number); it is used to detect antireplay.
The ESP trailer contains the following information:
Padding/pad length: Depending on original data size, padding might be required to fill the packet; and
Next header: Information on the next expected segment.
ESP Auth is the integrity check value (that is, the hash value) for this packet.
Traffic Processing: Part 1
The following list describes the order of traffic processing:

1.
The packet arrives at the remote Junos security platform.
2.
The Junos OS looks up the destination route and determines the Egress Zone.
3.
The Junos OS looks up the security policy. The traffic matches a tunnel policy.
4.
The original packet receives encryption.
5.
The Junos OS hashes the packet with an authentication key.
6.
The Junos OS builds the tunnel packet with a new IP header, IPsec header, and hash value. The new packet travels
to the tunnel peer.
Traffic Processing: Part 2
This list is a continuation of the list from the previous page, describing the order of traffic processing:
7.
The corporate Junos security platform receives the encrypted packet.
8.
The Junos OS looks up the incoming SPI in the local SA database. The matching record contains encryption and
authentication algorithms, and keys.
9.
The Junos OS compares the locally calculated hash with the received hash.
10.
The Junos OS decrypts the packet.
11.
The Junos OS performs the routing lookup for the decrypted packet and determines the Egress Zone.
12.
The Junos OS checks the associated security policy. It forwards the packet if the tunnel policy exists for the packet.
IPsec Processing Summary
The graphic provides a summary of all the steps of IPsec traffic processing.
IPsec Implementation Methods

The Junos OS offers two methods for IPsec VPN implementation:
Policy-based VPNs: To implement this method, a security policy specifies as its action the IPsec VPN tunnel for
transit traffic that meets the policys match criteria. Policy-based VPNs are required when one endpoint of the
tunnel uses dynamic addressing. For policy-based IPsec VPNs, a new tunnel generates for each flow of traffic that
matches the policy. Because each tunnel requires its own negotiation process and a separate pair of SAs, the use
of policy-based IPsec VPNs can require more resources than route-based IPsec VPNs.
Route-based VPNs: Unlike the process for policy-based IPsec VPNs, for route-based IPsec VPNs, a policy refers to a
destination addressnot an IPsec VPN tunnel. Because a destination address is used, route-based VPNs are
generally the best VPNs to use when a routing protocol adjacency must be formed across the tunnel. When the
Junos OS searches a route that must send traffic to the destination address, it finds a route associated with a
secure tunnel interface (st0.x). The tunnel interface is bound to a specific IPsec VPN tunnel, and traffic routes to
the tunnel if the policy action is permit. With a route-based IPsec VPN, in most cases, only one VPN exists
between two sites.
Elements of IPsec VPN Configuration:

IPsec VPN configuration consists of three steps:
1.
Configuring IKE Phase 1;
2.
Configuring IKE Phase 2; and
3.
Applying the IPsec implementation method, which includes implementing either policy-based VPNs or route-based
VPNs.
Configuring IKE Phase 1 Parameters: Step A
IKE Phase 1 configuration requires that you perform the following steps:
A.
Configure IKE Phase 1 proposals;
B.
Configure IKE policies and reference the proposals; and
C.
Configure the IKE gateway and reference the policy.
The inset addresses Step A, which is optional, because you can use the Junos predefined proposals. The following are the
predefined proposals:
basic:
Proposal 1: preshared key, DH g1, DES, and SHA1
Proposal 2: preshared key, DH g1, DES, and MD5
compatible:
Proposal 1: preshared key, DH g2, 3DES, and SHA1
Proposal 2: preshared key, DH g2, 3DES, and MD5
Proposal 3: preshared key, DH g2, DES, and SHA1
Proposal 4: preshared key, DH g2, DES, and MD5
standard:
Proposal 1: preshared key, DH g2, 3DES, and SHA1
Proposal 2: preshared key, DH g2, AES128, and SHA1
Configuring IKE Phase 1 Parameters: Step B
The inset illustrates the syntax for Step B of IKE Phase 1 configuration, which is policy configuration. For this step you must
either refer to the preconfigured proposal from Step A or use a system-defined proposal. Also, within the policy you must specify
the preshared key and mode of IKEmain or aggressive.
Configuration of IKE Phase 1 Parameters: Step C
The inset illustrates the last step of IKE Phase 1 configuration, which is gateway configuration. In this step you must refer to the
policy configured in the previous step, define the peer address, and specify the outgoing interface. Optionally, you can configure
dead peer detection (DPD) to send a DPD request packet if the device does not receive traffic from a peer for the number of
seconds specified with the interval option. You can also configure DPD to consider the peer unavailable after a threshold
number of interval periods is reached. For example, assume that the interval value is 10 seconds and the threshold value is 5.
If the device does not receive traffic from a peer for 10 seconds, it sends a DPD request packet to it. The Junos security platform
then considers the peer unavailable after five sequences of waiting for 10 seconds.
Configuring IKE Phase 2 Parameters: Step A
IKE Phase 2 configuration requires that you configure the following steps:
A.
IKE Phase 2 proposals;
B.
IKE Phase 2 policies; and
C.
IKE Phase 2 VPN tunnel.
The inset addresses Step A, which is optional, because you can use predefined proposals. The following are the predefined
proposals:
basic:
Proposal 1: no PFS, ESP, DES, and SHA1
Proposal 2: no PFS, DH g1, DES, and MD5
compatible:
Proposal 1: no PFS, ESP, 3DES, and SHA1
Proposal 2: no PFS, ESP, 3DES, and MD5
Proposal 3: no PFS, ESP, DES, and SHA1
Proposal 4: no PFS, ESP, DES, and MD5
standard:
Proposal 1: ESP, DH g2, 3DES, and SHA1
Proposal 2: ESP, DH g2, AES128, and SHA1
Configuring IKE Phase 2 Parameters: Step B
The inset illustrates the syntax for Step B of IKE Phase 2 configuration, which is policy configuration. For this step, you must
either refer to the preconfigured proposal from Step A or use a system-defined proposal. Also, within the policy, you have the
option to configure PFS to use with the three supported groups of DH as the method for the Junos OS to generate the encryption
key.
Configuring IKE Phase 2 Parameters: Step C
The inset illustrates the last step of IKE Phase 2 configuration, which is VPN configuration. In this step, you must refer to the
policy defined in the previous step, as well as the gateway preconfigured in Step C of IKE Phase 1. If you are configuring a
route-based VPN, you must bind the st0.x interface to the VPN, as illustrated in the inset. If you manually set up a tunnel, you
must specify all the necessary attributes manually. Should you choose to do so, you can set up all the necessary parameters
under the security ipsec vpn configuration stanza. The optional establish-tunnels command specifies when to
activate IKE-- immediately, or on-traffic. The immediately option signals the device to activate IKE immediately
after VPN configuration or configuration changes are committed. The on-traffic option signals the device to activate
IKE only when payload traffic flows.
Applying IPsecPolicy-Based IPsec VPNs
If you are implementing a policy-based IPsec VPN, you must apply the configured VPN from within the security policy, as
illustrated in the inset.
Applying IPsecRoute-Based IPsec VPNs
If you are implementing a route-based IPsec VPN, you must perform the following steps:
1.
Configure the secure tunnel interface (st0.x);
2.
Configure a static route or enable dynamic routing that points to the st0.x interface;
3.
Add the st0.x interface to the appropriate security zone; and
4.
Bind the st0.x interface to the IPsec VPN.
Example: Creating Policy-Based IPsec VPNs Using IKE
Consider the following example: you must implement a policy-based IPsec VPN between two SRX Series Services Gateways
named Edge and Remote, as illustrated in the graphic. A policy-based IPsec VPN implies that you must refer to the VPN tunnel
from within the policies at each end, as demonstrated in the graphic.
Example: Configuring IKE Phase 1 Parameters

The inset illustrates the configuration of the following parameters for IKE Phase 1:
1.
Proposal for IKE Phase 1: Recall that this step is optional, because you can use the Junos predefined proposals
(the choices are basic, compatible, or standard). In the inset, we named the configured proposal
ike-phase1-proposal. We decided to use authentication algorithm md5, encryption algorithm 3des-cbc, a
DH key exchange of group 2, and preshared keys as the authentication method.
2.
A policy, called ike-policy1: Within the policy we specified the mode that IKE Phase 1 will usemain mode, in
this case. We referred to the proposal ike-phase1-proposal, and we specified the preshared key.
3.
Gateway, called ike-phase1-gateway: Within the gateway stanza we referred to the policy ike-policy1,
specified the address of peer Remote (1.1.70.1), and specified the external interface that IKE will use to establish
the tunnel (ge-1/0/1.0). Also, we decided to use DPD so that a peer sends a DPD request packet to another
peer if it does not hear from it for 20 seconds. Suppose it is Edge that sends the DPD request packet to Remote.
After sending the DPD request packet, Edge considers Remote to be unavailable after five sequences of waiting
for 20 seconds.
You must repeat the illustrated configuration on the Remote device, defining the appropriate external interface and gateway
address.
Example: Configuring IKE Phase 2 Parameters for

Policy-Based IPsec VPNs
The inset illustrates configuration of IKE Phase 2 parameters for our
example. Our configuration consists of the following:
1.
A proposal for IKE Phase 2: Recall that this step is

optional because you can use the Junos predefined
proposals (the choices are basic, compatible, or
standard). We named the configured proposal
ike-phase2-proposal. We decided to use
authentication algorithm hmac-md5-96, encryption
algorithm 3des-cbc, and the ESP protocol.
2.
A policy called ipsec-pol1: Within the policy we

referred to the proposal ike-phase2-proposal, and
we specified that IPsec will use DH Group 2 as its PFS.
3.
A VPN tunnel, called TunnelA: Within the tunnel we

referred to the gateway ike-phase1-gateway and
the IKE Phase 2 policy ipsec-pol1. We also specified
that tunnels should establish immediately.
Note that you should repeat the configuration illustrated for the Edge device on the Remote device.
Monitoring Policy-Based IPsec VPNs
Once you finish and commit all the configurations, you must ensure that the tunnels are working properly by following the order
of how IPsec works. First ensure that IKE Phase 1 is working properly, then ensure that IKE Phase 2 is working properly. To check
that IKE Phase 1 functions properly, check whether the SAs are formed. Similarly, you perform IKE Phase 2 checking by viewing
the resulting SAs.
The inset illustrates both commands with the resulting outputs. Also, you can view the IPsec statistics that specify the number of
transit packet bytes that the device has encrypted and decrypted.
Example: Creating Route-Based IPsec VPNs Using IKE
Consider another example: In this case you need to set up the IPsec tunnel using the route-based method and IKE. Recall that a
route-based VPN requires only one tunnel between Junos security platforms, while a policy-based VPN sets up a tunnel for every
new flow.
You must ensure that both ends of the VPN tunnel have a secure tunnel interface configuredin our case it is the st0.0
interface, with IP address 1.1.80.0/28. Furthermore, you must ensure that each of the devices has a valid route referring to the
st0.0 interface. In our case we are using static route 0.0.0.0/0.
Example: Configuring a Security Zone for a Route-Based IPsec VPN
Once you configure interface st0.0, you must add it to the corresponding security zone. In our case, we must add it to the
Public security zone. Also note that although the inset provides the configuration for the Edge device, you must also repeat it
for the Remote device.
Example: Configuring IKE Phase 1 Parameters
The inset illustrates the configuration of the following parameters for IKE Phase 1:
1.
The proposal for IKE Phase 1: Recall that this step is optional because you can use the Junos predefined proposals
(the choices are basic, compatible, or standard). We named the configured proposal
ike-phase1-proposal. We decided to use authentication algorithm md5, encryption algorithm 3des-cbc, a
DH key exchange of group2, and preshared keys as the authentication method.
2.
A policy, called ike-policy1: Within the policy, we specified the mode that IKE Phase 1 will usethe main mode,
in this case. We referred to the proposal ike-phase1-proposal, and we specified the preshared key.
3.
A gateway, called ike-phase1-gateway: Within the gateway stanza we referred to the policy ike-policy1,
specified the address of the peer Remote (1.1.70.1), and specified the external interface IKE will use to establish

the tunnel (ge-1/0/1.0). Also, we decided to use DPD so that a peer will send a DPD request packet to another
peer if it does not hear from it for 20 seconds. Suppose that it is Edge that sends the DPD request packet to
Remote. After sending the DPD request packet, Edge considers Remote to be unavailable after five sequences of
waiting for 20 seconds.
Note that you must repeat the illustrated configuration at the Remote device, defining the appropriate external interface and
gateway address.
Example: Configuring IKE Phase 2 Parameters for a Route-Based IPsec VPN
The inset illustrates configuration of IKE Phase 2 parameters for our example. Our configuration consists of the following:
1.
A proposal for IKE Phase 2: Recall that this step is optional, because you can use the Junos predefined proposals
(the choices are basic, compatible, or standard). We named the configured proposal
ike-phase2-proposal. We decided to use authentication algorithm hmac-md5-96, encryption algorithm
3des-cbc, and the ESP protocol.
2.
A policy, named ipsec-pol1: Within the policy we referred to the proposal ike-phase2-proposal, and we
specified that IPsec will use DH group2 as its PFS.
3.
A VPN tunnel, called TunnelA: Within the tunnel we referred to the gateway ike-phase1-gateway and the IKE
Phase 2 policy ipsec-pol1. We also specified that tunnels should establish immediately. Furthermore, we bound
the st0.0 interface to the tunnel.
When you compare the configuration in the inset to the policy-based IPsec IKE Phase 2 configuration, you will notice that the
only difference between the two is the statement binding interface st0.0 to the tunnel.
Note that we must also repeat the configuration illustrated for the Edge device at the Remote device.
Monitoring a Route-Based IPsec VPN: Part 1
Once you finish and commit all the configurations, you must ensure that the tunnels work properly by following the order of how
IPsec works. First ensure that IKE Phase 1 works properly, then ensure that IKE Phase 2 works properly. To check that IKE Phase
1 functions properly, you must check whether the SAs form. Similarly, you perform IKE Phase 2 checking by viewing the resulting
SAs.
The inset illustrates both commands with the resulting outputs. Also, you can view IPsec statistics that specify the number of
transit packet bytes that the device encrypts and decrypts.
One of the differentiating points of a route-based IPsec VPN is that it uses the st0 interface. Therefore, you can use the show
interfaces st0.x command to view whether the interface is up as well as how much information transits through it. If there
is a problem in establishing the route-based IPsec tunnel, the st0 interface is not in the up state. The inset illustrates the results
of the show interface st0 detail command for the Edge device.
The inset is the continuation of the show interfaces st0 detail command from the previous inset. It provides
statistical information for the st0 interface, including flow input, flow output, and flow error statistics.
As we work with a route-based IPsec VPN, it is useful to check the routing table entries, ensuring that an active route referring to
the st0 interface exists. In our case, the 0.0.0.0/0 default route, using interface st0.0 as its next hop, is active.
Other IPsec VPN Monitoring Commands

You can enable traceoptions to debug IKE Phase 1 and Phase 2. Also, you can clear IKE Phase 1 and Phase 2 SAs and
statistics using the clear security ike security-associations and clear security ipsec
security-associations operational commands.
Common IPsec Configuration Problems

You should be aware of the following common problems when configuring IPsec VPNs:
Proposal mismatch: The IKE Phase 1 proposal lists configured on each side do not agree. In this case, the initiator
of the tunnel sees retransmissions and a retransmission limit indicator. The problem is evident at the destination
gateway (the responder). The responder rejects all proposals sent by the initiator.
Preshared key mismatch: The keys do not match.
No route information is available: To establish a gateway, you must either configure an explicit route or a default
route (or use a dynamic routing protocol) to be used to reach the remote gateway.
The destination gateway is misconfigured: It might happen that the destination gateway (responder) does not
recognize the incoming request as originating with a valid peer gateway. Any of the following misconfigurations
could cause this problem:
The peer gateway is not configured correctly;
The outgoing interface is not the right one; or
A proposal mismatch exists.
Review Questions
Answers
1.
The three major security concerns are confidentiality, integrity, and authentication.
2.
The main difference between ESP and AH is that AH does not provide confidentiality, while ESP does.
3.
The Junos OS supports the use of the MD5 and SHA protocols to ensure data integrity.
4.
The two modes available in IKE Phase 1 are main and aggressive.
Chapter 8: Introduction to Intrusion Detection and Prevention

The purpose of the Junos operating systems Intrusion Detection and Prevention (IDP) feature;
Utilizing and updating the IDP signature database;
Utilizing and configuring IDP policy using a policy template; and
Monitoring IDP operation.
What Is IDP?
Initially, network defense consisted of basic stateless firewall protection. Network devices, such as routers, often provided this
feature. As network attacks became more sophisticated, network defense also had to become more sophisticated. Stateful
firewalls, authentication mechanisms, and VPN devices utilizing encrypted traffic offered additional protection from harmful
network traffic and malicious users.
Traditional firewalls might not detect some malicious traffic because manufacturers design VPN devices and firewalls for
high-speed operation of VPN control and access control. For these types of attacks, the solution is to use IDP.
The Junos IDP feature provides additional security beyond a firewall. While a firewall traditionally inspects only Layers 3 and 4,
the Junos OS utilizes the IDP feature to decode and reassemble the protocol stream and thus sees traffic from the
applications point of view (Layer 7). When IDP reassembles the data stream, the Junos OS examines the stream for specified
attack patterns. If no problem with the stream exists, the Junos OS forwards the original packets. If the software detects a
problem within the stream, IDP can drop packets, close or drop sessions, prevent future sessions, and log attacks for review by
network administrators.
Utilizing IDP in combination with SCREEN options, zones, security policies, and other Junos security features offers a complete
approach to network security.
Introduction to Intrusion Detection and Prevention Chapter 81
Fully Integrated IDP
Junos security platforms have IDP functionality fully integrated into the Junos OS. This integration means no additional hardware
or operating system is necessary, resulting in less cost, lower management overhead, and increased operational simplicity.
Live Attack Database
Juniper Networks maintains a database of attack signatures for use with the IDP feature. With a valid license, users can retrieve
updates manually by running a CLI command or automatically by configuring a Junos security platform to update its database at
regular intervals. The full security package download includes various policy templates. These policy templates offer protection
against a variety of common attacks. Once you install the templates, you can customize them to fit the traffic patterns of a
particular network.
IDP Successes
The Junos IDP feature regularly protects networks from the latest Microsoft vulnerabilities. The attack database updates as new
threats emerge, keeping the Junos OS on the leading edge of network defense. IDP allows you to stop attacks before they fully
compromise the network. In the past, you often had to take a reactive approach to network security by parsing logs for security
threats before being able to take action. In the meantime, the network remained vulnerable. Using IDP, you can be proactive by
stopping attacks as they occur, and by preventing future attacks. IDP uses attack signatures to protect your network from
thousands of known attacks. It can also detect protocol anomalies to protect your network from unknown or potential attacks.
Juniper Networks maintains a Web-based security portal (http://www.juniper.net/security) listing the latest attack database
updates, Microsoft security bulletins, attack trends, and other useful security information.
IDP Policy Framework
Policy drives the IDP attack detection engine. IDP policy enables selective enforcement of various IDP attack detection and
prevention techniques on network traffic passing through the IDP engine. Users can write very granular rules to match a section
Chapter 82 Introduction to Intrusion Detection and Prevention

of traffic based on zones, networks, and applications. Users can then apply specific attack prevention techniques on that traffic,
and take active or passive preventive actions.
The graphic illustrates the structural view of an IDP policy. An IDP policy can consist of two types of rulebasesan intrusion
prevention system (IPS) rulebase and an exempt rulebase. A rulebase is a collection of rules. Rules contain a collection of
configuration objects and are similar in structure to security policy because they use configuration objects to create match
conditions and resulting actions. Once you create an IDP policy, the action of a security policy applies it. Although many IDP
policies might exist within the configuration, only one IDP policy is active on a Junos security platform.
IDP Configuration Objects

The Junos OS uses configuration objects to build IDP rules. Use configuration objects to match on zones, source and destination
networks, applications, and attacks or attack groups.
IDP Policy Matching Conditions
The inset shows a sample IDP policy configured with the Junos OS template policy named Recommended. The inset shows a
rule named rule 2 in an IPS rulebase with the matching conditions highlighted. In this case, the rule matches on traffic from any
zone and source address to any zone and destination address. The rule also matches on an application type of default. When
you select this application type, the software bases application matches on the attack or attack group objects. The Junos OS
automatically matches on application or service settings associated with the defined attack or attack group object. You can also
specify a configured application or application-set or use the any option.
The sample configuration in the inset shows a predefined attack group designed for Internet Control Message Protocol (ICMP)
attacks. Predefined attack and attack group objects are part of the signature database that can be downloaded from Juniper
Networks. We discuss the signature database on subsequent pages. You can also specify custom attack and attack group
objects or dynamic attack group objects. Custom attacks and attack groups are user-defined configuration objects. The
software builds dynamic attack groups using filters that match on a particular option, such as an application. For more
information on custom attacks and groups or dynamic attack groups, refer to http://www.juniper.net/techpubs for the Juniper
Networks technical documentation.
IDP Policy Actions
The inset shows the same sample policy rule as on the previous page, but with the action section of the rule highlighted. This
example defines an action of Recommended. This type of action is only applicable to IPS rulebases utilizing predefined attack
objects. A Juniper Networks recommended action is associated with all predefined attack objects. A rule can have one of the
following actions:
no-action: The Junos OS takes no action (used when you only need to generate a log);
ignore-connection: The Junos OS stops scanning traffic for the rest of the connection;
mark-diffserv: The Junos OS assigns the indicated service-differentiation value to the packet then passes it on
normally;
drop-packet: The Junos OS drops a packet before it can reach its destination, but does not close the
connection;
recommended: The action that Juniper Networks recommends when it detects a predefined attack;
drop-connection: The Junos OS drops the connection, preventing traffic for the connection from reaching its
destination;
close-client: The Junos OS closes the connection and sends a RST packet to the client but not to the server;
close-server: The Junos OS closes the connection and sends a RST packet to the server but not to the client;
and
close-client-and-server: The Junos OS closes the connection and sends an RST packet to both the client
and the server.
The example in the inset also illustrates a notification action. This action instructs the Junos OS to log the attack.
Additional IDP Policy Actions
The inset lists a continuation of IDP policy actions. IP actions prevent repeat attacks. This rule action applies to future sessions
that have the same IP action attributes of the flow on which the software detects an attack. For example, you could configure
one of the IP actions in a rule to block all future HTTP sessions between two hosts if the software detects an attack on a session
between those hosts. Optionally, you can specify a timeout value defining that the action should apply only if new sessions
initiate within a specified timeout value in seconds. (The default IP action timeout is 0, which means no timeout.) IP action
attributes consist of a combination of the following fields:
Source IP;
Destination IP;
Destination Port;
From Zone; and
Protocol.
These IP action attributes can be used only in certain combinations and list as targets in the following output:
[edit security idp idp-policy Recommended rulebase-ips rule 2]
user@srx# set then ip-action target ?
destination-address Match destination
service
Match source, destination, dst-port and protocol
source-address
Match source
source-zone
Match source-zone
zone-service
Match source-zone, destination, dst-port, protocol
The following are possible IP actions:
ip-block: The Junos OS silently drops all packets matching the IP action rule;
ip-close: The Junos OS closes any new sessions matching the IP action rule by sending an RST packet to the
client and server; and
ip-notify: The Junos OS generates a log when it finds a session matching the IP action rule.
You can use the severity action to override the default attack severity to a configured value.
Applying IDP Policy
You enable IDP policies by specifying the IDP policy in a security policy, as shown in the inset. The security policy action must be
to permit the flow. Note that once an IDP policy is in use, any change to the [edit security idp] hierarchy, the associated
security policy configuration, or the associated custom applications causes an IDP policy recompilation when you issue the
commit.
Active IDP Policy
Recall that only one IDP policy is active on a Junos security platform at any given time. The inset shows how to configure the
active IDP policy.
Evaluating IDP Rulebases
Once the software compiles an IDP policy, it pushes the policy to the data plane where the IDP policy evaluation occurs. IDP
policy evaluates only the first packet of a session. If a match occurs, the software creates a set of objects and caches them
within the session for use with attack detection on subsequent packets.
The Junos OS evaluates all IDP rules (unlike security policy) but does so sequentially. If a new session matches multiple rules,
the Junos OS performs the most severe action among the rules. The inset shows the order of severity associated with rule
actions.
You can make an IDP rule terminal using the configuration shown in the inset. When the software configures a match in a
terminal rule for the source, destination, zones, and application, it does not continue to check subsequent rules for the same
source, destination, and application. It does not matter whether traffic matches the attack objects in the matching rule or not.
This option is useful for disregarding traffic that originates from a known trusted source. Terminal rules should appear near the
top of the rulebase and before other rules that would match the same traffic.
Exempt Rulebases
The functionality of an exempt rulebase complements an IPS rulebase. You can write rules in an exempt rulebase to skip
detection of a set of attacks in certain traffic. Carefully written rules in an exempt rulebase can significantly reduce the number
of false positives generated by an IPS rulebase. Note that you must configure an IPS rulebase before using an exempt rulebase.
Rules in an exempt rulebase have the same matching conditions as those of an IPS rulebase. The exception is that you cannot
configure the application object, which means rules match all applications. When configuring attack or attack-group objects in
an exempt rulebase, note that these attacks are attacks the software should not inspect in traffic matching this rule. No actions
are available for exempt rulebases.
The Signature Database
The signature database is one of the major components of IDP. It contains definitions of different objectssuch as attack
objects, application signature objects, and service objectsthat it uses to define IDP policy rules. As a response to new
vulnerabilities, Juniper Networks periodically provides a file containing attack database updates on its Web site. You can
download this file to protect your network from new threats. The database lists the attack objects alphabetically, and the names
consist of the attack object group name and the name of the attack object, as shown in the inset.
The security package, which you can download from Juniper Networks, also includes IDP policy templates to help you implement
IDP policy on your Junos security platform. You can use the template policies as they are, or you can customize them for your
network environment. Templates exist for a multitude of network scenarios. The most widely used template is called the
Recommended policy. We discuss downloading the signature database and policy templates on subsequent pages.
IDP Signature Update License
To update the IDP signature database, an IDP signature license is necessary. The inset illustrates the configuration command
for adding a system license, and the result of a successful license addition.
Updating the Security Package Manually
You can download the Juniper Networks security package manually or automatically at specified time intervals. The inset
illustrates the operational mode commands to download the security package and check the status of the download. You must
connect the Junos security platform to the Internet to update a device directly. Alternatively, you can download the update to a
Network and Security Manager (NSM) device, which can be configured to push the updated database to your Junos security
platform.
Installing the Security Package
Once you successfully download the security package, you must install it. The inset illustrates the operational mode commands
for installing the security package and verifying the status of an installation.
Automatic Downloads
As mentioned previously, you can configure a Junos security platform to automatically download the security package. The inset
also shows an example configuration of automating the download.
Signature and Attack Database Version
The inset illustrates the operational mode command used to verify the attack database. The version includes a time and date
stamp so you can check the date of your local database.
Checking Your Connection to the Update Server
The inset illustrates the operational mode command used to check the server connection from your Junos security platform.
This command not only verifies network connectivity, but also provides the remote database version, which is useful for
comparing version differences with the previous command output.
Applying the Recommended IDP Policy: Part 1
The inset and the next two insets demonstrate the steps necessary for downloading and installing the Juniper Networks
recommended IDP policy. The inset shows the operational mode commands used to download and install the latest policy
templates provided by Juniper Networks. Recall that a Junos security platform must have an IDP signature license to download
the signature database or associated policy templates.
The Junos OS downloads Juniper Networks policy templates in the form of a commit script. Once you download and install the
policy templates, you must activate the template commit script with the configuration mode command shown in the inset. You
must perform a commit action to activate a commit script. In this example, we use the Junos CLI auto-completion feature to
verify the availability of the policy templates for configuration as the active IDP policy. For more information regarding commit
scripts, refer to http://www.juniper.net/techpubs for the Juniper Networks technical publications.
The next step is to set the recommended policy as the active policy. Recall that only one IDP policy can be active on a Junos
security platform. As illustrated in the inset, you must delete or deactivate the commit script. This step is important because
every subsequent commit will overwrite any changes that you made to template policies. The final step to activating the
recommended IDP policy is to apply the IDP action to a security policy. Do not forget to commit the changes!
Verifying the Application of IDP Policy
The inset shows a sample output of the show security policies policy-name command. By using the detail
option, you can verify that you enabled IDP for this security policy.
Monitoring IDP Status and Statistics
The inset illustrates the show security idp status command. This command provides traffic statistics related to the IDP
policy engine. It also outputs the active IDP policy and IDP detector version.
IDP Counters
The command shown in the inset along with one of the command arguments provides various counters useful in monitoring IDP
operation.
Monitoring Memory Utilization
If the IDP process runs out of memory, the software no longer evaluates traffic for attacks. Use the command shown in the inset
to monitor memory utilization.
IDP Logging
You enable logging using the notification action. The Junos OS stores logs according to the data plane logging configuration
present on the Junos security platform.
When you configure an IDP rule for logging, each matching event creates a log entry. Because the software generates IDP event
logs during an attack, log generation happens in bursts, generating a much larger volume of messages during an attack. In
comparison to other event messages, the message size is also much larger for attack-generated messages. The log volume and
message size are important concerns for log management. To better manage the volume of log messages, IDP supports log
suppression. Log suppression limits multiple instances of the same log occurring from the same or similar sessions over a given
period of time. The software enables log suppression by default but you can adjust attributes through configuration under the
[edit security idp sensor-configuration log suppression] hierarchy.
IDP Traceoptions
You can configure IDP traceoptions to log control plane events. Currently, the only flag available is the all flag. By default, the
software logs IDP traceoptions events to the /var/log/idpd file.
Review Questions
Answers
1.
The Junos OS processes the rule with the most severe action.
2.
The exempt rulebase exempts specified traffic from IDP policy.
3.
Evaluation of a rulebase stops only when the software matches a terminal rule.
4.
To apply an IDP policy, you must make it the active policy and reference an IDP action in a security policy.
Chapter 9: High Availability Clustering Theory

High availability (HA) clustering and its functionality;
Chassis cluster components;
Chassis cluster operation;
Chassis cluster configuration; and
Chassis cluster monitoring.
High Availability Characteristics
The Junos operating system high availability (HA) feature provides stateful session failover. This ability applies to TCP and UDP
sessionsthose that deploy Network Address Translation (NAT), IP Security (IPsec), or authentication, as well as those that do
not.
High availability includes the synchronization of configuration files and the dynamic runtime session states between Junos
security platforms deploying it. The Junos implementation of high availability clustering currently supports an active-passive
redundancy for the control plane and an active-active redundancy for the data plane. Check the Juniper Networks technical
documentation for high availability support specific to your platform at http://www.juniper.net/techpubs.
High Availability Clustering Theory Chapter 91
High Availability Using Chassis Clusters
The Junos OS achieves high availability on Junos security platforms using chassis clustering. Chassis clustering provides
network node redundancy by grouping two like devices into a cluster. The two nodes back each other up with one node acting as
the primary and the other as the secondary node, ensuring the stateful failover of processes and services in the event of system
or hardware failure. A control link between services processing cards (SPCs) or revenue ports and an Ethernet data link between
revenue ports connect two like devices. Junos security platforms must be the same model, and all SPCs, network processing
cards (NPCs), and input/output cards (IOCs) on high-end platforms must have the same slot placement and hardware revision.
The chassis clustering feature in the Junos OS is built on the high availability methodology of Juniper Networks M Series and
T Series platforms and the TX Matrix platform, including multichassis clustering, active-passive Routing Engines (REs) ,
active-active Packet Forwarding Engines (PFEs), and graceful RE switchover capability.
Considering all the process implementations on M Series and T Series platforms, most of which have complete hardware and
control plane redundancies, the Junos implementation for Junos security platforms mirrors the RE and PFE backup system and
RE and PFE redundancy using Ethernet interfaces. Junos OS security platforms add redundancy features by introducing
interchassis clustering and stateful failovers. Devices in a chassis cluster synchronize the configuration, kernel, and PFE session
states across the cluster to facilitate high availability, failover of stateful services, and load balancing.
Chassis Cluster Components

A chassis cluster consists of the following components:
Cluster identification, including cluster-id id and node id;
Redundancy groups (RGs); and
Chassis cluster interfaces:
fxp1: The control plane interface;
fxp0: The out-of-band management interface;
fab: The data plane interface;
swfab: The switching data plane interface; and
reth: A redundancy interface.
We address all chassis cluster components in the next section of this chapter.
Chapter 92 High Availability Clustering Theory
cluster-id Details
You can deploy up to fifteen chassis clusters in your environment. A unique cluster-id value, which ranges from 115,
identifies each cluster. A Junos security platform can belong to only one cluster at any given time. The device ignores high
availability configuration and acts as a standalone device if a cluster-id value is zero. When a device joins a cluster, it
becomes a node within that cluster, identified by a node id. If you choose to alter a cluster-id id or node id parameter,
you must reboot the device to activate the changes.
node id Details
The node id uniquely identifies a Junos security platform within a cluster. Because only two nodes can exist in a cluster, node
id values range from 01.
Recall the interface naming structure used by the Junos OS:
(media type)-(fpc slot #)/(pic slot #)/(port #), for example, ge-1/0/3.
In the case of Junos security platforms, the Flexible PIC Concentrator (FPC) can be either an IOC, an SPC, a Physical Interface
Module (PIM), or a fixed interface. The software uses the node id value to offset the FPC slot value in the interface name of a
device. Specifically, the software uses the following formula to calculate the FPC slot number:
Cluster interface FPC slot number =
(node id * max FPC slots) + standalone FPC slot number.
For example, a Juniper Networks SRX5800 Services Gateway has a maximum of 12 slots. Using the FPC slot number
calculation, you can determine that the second slot on node 1 of a chassis cluster uses an interface name of ge-13/x/y or
xe-13/x/y.
Redundancy Group
A redundancy group (RG) is an abstract construct that includes and manages a collection of objects. It contains objects on both
nodes of a cluster. An RG is primary on one node and backup on the other node at any given time. When an RG is primary on a
node, its objects on that node are active.

Junos security platforms support up to 256 RGs. RGs are independent units of failover, and one RGs primacy does not affect
the other RGs primacy. In other words, one of the RGs can be primary on node 0, while the other RG is primary on node 1. When
an RG fails over, all its objects fail over together.
When you initialize a Junos security platform in chassis cluster mode, the system creates a redundancy group called RG0. RG0
manages the primacy and failover between the REs on each node of the cluster. As is the case for all redundancy groups, RG0
can be primary on only one node at a time. The node on which RG0 is primary determines which RE is active in the cluster. You
must explicitly create RGx in the configuration and manage interface redundancy. RGx can contain up to 15 redundant Ethernet
interfaces called reth interfaces. We discuss reth interfaces in detail later in this chapter.
Three RG Object States

An RG object can be in one of the following three states:
A blank state, which is the starting state for an RG;
A primary state; or
A secondary state.
RG Object State Transitions

As indicated on the diagram, an RG object state can transition from blank
to either primary or secondary. In addition, an RG object in the primary
state can transition to the secondary state, and vice versa. Both primary
and secondary states can transition back to the blank state when you
delete an RG from the configuration file or when the device reboots.
RG Primacy Rules
The rules for RG primacy are as follows:
An RG is primary on the node with the higher priority.
By default, both nodes have the same priority for RG0, but you can change the default setting to specify which node
is primary for RG0. You must explicitly configure the node priority for RGx.
If you initialize both nodes of a cluster at the same time and you do not change the default setting for RG0 node
priority, Node 0 takes precedence.
If one node of the cluster initializes before the other, the first node to initialize takes precedence and remains the
primary node for the RG unless the preempt configuration option is present. Note that the preempt
configuration option is not supported on RG0.
RG State Transitions
For RGx to fail over automatically to another node, the software must monitor its interfaces. When you configure an RGx, you can
specify a set of interfaces the RG is to monitor for status, checking whether the interface is up or down. When you configure an
interface for RGx to monitor, you give it a weight value. RGx has a threshold tolerance value initially set to 255. When an
interface monitored by RGx becomes unavailable, the software subtracts its weight from the threshold. When the threshold
reaches zero, all objects within RGx fail over to the other node.
Illustration of RGxs Use for Load Balancing
The graphic illustrates an example of load balancing between two nodes of a cluster. Specifically, RG1 is primary on Node 0 for
destination network 10.10.0.0/16, and RG2 is primary on Node 1 for destination network 10.20.0.0/16. In addition, RG1 is
secondary on Node 1 for destination network 10.10.0.0/16, and RG2 is secondary on Node 0 for destination network
10.20.0.0/16. This load balancing across both nodes is a prime example of an active/active cluster, which is discussed in more
detail in the next chapter.
Chassis Cluster Interfacesreth
A reth is a pseudo-interface that includes a physical interface from each node of a cluster. A reth can contain either two physical
Ethernet interfaces, referred to as child interfaces of the reth interface. Each reth can contain only two interfaces because a
cluster contains only two nodes. Although reth interfaces must be the same kindeither Fast Ethernet, Gigabit Ethernet, or
10-Gigabit Ethernetthey do not need to be in the same slots on each node. A reth child interface associates with the reth
interface as part of the child interface configuration. A reth child interface inherits properties of its parent interface. A reth
interface inherits its failover properties from RGx. Consequently, a reth interface can remain active even if one of its child

interfaces becomes unavailable. In a reth interface that does not use a link aggregation group (LAG), only one child interface of
can accept and send traffic at a time. A reth interface has a virtual MAC address, which is based on the cluster ID and the
interface ID.
How Is the Virtual MAC Calculated?
When calculating the virtual MAC of a reth interface, you have control over two parts: the first 8 bits and bit positions 13 through
16. The other bits in the virtual MAC address represent a Juniper organizational unit identifier (OUI) number or they are
reserved. The first 8 bits represent the reth interface number; in the example in the graphic, interface reth0 receives
hexadecimal value of 00. If interface reth16 is configured, it receives a hexadecimal value of 10 in this field. The 13 through 16
bit positions represent the chassis cluster ID. In the example, the chassis cluster ID is 1.
This method of calculating the virtual MAC for reth interfaces ensures that multiple chassis clusters can exist in the same Layer
2 domain and that no duplicate MAC address problems will exist.
Redundant Ethernet LAG Interfaces
Reth LAG interfaces combine two forms of redundancy into onelink redundancy and node redundancy. This two factor
redundancy increases the HA of the chassis cluster and the overall throughput of the reth interface. This redundancy is

accomplished by adding two or more links per node, a maximum of 8 links per node, and is managed by the IEEE 802.3ad
standard.
Reth LAG interfaces combine characteristics of reth interfaces and LAG interfaces. All child interfaces in the reth LAG must be
the same speed, but do not have to be the same cable type. Forming a reth LAG interface using four Gigabit interfaces in which
two of the Gigabit interfaces use copper cables and the other two use fiber cables is a valid configuration. Whereas, forming a
reth LAG interface using three Gigabit interfaces and one Fast Ethernet interface, or forming a reth LAG interface using four Fast
Ethernet interfaces, in which three are operating in full duplex mode and one is operating in half duplex mode is not a valid
configuration.
A total of 128 LAG interfaces are supported per chassis cluster. Any combination of aggregate Ethernet, Redundant Ethernet, or
Redundant Ethernet LAG interfaces is included in this limit. Local LAG interfaces, which are represented by the ae interface
notation, are supported on the primary node as well as the secondary node but they, or their child interfaces, cannot be added
as a child interface of a reth interface.
The minimum-links statement is supported for reth LAG interfaces and provides another factor to the overall HA of the chassis
cluster. The minimum-links statement is enabled by default and has a value of one, which means all links in the reth LAG group
on the primary node must fail for the associated redundancy group to failover to the secondary node.
The following represents an example reth LAG configuration:
user@srx> show configuration interfaces | find ge-1/0/1
ge-1/0/1 {
gigether-options {
redundant-parent reth0;
}
}
ge-1/0/2 {
gigether-options {
}
}
ge-1/0/3 {
gigether-options {
}
}
ge-12/0/1 {
gigether-options {
}
}
ge-12/0/2 {
gigether-options {
}
}
ge-12/0/3 {
gigether-options {
}
}
reth0 {
redundant-ether-options {
redundancy-group 1;
minimum-links 3;
}
unit 0 {
family inet {
address 10.100.37.214/24;
}
}

}
user@srx> show interfaces terse | match reth
ge-1/0/1.0
up
up
aenet
--> reth0.0
ge-1/0/2.0
up
up
aenet
--> reth0.0
ge-1/0/3.0
up
up
aenet
--> reth0.0
ge-12/0/1.0
up
up
aenet
--> reth0.0
ge-12/0/2.0
up
up
aenet
--> reth0.0
ge-12/0/3.0
up
up
aenet
--> reth0.0
reth0
up
up
reth0.0
up
up
inet
10.100.37.214/24
Switch Configuration Considerations
Typically in a LAG configuration when two devices are back-to-back, or the links participating in the LAG group are traveling
through transport equipment, LAG is only configured on the devices. In a reth LAG scenario where a switch, or multiple
switches, are between the devices, the switch interfaces participating in the LAG group requires 802.3ad to be enabled. In the
instance where only one switch is between the two nodes there must be two separate LAG groups configured on the switch, one
for each bundle of links coming from each device. This configuration allows the traffic to be received, processed, and
transmitted correctly through the switch or switches involved.
Chassis Cluster Interfacesfxp0

Junos security platform management interfaces allow out-of-band network access and network management to each node in
the cluster. Only high-end security platforms contain an fxp0 interface. For branch security platforms in a chassis cluster, the
Junos OS designates one of the revenue ports to act as the fxp0 interface. Refer to your products documentation at http://
www.juniper.net/techpubs to determine which port acts as the fxp0 interface for your specific branch device.
We recommend giving each node in a chassis cluster a unique IP address for the fxp0 interface of each node. This practice
allows independent node management. To accomplish this practice, you must configure interfaces in separate configuration
groups under the [edit groups] configuration hierarchy. We cover details regarding configuration of groups later in this
chapter.
Chassis Cluster Interfacesfxp1
Each SPC on a high-end SRX Series platform has two ports for use as a chassis cluster control link, named fxp1. Currently, the
software supports only a single control link. On high-end security platforms, the control link connects through ports on SPCs.
Use Port 0 if the RE is in RE Slot 0 within the chassis, and use Port 1 if the RE is in RE Slot 1. Branch security platforms use
revenue ports for the chassis cluster control link. Check the documentation specific to your device to determine which port to
use.
On high-end security platforms, configuration is necessary to designate the ports associated with fxp1 as shown:
[edit chassis cluster]
user@srx# show
control-ports {
fpc slot port port;
fpc slot port port;
}
The system provides each fxp1 control link interface with an internal IP address and uses the proprietary Trivial Network
Protocol (TNP) to transmit the session state, the configuration file, and liveliness signals across the nodes. The Junos OS
periodically transmits heartbeat signals over the control link to determine the health of the control link. If the number of missed
heartbeats reaches the configured threshold and the fabric link is operational, the system signals a control link failure.
If the control link fails, the Junos OS disables the secondary node to prevent the possibility of each node becoming primary for
all RGs, including RG0.
Once a secondary node is disabled, you must reboot the node to resume operation. You can make this reboot automatic on
some Junos security platforms using the control-link-recovery configuration option as follows:
{primary:node0}[edit chassis cluster]
user@srx# show
control-link-recovery;
Chassis Cluster Interfacesfab
The Junos OS uses the fabric (fab) interface for the high availability data plane. When the system creates the fab interface, the
software assigns it an internally derived IP address that it uses for packet transmission. The fab is a physical connection
between two Ethernet interfaces on the same LAN. Both interfaces must be the same media type. Unlike the control link that
has system-determined interfaces, you specify the physical interfaces to use for the fab data link in the configuration.
Similar to the fxp1 control link, the fab link uses fabric probes to determine the health of the link. If the Junos OS determines
that there has been a fabric link failure, it disables the secondary node, and a reboot is required to restore operation.
The Junos OS does not support traditional interface features such as firewall filters, policies, logical interfaces, or system
services on the fab link, and the fab link is not configured under a security zone. Although the Junos OS does not support
fragmentation on the fab link, it does support jumbo frames up to 8980 bytes. Therefore, we recommend that no interface in a
chassis cluster exceed this maximum transmission unit (MTU) size.
Chassis Cluster Interfacesswfab
The swfab interfaces are similar to the fab interfaces; however, the SRX device strictly uses them to forward Layer 2 Ethernet
switching traffic between the two nodes by placing both nodes in the same Layer 2 domain. You can use any built-in interface
that supports Ethernet switching on a supported branch SRX platform except for the SRX550 and SRX650 devices. The SRX550
and SRX650 must use Gigabit-Backplane Physical Interface Module (GPIM) interfaces for the swfab connections.
The monitoring of the swfab link health is accomplished through the use of switch fabric probes. If too many fabric probes are
lost, the cluster nodes enter separate Layer 2 switching domains. However, the loss of the swfab link does not break up the
cluster. If the swfab link is lost, both nodes remain in the cluster as long as the fxp1 and fab links are functional.
As with fab interfaces, swfab interfaces do not support filters, policies, logical interfaces, or services. The swfab interfaces are
also not configured under a security zone. The Junos OS supports the transmission of jumbo frames across the swfab link up to
the maximum MTU of the swfab link member interfaces.
Dual Data Plane Links
Fabric links carry real-time objects (RTOs), fabric probes, and transit data. These links allow session synchronization and
forwarding of traffic between the nodes participating in the chassis cluster. If only one fabric link is present and a failure
scenario occurs, the results are catastrophic. All sessions are lost on the backup node and it transitions into the disable state.
Once the fabric link is restored, the backup node must be rebooted to recover and participate in the chassis cluster again.

Dual fabric links remove this single point of failure. If one fabric link fails and one remains functional, all sessions are
maintained between the two nodes and the chassis cluster status is preserved. Fabric link failures are not only detected when
the local fabric link interface goes down, but also when end-to-end connectivity is lost. Fabric probes are sent on each link to
determine the health of the links. If a predetermined amount of time expires without the receipt of any fabric probes the link is
declared down6 seconds for high-end SRX Series devices and 20 seconds for branch SRX Series devices.
The SRX devices also supports dual switch fabric links, which protect against one switch fabric link failing and both clusters
entering into separate Layer 2 switching domains. When you implement dual switch fabric links, frames are load balanced
across both links. This method ensures that overutilization of one switch fabric link does not occur.
A similar type and an equal number of interfaces must be used on each node in the cluster. A dual fabric link setup that
includes two Gigabit Ethernet links on the primary node, and one Gigabit and one Fast Ethernet on the secondary node is not
allowed. Also, the SFP interfaces located in mini PIMs on the branch SRX Series devices can not be used for fabric links.
Dual fabric links not only increase redundancy but also increase performance. In a single fabric link configuration RTOs, probes,
and data travel over a single link. This single fabric link configuration can be problematic in an active/active chassis cluster, in
which large amounts of data is crossing the fabric linkRTOs, probes, and data might be lost. In a dual fabric link setup RTOs
and fabric probes traverse one link and data traffic traverses the other link. The RTOs and probes use the fabric link which has
the lowest slot, PIC, and port numberdata traffic uses the other link. If a situation occurs in which one fabric link is lost all
inter-chassis traffic uses the remaining link. If the peers receive hellos over the recently lost link for 30 seconds the link is
considered active and load balancing resumes as before.
The child links are bundled together in an internal aggregate Ethernet interface and the maximum number of available
aggregated interfaces is reduced by one. For example, the maximum number of aggregated interfaces that can be configured
on the chassis cluster is 128. When dual fabric links are configured the remaining available aggregate interfaces that can be
configured has dropped to 127.
Dual Control Plane Links
The SRX5000, SRX3000, and SRX1400 lines also support control link redundancy. Dual control links provide a redundant link
for control traffic. Unlike dual fabric links, only one control link will be used at any one time.
For SRX5000 devices, at least two Switch Control Boards (SCBs) must be present, and both SCBs must have an RE installed.
The secondary RE does not act as a normal RE with control plane functions, but instead is used to initialize the switch on the
secondary SCB, allowing for the second control link. Once these components are in place, you can utilize the control ports of any
SPC. Note that while you can use both control ports on a single SPC, it is recommended to utilize two SPCs so that no single SPC
represents a single point of failure. If possible, it is also recommended to use SPCs with higher slot numbers because the SPC in
the lowest slot number also acts as the Central Point (CP) in session processing.
The SRX3000 line also supports dual control links, but requires the addition of an SRX Clustering Module (SCM). Note that the
SCM fits in an RE slot. It is not, however, an RE and will not perform the functions of an RE. Its sole purpose is to initialize a
second HA control link.
The SRX1400 devices support dual control links through the use of the SYSIO card, which represents port 10 and 11 on the
device. During chassis clustering these ports are dedicated control ports, and no additional configuration is necessary to enable
the control port functionality.
Purpose of Real-Time Objects
To provide for session or flow redundancy, the data plane synchronizes its state by sending special payload packets named
real-time objects (RTOs) from one node to the other across the fab data link. By transmitting information about a session
between the nodes, RTOs ensure the consistency and stability of sessions if a failover occurs; thus, they enable the system to
continue to process traffic belonging to existing sessions. To ensure session information synchronization between the two
nodes, the data plane gives RTO packets priority over transit traffic.
Dynamics of RTOs
The Junos OS creates RTOs dynamically in memory. Some examples of dynamically created RTOs include session table entries
and IPsec security associations (SAs).
Chassis Cluster Interface Summary
The graphic summarizes all the cluster interfaces that we just discussed.
Connecting Clusters over a Layer 2 Network
In the past a chassis cluster had to be connected back-to-back, which required both nodes to be in the same physical room.
While this deployment works well for most situations, there is a growing need to have each node in a different physical location
even in different buildings or cities. To this end, the nodes of a chassis cluster can be connected, through the control and data
links, over a Layer 2 network for the fxp1 and fab interfaces. The swfab interfaces must be connected directly, with no
intermediate devices in between the cluster nodes. However, because of the sensitive nature of these links there are some
special considerations when doing so.
The latency between the two nodes must be less than 100 ms. If the latency is greater than 100 ms, control link heartbeats and
fabric probes might not arrive in time or might arrive out of sequence. In a situation in which liveliness messages are late or out
of order, cluster instability occurs. Failure to hold to these standards might result in a control plane failover or a disruption in
data plane traffic.
Due to the sensitivity of the data traveling across these links, the recommended bandwidth to be reserved for the path is 1 Gbps
for the control link and 1 Gbps for the fabric link. However, depending on the cluster configuration this requirement can be
relaxed. For example, if you deploy an active/passive cluster the bandwidth needed for the fabric link is considerably less than
1 Gbps, or if there is a low amount of connections per second for the cluster, the amount of bandwidth needed for the control
link is less than 1 Gbps. However, this does not take into account all possible failover scenarios which is why the
recommendation of 1 Gbps of bandwidth for the path is given.
The chassis cluster uses private IP and private media access control (MAC) addresses to communicate, and having other hosts
on the same network as the control link or the fabric link can cause instability issues with the other hosts or the chassis cluster.
This network segregation can be accomplished by putting the control link and the fabric link in their own virtual LANs (VLANs).
The goal of chassis clustering is to provide HA, this can be defeated by connecting the control and fabric links through the same
physical switch topology. In doing so a single point of failure can be created for both links. If this were to occur, a split brain
scenario might happen in which both nodes attempt to take primacy of all redundancy groups.
LAN Deployment
We recommend deploying two separate physical switch topologies. This recommendation ensures no single device, or link
failure, causes both the control and fabric links to go down at the same time which might cause a split brain condition. If any

other traffic resides on the switches we recommend to put the control and fabric link traffic in their own unique VLANs. This
technique allows the two nodes to communicate across the links undisturbed.
WAN Deployment
A Layer 2 WAN topology which connects the control and fabric links can be accomplished as long as the previous mentioned
requirements are fulfilled. To accomplish this goal it is recommended to have two WAN connections, one for control link traffic
and the other for fabric link traffic. This rule is not a strict requirement, and one WAN connection can be used, but you do run
the risk of a single point of failure in which both nodes enter a split brain condition.
The WAN service used to connect the two nodes of the cluster can be virtual private LAN services (VPLS) or a non-Ethernet
based Layer 2 technology, such as L2 virtual private networks (VPNs) or circuit cross-connect services.
Chassis Clustering and Ethernet Switching
You can now configure a chassis cluster to act as a Layer 2 Ethernet switch. The Junos OS supports this feature for all branch
SRX Series devices, except the SRX100, SRX110, and SRX210. When you configure the interfaces of a chassis cluster to
participate in Ethernet switching, you can only configure local interfaces to switch Ethernet traffic. That is, you cannot configure
reth interfaces with the family ethernet-switching statement. Layer 2 LAG interfaces are included in the local
interfaces criteria. However, the member interfaces of the LAG must be contained within one node and cannot span between
both nodes.
Note that Layer 3 interfaces, such as reths, can be configured on a chassis cluster that is performing Layer 2 Ethernet switching.
This ability improves the flexibility of a chassis cluster in which you can provide Layer 2 and Layer 3 access through the
SRX Series devices.
Adding Ethernet Switching to a Cluster
When preparing a chassis cluster for Layer 2 Ethernet switching, you must create and connect the swfab interfaces. If you
enable Ethernet switching-related features without first establishing the swfab connection, the behavior of the nodes might
become unpredictable. As mentioned earlier in this chapter, you must use switching-enabled interfaces that are specific to the
branch SRX platforms that are in the cluster.
Ethernet ports support various Layer 2 features such as Spanning Tree Protocols (STPs), DOT1X, LAGs, Internet Group
Management Protocol (IGMP), GARP VLAN Registration Protocol (GVRP), Link Layer Discovery Protocol (LLDP), and IGMP
snooping. Users can configure a Layer 2 VLAN domain with member ports from both the nodes and the Layer 2 switching
protocols on both the devices. These Layer 2 VLAN domains can take advantage of integrated routing and bridging (IRB) and
VLAN interfaces to facilitate Layer 3 routing.
The following output displays the configuration for the swfab interfaces. Remember that you can place additional physical
interfaces with the swfab interfaces to provide redundancy.
{primary:node0}
user@srx> show configuration interfaces | find swfab
swfab0 {
fabric-options {
member-interfaces {
ge-0/0/2;
}
}
}
swfab1 {
fabric-options {
member-interfaces {
ge-5/0/2;
}
}
}
...
Examining the Ethernet Switching Status
Use the show chassis cluster ethernet-switching status command to view the current status of the swfab
probes and to determine whether both nodes of the cluster are in a single Layer 2 Ethernet switching domain. If the output lists
the probe status as down, both nodes are in separate Layer 2 Ethernet switching domains.
Viewing the Status of the swfab Interfaces
The show chassis cluster ethernet-switching interfaces command displays the current state of the swfab
interfaces. At least one set of swfab interfaces must be up and functional, or the nodes of the cluster will be in separate Layer 2
Ethernet switching domains.
Examining the swfab Statistics
The show chassis cluster ethernet-switching statistics command displays the current probe state as well
as statistics on probes sent and received, and probe errors.
Monitoring Remote IP Addresses
Redundancy group IP address monitoring checks end-to-end connectivity and allows a redundancy group to fail over because of
the inability of a reth interface to reach a configured IP address. Redundancy groups on both devices in a cluster can be
configured to monitor specific IP addresses to determine whether an upstream device in the network is reachable. The
redundancy group can be configured such that if the monitored IP address becomes unreachable, the redundancy group will fail
over to its backup to maintain service. The primary difference between this monitoring feature and interface monitoring is that
IP address monitoring allows for failover when the interface is still up but the network device it is connected to is not reachable
for some reason. It might be possible under those circumstances for the other node in the cluster to route traffic around the
problem.
IP Address Monitoring Configuration Parameters
IP address monitoring works by sending out ICMP requests to the monitored address. These ICMP requests are sent from the
address that is specified in the secondary-ip-address statement. The secondary IP address that you use must be found
within the subnet of the reth interface through which the address is being monitored. Also of note is that if you are monitoring
multiple IP address through the same reth interface, you must specify the same secondary IP address.
These ping requests are sent every second by default. This value is configurable with the retry-interval statement. Then,
if the monitored address is unreachable for 5 ping requests (the default value of the retry-count), the address is marked as
unreachable. When the Junos OS marks a monitored address as unreachable, the weight value associated with that address is
counted against the global-threshold value. If the accumulated monitored address weight values surpass the
global-threshold value, the value specified by the global-weight statement is counted against the overall threshold
tolerance value of the RG, which initially is 255. If the overall threshold tolerance value of an RG is reached for a node of the
cluster that is primary for the RG, an RG failover occurs.
The configuration in the inset shows a global-threshold value of 120, and a global-weight value of 200. With this
configuration, both monitored IP address must become unreachable to reach the global-threshold value. If this situation
occurs, the value specified in the global-threshold is counted against 255 threshold tolerance for RG 1. However, unless
further monitoring is added, an RG failover can never occur. You can add interface monitoring to RG 1 that must have a weight
value of at least 55 to reach the threshold tolerance for RG 1.
Examining the State of the Monitored Addresses
The output in the inset shows the current status of the monitored addresses that were configured in the last inset. This output
shows the statistics for all the redundancy groups that are monitoring IP addresses for reachability. As you can see in the inset,
the 172.20.20.2 address is reachable on both nodes, whereas the 1.1.1.1 address is not. Recall from the previous page that
each monitored address had a weight of 60, and RG 1 has an IP monitoring global threshold value of 120. These factors mean
that the IP monitoring global weight value is not counted against the threshold value for RG 1.
The Reason field can give more detail on why the monitored address is not reachable. The following is a list of possible reasons
and what they mean.
No route to host: The router could not resolve the ARP, which is needed to send the ICMP packet to the host with
the monitored IP address.
No auxiliary IP found: The redundant Ethernet interface does not have an auxiliary IP address configured.
Reth child not up: A child interface of a redundant Ethernet interface is down.
Redundancy-group state unknown: Unable to obtain the state (primary, secondary, secondary-hold, disable) of a
redundancy group.
The following is a continuation of the list from the preceding page:
No reth child MAC address: Could not extract the MAC address of the redundant Ethernet child interface.
Secondary link not monitored: The secondary link may be down (the secondary child interface of a redundant
Ethernet interface is either down or nonfunctional).
Unknown: The IP address has just been configured and the router still does not know the status of this IP, or the
exact reason for the failure is not known.
IPsec Tunnels and Chassis Clusters
When an IPsec tunnel terminates within a chassis cluster it must end on one of the nodes in the cluster. Typically the anchor
point for a tunnel end point is the address of a reth interface. This virtual termination ensures that in a failover scenario the
backup node can assume control of the redundancy group in which the reth interface belongs. Alternatively, the loopback
interface can be used for IPsec tunnel termination if the members of the cluster are branch SRX Series devices. Using the
loopback interface for tunnel termination is not supported for the high end SRX Series devices in HA clusters.
The keys and session information are synchronized between the nodes which allows the backup node to take control of the
IPsec tunnel if a failover scenario happens. Failovers occur in a stateful manner which allows the IPsec and the Internet Key
Exchange (IKE) security associations to be preserved. The remote side of the tunnel is not aware of the failover condition and
continues to pass and receive traffic through the tunnel as if nothing has happened.
IPv6 Clustering Support
As of Junos OS Release 12.1R1.9, the feature support for IPv6 in a chassis cluster has greatly been expanded. Now SRX Series
devices running IPv6 can be deployed in an active/passive cluster and it can also be deployed in an active/active cluster. Reth

interfaces and local interfaces can be IPv6 enabled, and run dual stacked with IPv4 and IPv6 addresses enabled on the
interface at the same time. The address book can be populated with IPv4, IPv6, and DNS entries simultaneously, which allows
policies to call on these address book entries. IPsec site-to-site VPNs over IPv6 is currently not supported, however, support is
planned for a future Junos OS release.
State Synchronization for High End SRX Devices
The SPC placement in a chassis cluster is very important. If the SPCs in both nodes are not in the same slots in each node, or if
there are a differing number of SPCs in each node, then inter-chassis communication might be intermittent and problematic.
Having the equal number of SPCs, and the SPCs residing in the same slots in each node, allows each SPC to communicate with
its peer SPC.
When a traffic session or a service is handled by an SPC on the primary node, a session synchronize message, in the form of an
RTO, is sent through the fabric link to the peer Services Processing Unit (SPU) located on the backup node. This process occurs
for each SPC in the primary node which is handling a session or a service. Once the session synchronize messages reach the
peer SPU on the backup node, the peer SPU validates and creates the session on the backup node. It then informs the CP of the
new session or service. The CP is now responsible for maintaining the state of all sessions on the node.
Graceful Restart
With routing protocols, any service interruption requires that an affected router recalculate adjacencies with neighboring
routers, restore routing table entries, and update other protocol specific information. An unprotected restart of a router can
result in forwarding delays, route flapping, wait times stemming from protocol reconvergence, and dropped packets. The main
benefits of graceful restart are uninterrupted packet forwarding and temporary suppression of all routing protocol updates.
Graceful restart enables a router to pass through intermediate convergence states that are hidden from the rest of the network.
Most graceful restart implementations define two types of routersthe restarting router and the helper router. The restarting
router requires quick restoration of forwarding state information so it can resume the forwarding of traffic. The helper router
assists the restarting router in this process. Graceful restart configuration statements typically affect either the restarting router
or the helper router.
Graceful restart is enabled globally and affects every routing protocol. If it is undesirable for a protocol it must be turned off for
that protocol. It only takes one command to enable graceful restart for all supported protocols.
{primary:node0}[edit]
user@srx# set routing-options graceful-restart
Review Questions
Answers
1.
The control plane of a chassis cluster uses SPC ports on high-end systems and revenue ports on branch platforms and is named fxp1. The
data plane connects using physical ports named fab0 and fab1.
2.
The fab interface serves as the data plane link between nodes in a chassis cluster and transmits RTOs to replicate session state between the
two nodes.

3.
An RG is an abstract entity that manages the redundancy of a group of objects. The software creates RG0 when a chassis cluster forms to
manage primacy of REs. The software uses RGx to manage primacy of reth interfaces.
4.
The default threshold for interface monitoring is 255.
Chapter 10: High Availability Clustering Implementation

High availability (HA) clustering and its functionality;
Chassis cluster components;
Chassis cluster operation;
Chassis cluster configuration; and
Chassis cluster monitoring.
Cluster Operation: Forming a Cluster
The first chassis in a cluster forms a cluster upon booting up. It transitions from the blank state to the primary state.
Cluster Operation: Joining a Cluster
A chassis can join an existing cluster. The RG0 of the joining chassis transitions from the blank state to the secondary state.
RGx transitions from the blank state to either the primary state or the secondary state based on a combination of priorities and
High Availability Clustering Implementation Chapter 101

preempt configurations. The join operation causes the joining chassis to perform configuration synchronization as well. A join
operation might cause the existing cluster node to change its RGx states from primary to secondary.
Cluster Operation: Leaving a Cluster
A leave action happens when a node chassis reboots or powers off. This leave action can trigger RG state changes from
secondary to primary in another cluster node.
Cluster Operation: Splitting a Cluster
The Junos OS offers automatic protection from split scenarios by disabling the secondary node if either the control link or the
fabric link suffers a loss of keepalives or heartbeat messages. You must reboot the disabled node to have it rejoin the cluster.
However, if the Junos OS detects a failure on both links simultaneously, such as in the case of a system failure, both devices
become primary nodes.
Chapter 102 High Availability Clustering Implementation
Cluster Operation: Merging a Cluster
A merge action happens when a split cluster regains connectivity. The merged cluster can cause RG state transitions from
primary to secondary.
One Node Handling Transit Traffic
The graphic illustrates the packet flow in active-passive mode for the data plane. In this case, Node 0 is the primary node, and
Node 1 is the secondary node.
Both Nodes Handling Transit Traffic
In active-active mode for the data plane, two nodes handle transit traffic. The graphic illustrates the packet flow in which ingress
and egress interfaces are on different devices of a cluster. The node containing the egress interface for the first flow in a
session always acts as the host of the session. In this case, the flows active session is on Node 1, and the flows backup
session is on Node 0.
At this time, Junos security platforms support active-active mode for the data plane only. The control plane always acts in an
active-passive fashion, with the secondary node providing redundancy to the primary node.
Active/Active Clustering
Although active/active clustering might seem like a complex topic it is only active/passive clustering done twice. In a typical
active/passive cluster configuration, node 0 is primary and node 1 is secondary for all redundancy groups, and node 1 is ready
to take over in a failover situation. In an active/active cluster configuration node 0 is primary for some redundancy groups and
node 1 is primary for other redundancy groups. In the diagram in the graphic, node 0 is primary for redundancy group 1 and
node 1 is primary for redundancy group 2. Node 0 is secondary for redundancy group 2 and is ready to take primacy if a failover
condition occurs with node 1. Node 1 is secondary for redundancy group 1 and is ready to take primacy if a failover condition
occurs with node 0.
Data path, or Z path, forwarding occurs during an active/active cluster configuration. Traffic traverses the data link between the
two nodes which might introduce a bottle neck if the interface type used for the data link has too little bandwidth available.
Consider using the largest available interface for the data link. Also, the use of dual data links might help mitigate this possible
issue.
Many administrators use one redundancy group which is primary on the backup node as means of employing a health check for
the backup node. This practice ensures that the backup node is functioning and is ready to take over in the event of a failover
scenario.
Connecting the Two Devices

Ensure that you interconnect two Junos security platforms of the same model, with SPCs inserted in identical slots (on a
high-end platform), as follows:
Connect the ports for use as the control link. On high-end platforms, use the SPC port with the same number
as the RE slot. On branch platforms, use the appropriate revenue port specific to the model of device.
Connect the Ethernet interfaces of the two nodes to create the fabric link (fab interface).
Configuring Control Ports

For high-end platforms, enable the SPC control plane ports in the configuration and commit the configuration.
Enabling Clustering
Enabling chassis clustering involves setting a cluster-id id and node id on each chassis in the cluster. The
cluster-id value is the same on both nodes. To activate clustering, once you set the cluster-id id and the node id,
you must reboot the node designated as the primary device first, then reboot the desired secondary node.
Enabling the Chassis Cluster
The inset illustrates the configuration required to enable the SPC control plane ports for high-end security platforms.
It also displays the syntax of a command that is necessary to set up the cluster-id id and node id. Note that you
perform this command in operational mode and the mandatory reboot is available as part of the command.
Enabling the Chassis Cluster on the Second Node
Because the second node inherits the configuration associated with the primary node, no control port configuration is
necessary. The inset illustrates the operational mode command required to add the second node to the chassis cluster.
Cluster Configuration Steps
Once you reboot a node of a cluster, you are ready to configure other cluster parameters. The inset lists the configuration steps
you must follow to accomplish cluster configuration.
Configuring the Management Interface
You configure management access to the cluster by defining a unique hostname for each node and assigning a unique IP
address for the fxp0 interface on each node. Note that the configured group names must be node0 and node1. You must apply
the configured groups using the apply-groups configuration stanza, as illustrated in the inset.
Configuring Fabric Interfaces
You configure the fab interface between the two nodes using the syntax illustrated in the inset. The member interface for fab0 is
an Ethernet interface on Node 0, and the member interface for fab1 is an Ethernet interface on Node 1. Both fab interfaces
must be of the same media type.
Configuring a Redundancy Group
The inset illustrates the syntax necessary for configuring an RG. You perform the configuration under the [edit chassis
cluster] configuration stanza. The configuration includes specifying the following:
The node priorities (the higher number takes precedence);
The number of gratuitous Address Resolution Protocol (ARP) requests that an interface can send to notify other
network devices of its presence after an RG to which it belongs fails over;
Weights to the monitored interfaces; and
An optional preemption, which allows a node with a better priority to initiate a failover to become primary for the configured RG.
Configuring a Redundant Ethernet Interface
To create a reth interface, you configure the two physical interfaces independently. You configure the rest of the parameters
pertaining to reth interfaces at the interfaces reth number configuration stanza. Once you commit the configuration, all
child interfaces of a reth interface inherit those parameters. Because reth interfaces are pseudo-interfaces, you must define the
number of reth interfaces in a cluster by configuring reth-count.
Configuring Cluster Failover Parameters

The following are the cluster failover parameters that you can
configure, should you choose to alter their default values:
heartbeat-interval: Interval or duration when

all nodes in the cluster receive the heartbeat
message broadcast; and
heartbeat-threshold: Number of missed

heartbeats that must be exceeded to declare the
cluster node dead.
Disabling a Chassis Cluster
The inset illustrates the operational mode command used to remove a Junos security platform from a cluster. Enter it first on the
primary node and then on the secondary node. Because it will have its configuration synced to the primary node configuration,
the secondary node will also need its interfaces renamed.
Example: Network Diagram Prior to Issuing the Cluster-Forming Command
Consider the example on the graphic. Two high-end security platforms, host1 and host2, interconnect together using Gigabit
Ethernet interfaces as well as SPC control ports in Slot 3. We connected both nodes to the server site using the ge-0/0/0
interface and to the Internet using the ge-1/0/0 interface.
Forming a Cluster
To form a cluster using high-end security platforms, you must configure the control ports on the node. Because the secondary
nodes configuration will be synchronized with the primary nodes configuration, you are only required to configure control ports
on the node designated as primary. Make sure to commit the configuration.

For all Junos security platforms, use the operational mode commands shown on the graphic to set the cluster identification
number and node identification number. The operational mode command also allows you to perform the mandatory reboot on
each device. Remember to perform this operation first on the node designated to be the primary node and then on the node
designated as secondary.
Example: Network Diagram After Issuing the Cluster-Forming Command
After you reboot the SRX Series Services Gateways, they form a cluster. The cluster formation results in interface names
changing, as illustrated on the graphic.
Cluster Status Check
Use the show commands illustrated in the inset to display the status of the chassis cluster and the cluster interfaces.
Configuring the Management Interface
Next, configure the management interface using the groups and apply-groups configuration stanzas, as illustrated in the
inset.
Configuring the Fabric Interfaces
In the example in the inset, the fab0 and fab1 interfaces of the cluster use ge-0/0/2 and ge-12/0/2 physical interfaces. The
inset depicts the configuration of the fab0 and fab1 interfaces as well as the resulting status. Note that the fab interfaces now
show a link status of up.
Configuring a Redundancy Group

The inset illustrates the configuration of RG0 and RG1. Node 0
is primary because its priority is higher than Node 1s priority.
RG1 monitors the ge-0/0/0 interface connected to the server
site. If the ge-0/0/0 interface becomes unavailable, RG1 fails
over to Node 1 and the ge-12/0/0 interface.
Viewing Redundancy Groups
To view the RG status, use the show chassis cluster status command. This command allows you to see which nodes
are primary and secondary for RG0 and RG1. You can also verify that you enabled preemption or if a manual failover is in effect.
We discuss manual failovers on a subsequent page.
Configuring reth Interfaces
In the example in the inset, one reth interface is shownreth1and it belongs to RG1. Interfaces ge-0/0/0 and ge-12/0/0
constitute the reth1 interface. The total number of reth interfaces that the cluster will recognize is two (based on a
reth-count value).
Configuring Cluster Failover Parameters

According to the configuration in the inset, heartbeat messages
between the nodes in the cluster happen every 1200
milliseconds. In addition, the system assumes the node is dead if
the number of missed heartbeats exceeds five.
Monitoring Cluster Statistics
Use the show chassis cluster statistics command to display chassis cluster counters. The counters are useful for
troubleshooting and verifying proper operation.
Manual Failover
You can initiate a failover manually with the request command shown in the inset. A manual failover bumps up the priority of
the redundancy group for that member to 255. Be careful with manual failovers. An RG0 failover implies an RE failover. An RE
failover kills all processes running on the primary node and spawns them on the new primary RE, which can result in a loss of
state, such as routing state.
Resetting a Manual Failover
After a manual failover, the new primary node continues in that role until a reset or failback occurs. If a failback occurs, the
manual failover is lost, and the software bases state election on priority and preempt settings. A failback in manual failover
mode can occur if the primary node fails or if the threshold of an RG reaches zero.
Chassis Cluster Logging
Use the show log jsrpd command to view chassis cluster events. The jsrpd process is the process associated with
managing chassis cluster events. For some chassis cluster events, the software dynamically populates this log.
Traceoptions
You can also configure traceoptions for chassis cluster operations. You
can set flags for many events.
{primary:node0}[edit]
user@srx# set chassis cluster traceoptions flag ?
Trace all events
all
cli
Trace CLI events
configuration
Trace configuration events
eventlib
Trace event library events
fsm
Trace finite state machine events
heartbeat
Trace JSRPD heartbeats
init
Trace initialization events
interface
Trace interface related events
routing-socket
Trace routing socket events
socket
Trace socket events
uspipc
Trace USP IPC events
Review Questions
Answers
1.
An chassis cluster in active/active mode has transit traffic passing through both nodes of the cluster all of the time. Whereas a chassis
cluster in active/passive mode only has transit traffic passing through the primary node while the backup node waits in hot standby.
2.
The jsrpd log file contains events that relate to chassis clustering.

3.
You can use the show interface terse | match reth command to view the status of the reth interface and its child
interfaces.
Lab 8: Implementing High Availability Techniques

Please complete Lab 8.

Jncis Sec P1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jncis Sec P1

Uploaded by

Copyright:

Available Formats

JNCIS-SEC Study GuidePart 1

Worldwide Education Services

This document is produced by Juniper Networks, Inc.

Introduction to Junos Security Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Firewall User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

SCREEN Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Introduction to Intrusion Detection and Prevention . . . . . . . . . . . . . . . . . . . . 8-1

High Availability Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

High Availability Clustering Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .10-1

Introduction to Junos Security Platforms

Firewall User Authentication

Network Address Translation

Introduction to Intrusion Detection and Prevention

High Availability Clustering

Chapter 10: High Availability Clustering Implementation

Most of what you read in the Lab Guide

Exiting configuration mode

GUI text elements:

Select File > Open, and then click

Input Text Versus Output Text

View configuration history by clicking

Text that you must enter.

lab@San_Jose> show route

Defined and Undefined Syntax Variables

Text where variable value is

Click my-peers in the dialog.

Text where the variables value

Type set policy policy-name.

About This Publication

Juniper Networks Support

JNCIS-SEC Study GuidePart 1

Chapter 1: Introduction to Junos Security

Traditional routing and security implementations;

Current trends in internetworking;

The Junos operating system for the SRX Series; and

Logical packet flow through SRX Series devices.

Built to Forward Packets

Packet Processing Is Stateless

Separate Broadcast Domains and Provide WAN Connectivity

2012 Juniper Networks, Inc. All rights reserved.

Introduction to Junos Security Chapter 11

JNCIS-SEC Study GuidePart 1

Layer 3 Packet Forwarding

Layer 3 Packet Forwarding

Typical Treatment of Security

Typical Router Positioning

2012 Juniper Networks, Inc. All rights reserved.

JNCIS-SEC Study GuidePart 1

Adding Security to the Network

Requirements for Firewall Devices

Firewall: Stateful Packet Processing

Introduction to Junos Security Chapter 13

JNCIS-SEC Study GuidePart 1

Firewall: NAT and PAT

Firewall: Virtual Private Networks

Chapter 14 Introduction to Junos Security

2012 Juniper Networks, Inc. All rights reserved.

JNCIS-SEC Study GuidePart 1

Junos Security Platforms Versus a Traditional Router

2012 Juniper Networks, Inc. All rights reserved.