JUNIPER SRX Security-Policies

Junos® OS
Security Policies User Guide for Security

Devices
Published
2022-07-05
ii
Juniper Networks, Inc.

1133 Innovation Way
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc.
in the United States and other countries. All other trademarks, service marks, registered marks, or registered service
marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right
to change, modify, transfer, or otherwise revise this publication without notice.
Junos® OS Security Policies User Guide for Security Devices

Copyright © 2022 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related
limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use
with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License
Agreement ("EULA") posted at https://support.juniper.net/support/eula/. By downloading, installing or using such
software, you agree to the terms and conditions of that EULA.
iii
Table of Contents
About This Guide | xviii
1 Overview
Security Basics Overview | 2
Security Policies Overview | 2
2 Security Zones
Security Zones | 7
Security Zones Overview | 7
Example: Creating Security Zones | 9
Requirements | 10
Overview | 10
Configuration | 10
Verification | 12
Supported System Services for Host Inbound Traffic | 13
Understanding How to Control Inbound Traffic Based on Traffic Types | 14
Example: Controlling Inbound Traffic Based on Traffic Types | 15
Requirements | 15
Overview | 15
Configuration | 15
Verification | 18
Understanding How to Control Inbound Traffic Based on Protocols | 19
Example: Controlling Inbound Traffic Based on Protocols | 20
Requirements | 20
Overview | 20
Configuration | 21
Verification | 22
Example: Configuring the TCP-Reset Parameter | 23
Requirements | 23
iv
Overview | 23
Configuration | 23
Verification | 24
3 Address Books and Address Sets

Address Books and Address Sets | 26
Understanding Address Books | 26
Understanding Global Address Books | 28
Understanding Address Sets | 29
Limitations of Addresses and Address Sets in a Security Policy | 29
Configuring Addresses and Address Sets | 30
Example: Configuring Address Books and Address Sets | 36
Requirements | 36
Overview | 37
Configuration | 39
Verification | 42
Excluding Addresses from Policies | 44
Example: Excluding Addresses from Policies | 45
Requirements | 45
Overview | 46
Configuration | 46
Verification | 50
4 Security Policy Applications and Application Sets

Security Policy Applications and Application Sets | 54
Security Policy Applications Overview | 54
Security Policy Application Sets Overview | 55
Example: Configuring Security Policy Applications and Application Sets | 55
Requirements | 56
Overview | 56
Configuration | 57
Verification | 57
v
Understanding Policy Application Timeout Configuration and Lookup | 58
Understanding Policy Application Timeouts Contingencies | 59
Example: Setting a Policy Application Timeout | 59
Requirements | 60
Overview | 60
Configuration | 60
Verification | 61
Predefined Policy Applications | 61
Understanding Internet-Related Predefined Policy Applications | 62
Understanding Microsoft Predefined Policy Applications | 64
Understanding Dynamic Routing Protocols Predefined Policy Applications | 66
Understanding Streaming Video Predefined Policy Applications | 67
Understanding Sun RPC Predefined Policy Applications | 68
Understanding Security and Tunnel Predefined Policy Applications | 69
Understanding IP-Related Predefined Policy Applications | 70
Understanding Instant Messaging Predefined Policy Applications | 70
Understanding Management Predefined Policy Applications | 71
Understanding Mail Predefined Policy Applications | 73
Understanding UNIX Predefined Policy Applications | 74
Understanding Miscellaneous Predefined Policy Applications | 74
Understanding ICMP Predefined Policy Applications | 75
Example: Defining a Custom ICMP Application | 82
Requirements | 82
Overview | 82
Configuration | 83
Verification | 84
Custom Policy Applications | 85
Understanding Custom Policy Applications | 85

vi
Custom Application Mappings | 85
Example: Adding and Modifying Custom Policy Applications | 86
Requirements | 86
Overview | 86
Configuration | 87
Verification | 88
Example: Configuring Custom Policy Application Term Options | 89
Requirements | 90
Overview | 90
Configuration | 90
Verification | 93
5 Security Policies
Configuring Security Policies | 96
Understanding Security Policy Elements | 96
Understanding Security Policy Rules | 97
Understanding Security Policies for Self Traffic | 101
Security Policies Configuration Overview | 102
Best Practices for Defining Policies on SRX Series Devices | 103
Configuring Policies Using the Firewall Wizard | 106
Example: Configuring a Security Policy to Permit or Deny All Traffic | 107
Requirements | 107
Overview | 107
Configuration | 109
Verification | 112
Example: Configuring a Security Policy to Permit or Deny Selected Traffic | 113
Requirements | 113
Overview | 113
Configuration | 115
Verification | 118
Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic | 119
vii
Requirements | 119
Overview | 120
Configuration | 120
Verification | 123
Example: Configuring a Security Policy to Redirect Traffic Logs to an External System Log
Server | 124
Requirements | 124
Overview | 124
Configuration | 125
Verification | 128
TAP Mode for Security Zones and Policies | 128
Understanding TAP Mode Support for Security Zones and Policies | 129
Example: Configuring Security Zones and Policies in TAP mode | 129
Dynamic Address Groups in Security Policies | 134
Configure Security Policies for VXLAN | 141
Requirements | 141
Overview | 142
Configuration | 143
Verification | 147
Unified Security Policies | 153
Unified Policies Overview | 154
Unified Policies Configuration Overview | 155
Example: Configure a Unified Policy Using a Redirect Message Profile | 164
Requirements | 164
Overview | 164
Configuration | 165
Verification | 167
Configure a URL Category with Unified Policies | 170
Understanding URL Category with Unified Policies | 170
Example: Configuring a Unified Policy Using URL Category | 171
Configure Applications in Unified Policies | 176

viii
Applications in Unified Policies | 176
Example: Configure a Unified Policy Using Dynamic Applications | 176
Configure Micro-Applications in Unified Policies | 181
Global Security Policies | 183
Global Policy Overview | 184
Example: Configuring a Global Policy with No Zone Restrictions | 186
Requirements | 187
Overview | 187
Configuration | 188
Verification | 191
Example: Configuring a Global Policy with Multiple Zones | 192
Requirements | 192
Overview | 192
Configuration | 193
Verification | 195
User Role Firewall Security Policies | 195
Understanding User Role Firewalls | 196
User Role Retrieval and the Policy Lookup Process | 197
Understanding the User Identification Table | 199
Obtaining Username and Role Information Through Firewall Authentication | 206
Configuring a User Role Firewall For Captive Portal Redirection | 208
Example: Configuring a User Role Firewall on an SRX Series Device | 209
Requirements | 210
Overview | 210
Configuration | 212
Configuring Resource Policies Using UAC | 219
Reordering Security Policies | 222
Understanding Security Policy Ordering | 222
Example: Reordering Security Policies | 224
Requirements | 225
ix
Overview | 225
Configuration | 225
Verification | 226
Scheduling Security Policies | 226
Security Policy Schedulers Overview | 226
Example: Configuring Schedulers for a Daily Schedule Excluding One Day | 227
Requirements | 228
Overview | 228
Configuration | 228
Verification | 231
Verifying Scheduled Policies | 232
Threat Profiling Support in Security Policy | 233
Configuring Security Policies for a VRF Routing Instance | 234
Overview | 235
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from MPLS
Network to an IP Network | 238
Requirements | 238
Overview | 238
Configuration | 239
Example: Configuring a Security Policy to Permit VRF-Based Traffic from an IP Network to an

MPLS Network | 244
Requirements | 244
Overview | 244
Configuration | 245
Example: Configuring a Security Policy to Permit VRF-Based Traffic from an MPLS Network to
an MPLS Network over GRE without NAT | 250
Requirements | 250
Overview | 250
Configuration | 251
Example: Configuring Security Policies Using VRF Routing Instances in an MPLS Network | 256
x
Requirements | 257
Overview | 257
MPLS Network to Private IP Network | 257
Global IP Network to an MPLS Network | 260
Configuring Security Policies Using VRF Group | 267
Overview | 267
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from MPLS
Network to an IP Network using Source VRF Group | 269
Requirements | 269
Overview | 269
Configuration | 270
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from an IP Network
to MPLS Network using Destination VRF Group | 274
Requirements | 275
Overview | 275
Configuration | 276
Managing Overlapping VPN using VRF group | 280
Monitoring and Troubleshooting Security Policies | 281
Understanding Security Alarms | 281
Example: Generating a Security Alarm in Response to Policy Violations | 282
Requirements | 282
Overview | 283
Configuration | 283
Verification | 285
Matching Security Policies | 285
Tracking Policy Hit Counts | 287
Checking Memory Usage on SRX Series Devices | 287
Monitoring Security Policy Statistics | 289
Verifying Shadow Policies | 290
Verifying All Shadow Policies | 290
Verifying a Policy Shadows One or More Policies | 291

xi
Verifying a Policy Is Shadowed by One or More Policies | 292
Troubleshooting Security Policies | 293
Synchronizing Policies Between Routing Engine and Packet Forwarding Engine | 293
Checking a Security Policy Commit Failure | 295
Verifying a Security Policy Commit | 295
Debugging Policy Lookup | 296
High Availability (HA) Synchronization of Address Name Resolving Cache | 297
6 Configuration Statements
address (Security Address Book) | 304
address-book | 306
address-set | 308
alarms (Security) | 310
alarm-threshold | 312
alarm-without-drop | 314
application (Applications) | 315
application (Security Alarms) | 319
application (Security Policies) | 321
application-protocol (Applications) | 323
application-services (Security Policies) | 326
application-tracking (Security Zones) | 330
application-traffic-control (Application Services) | 331
attach | 333
audible (Security Alarms) | 335
authentication (Security Alarms) | 336
captive-portal (Services UAC Policy) | 338
count (Security Policies) | 340

xii
default-policy | 341
deny (Security Policies) | 343
description (Applications) | 344
description (Security Address Book) | 346
description (Security Zone) | 347
destination-address (Security Policies) | 349
destination-address (Security Policies Flag) | 351
destination-address-excluded | 353
destination-ip (Security Alarms) | 354
destination-port (Applications) | 356
dns-cache | 362
dns-proxy | 364
dynamic-address | 366
dynamic-application (Security) | 368
dynamic-application (Security Policies) | 370
dynamic-dns | 372
exclude (Schedulers) | 374
feed-server | 376
firewall-authentication (Security Policies) | 379
forward-only (DNS) | 381
from-zone (Security Policies) | 383
from-zone (Security Policies Global) | 387
functional-zone | 389
global (Security Policies) | 391
host-inbound-traffic | 394
xiii
icmp-code (Applications) | 396
icmp-type (Applications) | 398
inactivity-timeout (Applications) | 399
interfaces (Security Zones) | 401
initial-tcp-mss | 403
ipsec-group-vpn (Security Policies) | 404
ipsec-vpn (Security Policies) | 406
log (Security Policies) | 408
management (Security Zones) | 410
match (Security Policies) | 412
match (Security Policies Global) | 414
unified-policy max-lookups | 417
no-policy-cold-synchronization | 418
pair-policy | 420
pass-through | 421
permit (Security Policies) | 424
policies | 427
policy (Security Alarms) | 437
policy (Security Policies) | 439
policy-match | 443
policy-rematch | 445
policy-stats | 447
potential-violation | 448
pre-id-default-policy | 452
profile(dynamic-application) | 455
xiv
protocol (Applications) | 458
protocols (Security Zones Host Inbound Traffic) | 460
protocols (Security Zones Interfaces) | 463
range-address | 465
redirect-wx (Application Services) | 467
reject (Security) | 468
report-skip | 470
reverse-tcp-mss | 472
rpc-program-number (Applications) | 474
scheduler (Security Policies) | 475
scheduler-name | 478
schedulers (Security Policies) | 479
screen (Security Zones) | 481
secure-neighbor-discovery | 482
security-intelligence (security policies) | 484
security-zone | 486
sequence-check-required | 489
services-offload (Security) | 490
session-close | 492
session-init | 493
session-scan | 495
simple-mail-client-service | 496
source-address (Security Policies) | 498
source-address-excluded | 500
source-identity | 501
xv
source-ip (Security Alarms) | 504
source-port (Applications) | 506
ssl-proxy (Application Services) | 507
ssl-termination-profile | 509
start-date | 510
start-time (Schedulers) | 512
stop-date | 514
stop-time | 515
syn-check-required | 517
system-services (Security Zones Host Inbound Traffic) | 519
system-services (Security Zones Interfaces) | 522
tcp-options (Security Policies) | 525
tcp-rst | 528
term (Applications) | 529
then (Security Policies) | 531
threshold-logging-interval | 534
to-zone (Security Policies) | 536
to-zone (Security Policies Global) | 539
traceoptions (dynamic-address) | 541
traceoptions (dynamic-application) | 543
traceoptions (Security Policies) | 546
traceoptions (Security User Identification) | 549
traceoptions (System Services DNS) | 551
tunnel (Security Policies) | 555
tunnel-inspection | 556
xvi
uac-policy (Application Services) | 558
unidirectional-session-refreshing | 560
unified-policy-explicit-match | 561
user-firewall | 563
user-identification | 565
utm-policy | 567
uuid (Applications) | 570
vrrp | 571
web-authentication | 573
web-redirect | 575
zones | 577
7 Operational Commands
clear security alarms | 583
clear security policies hit-count | 587
clear security policies statistics | 589
clear system services dns dns-proxy | 590
request security policies check | 592
request security policies resync | 595
request security user-identification local-authorization-table add | 598
request security user-identification local-authentication-table delete | 601
show security alarms | 603
show security firewall-authentication users address | 609
show security firewall-authentication users auth-type | 614
show security flow session application | 617
show security match-policies | 623

xvii
show security policies | 633
show security policies checksum | 655
show security policies hit-count | 658
show security policies information | 665
show security policies unknown-source-identity | 674
show security policies zone-context | 676
show security policy-report | 679
show security shadow-policies | 684
show security user-identification local-authentication-table | 687
show security user-identification role-provision all | 691
show security user-identification source-identity-provision all | 693
show security user-identification user-provision all | 695
show security zones | 696
show security zones type | 706
show system services dns dns-proxy | 711
show system services dynamic-dns | 715

xviii
About This Guide
Use this guide to configure security zones, address books and address sets, security policy applications
and application sets, and security policies in Junos OS on the SRX Series devices.
1 CHAPTER
Overview

2
Security Basics Overview
This guide provides information about the security basics used to configure features for security devices.
• A security zone is a collection of one or more network segments requiring the regulation of inbound
and outbound traffic through policies. Security zones are logical entities to which one or more
interfaces are bound. With many types of Juniper Networks devices, you can define multiple security
zones, the exact number of which you determine based on your network needs.
• An address book is a collection of addresses and address sets. Junos OS allows you to configure
multiple address books. Address books are like components, or building blocks, that are referenced in
other configurations such as security policies or NAT. You can add addresses to address books or use
the predefined addresses available to each address book by default.
• An application set is a group of applications. Junos OS simplifies the process by allowing you to
manage a small number of application sets, rather than a large number of individual application
entries. The application (or application set) is referred to by security policies as match criteria for
packets initiating sessions.
• A security policy is a stateful firewall policy that provides a set of tools to network administrators,
enabling them to implement network security for their organizations. Security policies enforce rules
for transit traffic, in terms of what traffic can pass through the firewall, and the actions that need to
take place on traffic as it passes through the firewall.
RELATED DOCUMENTATION
Getting Started Guide for Junos OS
Security Policies Overview
To secure their business, organizations must control access to their LAN and their resources. Security
policies are commonly used for this purpose. Secure access is required both within the company across
the LAN and in its interactions with external networks such as the Internet. Junos OS provides powerful
network security features through its stateful firewall, application firewall, and user identity firewall. All
three types of firewall enforcement are implemented through security policies. The stateful firewall
policy syntax is widened to include additional tuples for the application firewall and the user identity
firewall.
3
In a Junos OS stateful firewall, the security policies enforce rules for transit traffic, in terms of what
traffic can pass through the firewall, and the actions that need to take place on traffic as it passes
through the firewall. From the perspective of security policies, the traffic enters one security zone and
exits 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.
A security policy, which can be configured from the user interface, controls the traffic flow from one
zone to another zone by defining the kind(s) of traffic permitted from specified IP sources to specified IP
destinations at scheduled times.
Policies allow you to deny, permit, reject (deny and send a TCP RST or ICMP port unreachable message
to the source host), encrypt and decrypt, authenticate, prioritize, schedule, filter, and monitor the traffic
attempting to cross from one security zone to another. You decide which users and what data can enter
and exit, and when and where they can go.
NOTE: For an SRX Series device that supports virtual systems, policies set in the root system do
not affect policies set in virtual systems.
An SRX Series device secures a network by inspecting, and then allowing or denying, all connection
attempts that require passage from one security zone to another.
Logging capability can also be enabled with security policies during session initialization (session-init) or
session close (session-close) stage.
• To view logs from denied connections, enable log on session-init.
• To log sessions after their conclusion/tear-down, enable log on session-close.
NOTE: Session log is enabled at real time in the flow code which impacts the user performance.
If both session-close and session-init are enabled, performance is further degraded as compared to
enabling session-init only.
For SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices, a factory-default security
policy is provided that:
• Allows all traffic from the trust zone to the untrust zone.
• Allows all traffic between trusted zones, that is from the trust zone to intrazone trusted zones.
• Denies all traffic from the untrust zone to the trust zone.
4
Through the creation of policies, you can control the traffic flow from zone to zone by defining the kinds
of traffic permitted to pass from specified sources to specified destinations at scheduled times.
At the broadest level, you can allow all kinds of traffic from any source in one zone to any destination in
all other zones without any scheduling restrictions. At the narrowest level, you can create a policy that
allows only one kind of traffic between a specified host in one zone and another specified host in
another zone during a scheduled interval of time. See Figure 1 on page 4.
Figure 1: Security Policy
Every time a packet attempts to pass from one zone to another or between two interfaces bound to the
same zone, the device checks for a policy that permits such traffic (see "Understanding Security Zones"
on page 7 and "Example: Configuring Security Policy Applications and Application Sets" on page 55).
To allow traffic to pass from one security zone to another—for example, from zone A to zone B—you
must configure a policy that permits zone A to send traffic to zone B. To allow traffic to flow the other
way, you must configure another policy permitting traffic from zone B to zone A.
To allow data traffic to pass between zones, you must configure firewall policies.
5

2 CHAPTER
Security Zones
Security Zones | 7
7
Security Zones
IN THIS SECTION
Example: Creating Security Zones | 9
Example: Controlling Inbound Traffic Based on Traffic Types | 15
Example: Controlling Inbound Traffic Based on Protocols | 20
A security zone is a collection of one or more network segments requiring the regulation of inbound and
outbound traffic through policies. Security zones are logical entities to which one or more interfaces are
bound. You can define multiple security zones, the exact number of which you determine based on your
network needs.
Security Zones Overview
IN THIS SECTION
Understanding Security Zone Interfaces | 8
Understanding Functional Zones | 8
Understanding Security Zones | 9
Interfaces act as a doorway through which traffic enters and exits a Juniper Networks device. Many
interfaces can share exactly the same security requirements; however, different interfaces can also have
different security requirements for inbound and outbound data packets. Interfaces with identical
security requirements can be grouped together into a single security zone.
8
A security zone is a collection of one or more network segments requiring the regulation of inbound and
outbound traffic through policies.
Security zones are logical entities to which one or more interfaces are bound. With many types of
Juniper Networks devices, you can define multiple security zones, the exact number of which you
determine based on your network needs.
On a single device, you can configure multiple security zones, dividing the network into segments to
which you can apply various security options to satisfy the needs of each segment. At a minimum, you
must define two security zones, basically to protect one area of the network from the other. On some
security platforms, you can define many security zones, bringing finer granularity to your network
security design—and without deploying multiple security appliances to do so.
From the perspective of security policies, traffic enters into one security zone and goes out on another
security zone. This combination of a from-zone and a to-zone is defined as a context. Each context contains
an ordered list of policies. For more information on policies, see "Security Policies Overview" on page 2.
This topic includes the following sections:
Understanding Security Zone Interfaces
An interface for a security zone can be thought of as a doorway through which TCP/IP traffic can pass
between that zone and any other zone.
Through the policies you define, you can permit traffic between zones to flow in one direction or in
both. With the routes that you define, you specify the interfaces that traffic from one zone to another
must use. Because you can bind multiple interfaces to a zone, the routes you chart are important for
directing traffic to the interfaces of your choice.
An interface can be configured with an IPv4 address, IPv6 address, or both.
Understanding Functional Zones
A functional zone is used for special purposes, like management interfaces. Currently, only the
management (MGT) zone is supported. Management zones have the following properties:
• Management zones host management interfaces.
• Traffic entering management zones does not match policies; therefore, traffic cannot transit out of
any other interface if it was received in the management interface.
• Management zones can only be used for dedicated management interfaces.

9
Understanding Security Zones
Security zones are the building blocks for policies; they are logical entities to which one or more
interfaces are bound. Security zones provide a means of distinguishing groups of hosts (user systems
and other hosts, such as servers) and their resources from one another in order to apply different
security measures to them.
Security zones have the following properties:
• Policies—Active security policies that enforce rules for the transit traffic, in terms of what traffic can
pass through the firewall, and the actions that need to take place on the traffic as it passes through
the firewall. For more information, see "Security Policies Overview" on page 2.
• Screens—A Juniper Networks stateful firewall secures a network by inspecting, and then allowing or
denying, all connection attempts that require passage from one security zone to another. For every
security zone, you can enable a set of predefined screen options that detect and block various kinds
of traffic that the device determines as potentially harmful. For more information, see
Reconnaissance Deterrence Overview.
• Address books—IP addresses and address sets that make up an address book to identify its members
so that you can apply policies to them. Address book entries can include any combination of IPv4
addresses, IPv6 addresses, and Domain Name System (DNS) names. For more information, see
"Example: Configuring Address Books and Address Sets" on page 36.
• TCP-RST—When this feature is enabled, the system sends a TCP segment with the RESET flag set
when traffic arrives that does not match an existing session and does not have the SYNchronize flag
set.
• Interfaces—List of interfaces in the zone.
Security zones have the following preconfigured zone:
• Trust zone—Available only in the factory configuration and is used for initial connection to the
device. After you commit a configuration, the trust zone can be overridden.
Example: Creating Security Zones
IN THIS SECTION
Requirements | 10
Overview | 10
10
Configuration | 10
Verification | 12
This example shows how to configure zones and assign interfaces to them. When you configure a
security zone, you can specify many of its parameters at the same time.
Requirements
Before you begin, configure network interfaces. See the Interfaces User Guide for Security Devices.
Overview
An interface for a security zone can be thought of as a doorway through which TCP/IP traffic can pass
between that zone and any other zone.
NOTE: By default, interfaces are in the null zone. The interfaces will not pass traffic until they
have been assigned to a zone.
NOTE: You can configure 2000 interfaces within a security zone on SRX3400, SRX3600,
SRX4600, SRX5400, SRX5600, or SRX5800 devices, depending on the Junos OS release in your
installation.
Configuration
IN THIS SECTION
Procedure | 11
11
Procedure
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any
line breaks, change any details necessary to match your network configuration, copy and paste the
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.1/24

set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8:1::1/64
set security zones security-zone ABC interfaces ge-0/0/1.0
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.
To create zones and assign interfaces to them:
1. Configure an Ethernet interface and assign an IPv4 address to it.
[edit]
user@host# set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.1/24
2. Configure an Ethernet interface and assign an IPv6 address to it.
[edit]
user@host# set interfaces ge-0/0/1 unit 0 family inet6 address 2001:db8::1/32
3. Configure a security zone and assign it to an Ethernet interface.
[edit]
user@host# set security zones security-zone ABC interfaces ge-0/0/1.0
12
Results
From configuration mode, confirm your configuration by entering the show security zones security-zone ABC
and show interfaces ge-0/0/1 commands. If the output does not display the intended configuration, repeat
the configuration instructions in this example to correct it.
For brevity, this show output includes only the configuration that is relevant to this example. Any other
configuration on the system has been replaced with ellipses (...).
[edit]
user@host# show security zones security-zone ABC

...
interfaces {
ge-0/0/1.0 {
...
}
}
[edit]
user@host# show interfaces ge-0/0/1

...
unit 0 {
family inet {
address 203.0.113.1/24;
}
family inet6 {
address 2001:db8:1::1/64;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
IN THIS SECTION
Troubleshooting with Logs | 13

13
Troubleshooting with Logs
Purpose
Use these logs to identify any issues.
Action
From operational mode, enter the show log messages command and the show log dcd command.
Supported System Services for Host Inbound Traffic
This topic describes the supported system services for host inbound traffic on the specified zone or
interface.
For example, suppose a user whose system was connected to interface 203.0.113.4 in zone ABC wanted to
telnet into interface 198.51.100.4 in zone ABC. For this action to be allowed, the Telnet application must be
configured as an allowed inbound service on both interfaces and a policy must permit the traffic
transmission.
See the Options section in "system-services (Security Zones Host Inbound Traffic)" on page 519 to view
the system services that can be used for host inbound traffic.
NOTE: On SRX Series Services Gateways, the xnm-clear-text field is enabled in the factory-default
configuration. This setting enables incoming Junos XML protocol traffic in the trust zone for the
device when the device is operating with factory-default settings. We recommend that you
replace the factory-default settings with a user-defined configuration that provides additional
security once the box is configured. You must delete the xnm-clear-text field manually by using the
CLI command delete system services xnm-clear-text.
See the Options section in "protocols (Security Zones Interfaces)" on page 463 to view the supported
protocols that can be used for host inbound traffic.
NOTE: All services (except DHCP and BOOTP) can be configured either per zone or per
interface. A DHCP server is configured only per interface because the incoming interface must
be known by the server to be able to send out DHCP replies.
14
NOTE: You do not need to configure Neighbor Discovery Protocol (NDP) on host-inbound traffic,
because the NDP is enabled by default.
Configuration option for IPv6 Neighbor Discovery Protocol (NDP) is available. The configuration option
is set protocol neighbor-discovery onlink-subnet-only command. This option will prevent the device from
responding to a Neighbor Solicitation (NS) from a prefix which was not included as one of the device
interface prefixes.
NOTE: The Routing Engine needs to be rebooted after setting this option to remove any
possibility of a previous IPv6 entry from remaining in the forwarding-table.
Understanding How to Control Inbound Traffic Based on Traffic Types
This topic describes how to configure zones to specify the kinds of traffic that can reach the device from
systems that are directly connected to its interfaces.
Note the following:
• You can configure these parameters at the zone level, in which case they affect all interfaces of the
zone, or at the interface level. (Interface configuration overrides that of the zone.)
• You must enable all expected host-inbound traffic. Inbound traffic destined to this device is dropped
by default.
• You can also configure a zone's interfaces to allow for use by dynamic routing protocols.
This feature allows you to protect the device against attacks launched from systems that are directly or
indirectly connected to any of its interfaces. It also enables you to selectively configure the device so
that administrators can manage it using certain applications on certain interfaces. You can prohibit use
of other applications on the same or different interfaces of a zone. For example, most likely you would
want to ensure that outsiders not use the Telnet application from the Internet to log in to the device
because you would not want them connecting to your system.
15
Example: Controlling Inbound Traffic Based on Traffic Types
IN THIS SECTION
Requirements | 15
Overview | 15
Configuration | 15
Verification | 18
This example shows how to configure inbound traffic based on traffic types.
Requirements
Before you begin:
• Configure network interfaces. See Interfaces User Guide for Security Devices.
• Understand Inbound traffic types. See "Understanding How to Control Inbound Traffic Based on
Traffic Types" on page 14.
Overview
By allowing system services to run, you can configure zones to specify different types of traffic that can
reach the device from systems that are directly connected to its interfaces. You can configure the
different system services at the zone level, in which case they affect all interfaces of the zone, or at the
interface level. (Interface configuration overrides that of the zone.)
You must enable all expected host-inbound traffic. Inbound traffic from devices directly connected to
the device's interfaces is dropped by default.
Configuration
IN THIS SECTION
Procedure | 16
16
Procedure
set security zones security-zone ABC host-inbound-traffic system-services all

set security zones security-zone ABC interfaces ge-0/0/1.3 host-inbound-traffic system-services
telnet
ftp
snmp
all
ftp except
http except
To configure inbound traffic based on traffic types:
1. Configure a security zone.
[edit]
user@host# edit security zones security-zone ABC
2. Configure the security zone to support inbound traffic for all system services.
[edit security zones security-zone ABC]

user@host# set host-inbound-traffic system-services all
17
3. Configure the Telnet, FTP, and SNMP system services at the interface level (not the zone level) for
the first interface.

user@host# set interfaces ge-0/0/1.3 host-inbound-traffic system-services telnet
user@host# set interfaces ge-0/0/1.3 host-inbound-traffic system-services ftp
user@host# set interfaces ge-0/0/1.3 host-inbound-traffic system-services snmp
4. Configure the security zone to support inbound traffic for all system services for a second interface.

user@host# set interfaces ge-0/0/1.0 host-inbound-traffic system-services all
5. Exclude the FTP and HTTP system services from the second interface.

user@host# set interfaces ge-0/0/1.0 host-inbound-traffic system-services ftp except
user@host# set interfaces ge-0/0/1.0 host-inbound-traffic system-services http except
Results
From configuration mode, confirm your configuration by entering the show security zones security-zone ABC.
If the output does not display the intended configuration, repeat the configuration instructions in this
example to correct it.
[edit]

host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/1.3 {
system-services {
ftp;
telnet;
18
snmp;
}
}
}
ge-0/0/1.0 {
system-services {
all;
ftp {
except;
}
http {
except;
}
}
}
}
}
Verification
IN THIS SECTION
Purpose
Action
19
Understanding How to Control Inbound Traffic Based on Protocols
This topic describes the inbound system protocols on the specified zone or interface.
Any host-inbound traffic that corresponds to a protocol listed under the host-inbound traffic option is
allowed. For example, if anywhere in the configuration, you map a protocol to a port number other than
the default, you can specify the protocol in the host-inbound traffic option, and the new port number
will be used. Table 1 on page 19 lists the supported protocols. A value of all indicates that traffic from
all of the following protocols is allowed inbound on the specified interfaces (of the zone, or a single
specified interface).
Table 1: Supported Inbound System Protocols
Supported System Services
all igmp pim sap
bfd ldp rip vrrp
bgp msdp ripng nhrp
router-discovery dvmrp ospf rsvp
pgm ospf3
NOTE: If DVMRP or PIM is enabled for an interface, IGMP and MLD host-inbound traffic is
enabled automatically. Because IS-IS uses OSI addressing and should not generate any IP traffic,
there is no host-inbound traffic option for the IS-IS protocol.
NOTE: You do not need to configure Neighbor Discovery Protocol (NDP) on host-inbound traffic,
because the NDP is enabled by default.
Configuration option for IPv6 Neighbor Discovery Protocol (NDP) is available. The configuration option
is set protocol neighbor-discovery onlink-subnet-only command. This option will prevent the device from
responding to a Neighbor Solicitation (NS) from a prefix which was not included as one of the device
interface prefixes.
20
NOTE: The Routing Engine needs to be rebooted after setting this option to remove any
possibility of a previous IPv6 entry remaining in the forwarding-table.
Example: Controlling Inbound Traffic Based on Protocols
IN THIS SECTION
Requirements | 20
Overview | 20
Configuration | 21
Verification | 22
This example shows how to enable inbound traffic for an interface.
Requirements
Before you begin:
• Configure security zones. See "Example: Creating Security Zones" on page 9.
• Configure network interfaces. See the Interfaces User Guide for Security Devices.
Overview
Any host-inbound traffic that corresponds to a protocol listed under the host-inbound traffic option is
allowed. For example, if anywhere in the configuration you map a protocol to a port number other than
the default, you can specify the protocol in the host-inbound traffic option, and the new port number
will be used.
A value of all indicates that traffic from all of the protocols is allowed inbound on the specified
interfaces (of the zone, or a single specified interface).
21
Configuration
IN THIS SECTION
Procedure | 21
Procedure
set security zones security-zone ABC interfaces ge-0/0/1.0 host-inbound-traffic protocols ospf
set security zones security-zone ABC interfaces ge-0/0/1.0 host-inbound-traffic protocols ospf3
To configure inbound traffic based on protocols:
[edit]
2. Configure the security zone to support inbound traffic based on the ospf protocol for an interface.

user@host# set interfaces ge-0/0/1.0 host-inbound-traffic protocols ospf
22
3. Configure the security zone to support inbound traffic based on the ospf3 protocol for an interface.

user@host# set interfaces ge-0/0/1.0 host-inbound-traffic protocols ospf3
Results
From configuration mode, confirm your configuration by entering the show security zones security-zone ABC.
If the output does not display the intended configuration, repeat the configuration instructions in this
[edit]
interfaces {
ge-0/0/1.0 {
protocols {
ospf;
ospf3;
}
}
}
}
Verification
IN THIS SECTION
Purpose

23
Action
Example: Configuring the TCP-Reset Parameter
IN THIS SECTION
Requirements | 23
Overview | 23
Configuration | 23
Verification | 24
This example shows how to configure the TCP-Reset parameter for a zone.
Requirements
Before you begin, configure security zones. See "Example: Creating Security Zones" on page 9.
Overview
When the TCP-Reset parameter feature is enabled, the system sends a TCP segment with the RESET
flag set when traffic arrives that does not match an existing session and does not have the SYN flag set.
Configuration
IN THIS SECTION
Procedure | 24
24
Procedure
To configure the TCP-Reset parameter for a zone:
[edit]
2. Configure the TCP-Reset parameter for the zone.

user@host# set tcp-rst
3. If you are done configuring the device, commit the configuration.
[edit]
user@host# commit
Verification
To verify the configuration is working properly, enter the show security zones command.

3 CHAPTER
Address Books and Address Sets

26
Address Books and Address Sets
IN THIS SECTION
Limitations of Addresses and Address Sets in a Security Policy | 29
Configuring Addresses and Address Sets | 30
Example: Configuring Address Books and Address Sets | 36
Excluding Addresses from Policies | 44
Example: Excluding Addresses from Policies | 45
An address book is a collection of addresses and address sets. Address books are like components or
building blocks, that are referenced in other configurations such as security policies, security zones, and
NAT. You can add addresses to address books or use the predefined addresses available to each address
book by default.
Address sets are groups of addresses used to manage large address books. Using address sets, you can
organize addresses in logical groups and use them to easily configure other features, such as policies and
NAT rules.
Understanding Address Books
IN THIS SECTION
Predefined Addresses | 27
Network Prefixes in Address Books | 27
Wildcard Addresses in Address Books | 27
DNS Names in Address Books | 28

27
An address book is a collection of addresses and address sets. Junos OS allows you to configure multiple
address books. Address books are like components, or building blocks, that are referenced in other
configurations such as security policies or NAT. You can add addresses to address books or use the
predefined addresses available to each address book by default.
Address book entries include addresses of hosts and subnets whose traffic is either allowed, blocked,
encrypted, or user-authenticated. These addresses can be any combination of IPv4 addresses, IPv6
addresses, wildcard addresses, or Domain Name System (DNS) names.
Predefined Addresses
You can either create addresses or use any of the following predefined addresses that are available by
default:
• Any—This address matches any IP address. When this address is used as a source or destination
address in a policy configuration, it matches the source and destination address of any packet.
• Any-ipv4—This address matches any IPv4 address.
• Any-ipv6—This address matches any IPv6 address.
Network Prefixes in Address Books
You can specify addresses as network prefixes in the prefix/length format. For example, 203.0.113.0/24
is an acceptable address book address because it translates to a network prefix. However,
203.0.113.4/24 is not acceptable for an address book because it exceeds the subnet length of 24 bits.
Everything beyond the subnet length must be entered as 0 (zero). In special scenarios, you can enter a
hostname because it can use the full 32-bit address length.
An IPv6 address prefix is a combination of an IPv6 prefix (address) and a prefix length. The prefix takes
the form ipv6-prefix/prefix-length and represents a block of address space (or a network). The ipv6-
prefix variable follows general IPv6 addressing rules. The /prefix-length variable is a decimal value that
indicates the number of contiguous, higher-order bits of the address that make up the network portion
of the address. For example, 2001:db8::/32 is a possible IPv6 prefix. For more information on text
representation of IPv6 addresses and address prefixes, see RFC 4291, IP Version 6 Addressing
Architecture.
Wildcard Addresses in Address Books
Besides IP addresses and domain names, you can specify a wildcard address in an address book. A
wildcard address is represented as A.B.C.D/wildcard-mask. The wildcard mask determines which of the
bits in the IP address A.B.C.D should be ignored. For example, the source IP address
192.168.0.11/255.255.0.255 in a security policy implies that the security policy match criteria can
discard the third octet in the IP address (symbolically represented as 192.168.*.11). Therefore, packets
28
with source IP addresses such as 192.168.1.11 and 192.168.22.11 conform to the match criteria.
However, packets with source IP addresses such as 192.168.0.1 and 192.168.1.21 do not satisfy the
match criteria.
The wildcard address usage is not restricted to full octets only. You can configure any wildcard address.
For example, the wildcard address 192.168.7.1/255.255.7.255 implies that you need to ignore only the
first 5 bits of the third octet of the wildcard address while making the policy match. If the wildcard
address usage is restricted to full octets only, then wildcard masks with either 0 or 255 in each of the
four octets only will be permitted.
DNS Names in Address Books
By default, you can resolve IPv4 and IPv6 addresses for a DNS. If IPv4 or IPv6 addresses are designated,
you can resolve only those addresses by using the keywords ipv4-only and ipv6-only, respectively.
For SRX5400, SRX5600, and SRX5800 devices and vSRX instances, starting with Junos OS 15.1X49-
D60, management traffic can originate from a specific source address for Domain Name System (DNS)
names.
Consider the following when you configure the source address for DNS:
• Only one source address can be configured as the source address for each DNS server name.
• IPv6 source addresses are supported for IPv6 DNS servers, and only IPv4 addresses are supported
for IPv4 servers. You cannot configure an IPv4 address for an IPv6 DNS server or an IPv6 address for
an IPv4 DNS server.
To have all management traffic originate from a specific source address, configure the system name
server and the source address. For example:
user@host# set system name-server 10.5.0.1 source-address 10.4.0.1
Before you can use domain names for address entries, you must configure the security device for DNS
services. For information about DNS, see DNS Overview.
Understanding Global Address Books
An address book called “global” is always present on your system. Similar to other address books, the
global address book can include any combination of IPv4 addresses, IPv6 addresses, wildcard addresses,
or Domain Name System (DNS) names.
29
You can create addresses in the global address book or use the predefined addresses (any, any-ipv4, and
any-ipv6). However, to use the addresses in the global address book, you do not need to attach the
security zones to it. The global address book is available to all security zones that have no address books
attached to them.
Global address books are used in the following cases:
• NAT configurations–NAT rules can use address objects only from the global address book. They
cannot use addresses from zone-based address books.
• Global policies–Addresses used in a global policy must be defined in global address book. Global
address book objects do not belong to any particular zone.
Understanding Address Sets
An address book can grow to contain large numbers of addresses and become difficult to manage. You
can create groups of addresses called address sets to manage large address books. Using address sets,
you can organize addresses in logical groups and use them to easily configure other features, such as
policies and NAT rules.
The predefined address set, any, which contains both any-ipv4 and any-ipv6 addresses, is automatically
created for each security zone.
You can create address sets with existing users, or create empty address sets and later fill them with
users. When creating address sets, you can combine IPv4 and IPv6 addresses, but the addresses must be
in the same security zone.
You can also create an address set within an address set. This allows you to apply policies more
effectively. For example, if you want to apply a policy to two address sets, set1 and set2, instead of using
two statements, you can use just one statement to apply the policy to a new address set, set3, that
includes address sets set1 and set2.
When you add addresses to policies, sometimes the same subset of addresses can be present in multiple
policies, making it difficult to manage how policies affect each address entry. Reference an address set
entry in a policy like an individual address book entry to allow you to manage a small number of address
sets, rather than manage a large number of individual address entries.
Limitations of Addresses and Address Sets in a Security Policy
On SRX Series devices, one policy can reference multiple address sets, multiple address entries, or both.
One address set can reference a maximum of 1024 address entries and a maximum of 256 address sets.
30
There is a limit to the number of address objects that a policy can reference; the maximum number of
address objects per policy is 1024. Starting with Junos OS Release 12.3X48-D15 and Junos OS Release
17.3R1, the maximum number of policies per context for SRX3400 and SRX3600 devices increases from
10,240 to 40,000, and for SRX5400, SRX5600, and SRX5800 devices, from 10240 to 80,000.
Note that every IPv6 address entry is equal to 4 IPv4 address entries. For example, a policy configured
for 1000 IPv4 address entries and 5 IPv6 address entries has 1020 address objects (1000 + [5 x4] =
1020), which is within the 1024 value, and can be committed. However, a policy configured for 1000
IPv4 address entries and 7 IPv6 address entries has 1028 address objects (1000 +[7 x 4] = 1028), which
exceeds the 1024 value, cannot be committed, and consequently generates an error message.
Configuring Addresses and Address Sets
IN THIS SECTION
Addresses and Address Sets | 30
Address Books and Security Zones | 31
Address Books and Security Policies | 32
Address Books and NAT | 34
You can define addresses and address sets in an address book and then use them when configuring
different features. You can also use predefined addresses any, any-ipv4, and any-ipv6 that are available by
default. However, you cannot add the predefined address any to an address book.
After address books and sets are configured, they are used in configuring different features, such as
security policies, security zones, and NAT.
Addresses and Address Sets
You can define IPv4 addresses, IPv6 addresses, wildcard addresses, or Domain Name System (DNS)
names as address entries in an address book.
31
The following sample address book called book1 contains different types of addresses and address sets.
Once defined, you can leverage these addresses and address sets when you configure security zones,
policies, or NAT rules.
[edit security address-book book1]

user@host# set address a1 203.0.113.1
user@host# set address a2 203.0.113.4/30
user@host# set address a4 2001:db8::/32
user@host# set address a5 2001:db8:1::1/127
user@host# set address example dns-name www.example.com
user@host# set address-set set1 address a1
user@host# set address-set set2 address bbc
When defining addresses and address sets, follow these guidelines:
• Address sets can only contain address names that belong to the same security zone.
• Address names any, any-ipv4 and any-ipv6 are reserved; you cannot use them to create any addresses.
• Addresses and address sets in the same zone must have distinct names.
• Address names cannot be the same as address set names. For example, if you configure an address
with the name add1, do not create the address set with the name add1.
• When deleting an individual address book entry from the address book, you must remove the
address (wherever it is referred) from all the address sets; otherwise, the system will cause a commit
failure.
Address Books and Security Zones
A security zone is a logical group of interfaces with identical security requirements. You attach security
zones to address books that contain entries for the addressable networks and end hosts (and, thus,
users) belonging to the zone.
A zone can use two address books at a time—the global address book and the address book that the
zone is attached to. When a security zone is not attached to any address book, it automatically uses the
global address book. Thus, when a security zone is attached to an address book, the system looks up
addresses from this attached address book; otherwise, the system looks up addresses from the default
global address book. The global address book is available to all security zones by default; you do not
need to attach zones to the global address book.
The following guidelines apply when attaching security zones to address books:
32
• Addresses attached to a security zone conform to the security requirements of the zone.
• The address book that you attach to a security zone must contain all IP addresses that are reachable
within that zone.
• When you configure policies between two zones, you must define the addresses for each of the
zone's address books.
• Addresses in a user-defined address book have a higher lookup priority than addresses in the global
address book. Thus, for a security zone that is attached to a user-defined address book, the system
searches the user-defined address book first; if no address is found, then it searches the global
address book.
Address Books and Security Policies
Addresses and address sets are used when specifying the match criteria for a policy. Before you can
configure policies to permit, deny, or tunnel traffic to and from individual hosts and subnets, you must
make entries for them in address books. You can define different types of addresses, such as IPv4
addresses, IPv6 addresses, wildcard addresses, and DNS names, as match criteria for security policies.
Policies contain both source and destination addresses. You can refer to an address or address set in a
policy by the name you give to it in the address book attached to the zone specified in the policy.
• When traffic is sent to a zone, the zone and address to which the traffic is sent are used as the
destination zone and address-matching criteria in policies.
• When traffic is sent from a zone, the zone and address from which the traffic is sent are used as the
source zone and address-matching criteria in policies.
Addresses Available for Security Policies
When configuring the source and destination addresses for a policy rule, you can type a question mark
in the CLI to list all the available addresses that you can choose from.
You can use the same address name for different addresses that are in different address books.
However, the CLI lists only one of these addresses—the address that has the highest lookup priority.
For example, suppose you configure addresses in two address books—global and book1. Then, display the
addresses that you can configure as source or destination addresses in a policy (see Table 2 on page
33).
33
Table 2: Available Addresses Displayed in the CLI
Addresses Configured Addresses Displayed in the CLI
[edit security address-book] [edit security policies from-zone trust to-zone untrust]
set global address a1 203.0.113.0/24; user@host# set policy p1 match set match source-address ?
set global address a2 198.51.100.0/24;
set global address a3 192.0.2.0/24; Possible completions:
set book1 address a1 203.0.113.128/25; [ Open a set of values
a1 The address in address book book1
a2 The address in address book global
a3 The address in address book global
any Any IPv4 or IPv6 address
any-ipv4 Any IPv4 address
any-ipv6 Any IPv6 address
The addresses displayed in this example illustrate:
• Addresses in a user-defined address book have a higher lookup priority than addresses in the global
address book.
• Addresses in a global address book have a higher priority than the predefined addresses any, any-ipv4,
and any-ipv6.
• When the same address name is configured for two or more different addresses, only the highest
priority address, based on the address lookup, is available. In this example, the CLI displays address a1
from book1 (203.0.113.128/25) because that address has a higher lookup priority than the global
address a1 (203.0.113.0/24).
Applying Policies to Address Sets
When you specify an address set in policies, Junos OS applies the policies automatically to each address
set member, so you do not have to create them one by one for each address. Also, if an address set is
referenced in a policy, the address set cannot be removed without removing its reference in the policy. It
can, however, be edited.
NOTE: Consider that for each address set, the system creates individual rules for its members. It
creates an internal rule for each member in the group as well as for each service configured for
each user. If you configure address books without taking this into account, you can exceed the
34
number of available policy resources, especially if both the source and destination addresses are
address groups and the specified service is a service group.
Figure 2 on page 34 shows how policies are applied to address sets.
Figure 2: Applying Policies to Address Sets
Address Books and NAT
Once you define addresses in address books, you can specify them in the source, destination, or static
NAT rules. It is simpler to specify meaningful address names instead of IP prefixes as source and
destination addresses in the NAT rule configuration. For example, instead of specifying 10.208.16.0/22
as source address, you can specify an address called local that includes address 10.208.16.0/22.
35
You can also specify address sets in NAT rules, allowing you to add multiple addresses within an address
set and therefore manage a small number of address sets, rather than manage a large number of
individual address entries. When you specify an address set in a NAT rule, Junos OS applies the rule
automatically to each address set member, so you do not have to specify each address one by one.
NOTE: The following address and address set types are not supported in NAT rules—wildcard
addresses, DNS names, and a combination of IPv4 and IPv6 addresses.
When configuring address books with NAT, follow these guidelines:
• In a NAT rule, you can specify addresses from a global address book only. User-defined address
books are not supported with NAT.
• You can configure an address set as a source address name in a source NAT rule. However, you
cannot configure an address set as a destination address name in a destination NAT rule.
The following sample NAT statements show the address and address set types that are supported
with source and destination NAT rules:
[edit security nat source rule-set src-nat rule src-rule1]

set match source-address 2001:db8:1::/64
set match source-address-name add1
set match source-address-name add-set1
set match destination-address 2001:db8::/64
set match destination-address-name add2
set match destination-address-name add-set2
[edit security nat destination rule-set dst-nat rule dst-rule1]

set match source-address 2001:db8::/64
set match source-address-name add2
set match source-address-name add-set2
set match destination-address-name add1
36
• In a static NAT rule, you cannot configure an address set as a source or destination address name.
The following sample NAT statements show the types of address that are supported with static NAT
rules:
[edit security nat static rule-set stat]

set rule stat-rule1 match destination-address 203.0.113.0/24
set rule stat-rule2 match destination-address-name add1
Example: Configuring Address Books and Address Sets
IN THIS SECTION
Requirements | 36
Overview | 37
Configuration | 39
Verification | 42
This example shows how to configure addresses and address sets in address books. It also shows how to
attach address books to security zones.
Requirements
Before you begin:
• Configure the Juniper Networks security devices for network communication.
• Configure network interfaces on server and member devices. See the Interfaces User Guide for
Security Devices.
• Configure Domain Name System (DNS) services. For information about DNS, see DNS Overview.
37
Overview
IN THIS SECTION
Topology | 38
In this example, you configure an address book with addresses and address sets (see Figure 3 on page
38) to simplify configuring your company’s network. You create an address book called Eng-dept and add
addresses of members from the Engineering department. You create another address book called Web and
add a DNS name to it. Then you attach a security zone trust to the Eng-dept address book and security
zone untrust to the Web address book. You also create address sets to group software and hardware
addresses in the Engineering department. You plan to use these addresses as source address and
destination addresses in your future policy configurations.
38
In addition, you add an address to the global address book, to be available to any security zone that has
no address book attached to it.
Figure 3: Configuring Addresses and Address Sets
Topology
39
Configuration
IN THIS SECTION
Procedure | 39
Procedure
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.5

set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.6
set security zones security-zone trust interfaces ge-0/0/0
set security zones security-zone untrust interfaces ge-0/0/1
set security address-book Eng-dept address a1 203.0.113.1
set security address-book Eng-dept address-set sw-eng address a1
set security address-book Eng-dept address-set sw-eng address a2
set security address-book Eng-dept address-set hw-eng address a3
set security address-book Eng-dept address-set hw-eng address a4
set security address-book Eng-dept attach zone trust
set security address-book Web address Intranet dns-name www-int.device1.example.com
set security address-book Web attach zone untrust
set security address-book global address g1 198.51.100.2
To configure addresses and address sets:

40
1. Configure Ethernet interfaces and assign IPv4 addresses to them.
[edit]
user@host# set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.5
user@host# set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.6
2. Create security zones and assign interfaces to them.
[edit]
user@host# set security zones security-zone trust interfaces ge-0/0/0
user@host# set security zones security-zone untrust interfaces ge-0/0/1
3. Create an address book and define addresses in it.
[edit security address-book Eng-dept ]

4. Create address sets.
[edit security address-book Eng-dept]

user@host# set address-set sw-eng address a1
user@host# set address-set sw-eng address a2
user@host# set address-set hw-eng address a3
user@host# set address-set hw-eng address a4
5. Attach the address book to a security zone.
[edit security address-book Eng-dept]

user@host# set attach zone trust
41
6. Create another address book and attach it to a security zone.
[edit security address-book Web ]

user@host# set address Intranet dns-name www-int.device1.example.com
user@host# set attach zone untrust
7. Define an address in the global address book.
[edit]
user@host# set security address-book global address g1 198.51.100.2
Results
From configuration mode, confirm your configuration by entering the show security zones and show security
address-book commands. If the output does not display the intended configuration, repeat the
configuration instructions in this example to correct it.
[edit]
user@host# show security zones
security-zone trust {
interfaces {
ge-0/0/0.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/1.0;
}
}
[edit]
user@host# show security address-book
Eng-dept {
address a1 203.0.113.1/32;
address a2 203.0.113.2/32;
address a3 203.0.113.3/32;
address a4 203.0.113.4/32;
address-set sw-eng {
address a1;
42
address a2;
}
address-set hw-eng {
address a3;
address a4;
}
attach {
zone trust;
}
}
Web {
address Intranet {
dns-name www-int.device1.example.com;
}
attach {
zone untrust;
}
}
global {
address g1 198.51.100.2/32;
}
Verification
IN THIS SECTION
Verifying Address Book Configuration | 42
Verifying Global Address Book Configuration | 43
Confirm that the configuration is working properly.
Verifying Address Book Configuration
Purpose
Display information about configured address books and addresses.

43
Action
From configuration mode, enter the show security address-book command.

Eng-dept {
address a1 203.0.113.1/32;
address a2 203.0.113.2/32;
address a3 203.0.113.3/32;
address a4 203.0.113.4/32;
address-set sw-eng {
address a1;
address a2;
}
address-set hw-eng {
address a3;
address a4;
}
attach {
zone trust;
}
}
Web {
address Intranet {
dns-name www-int.device1.example.com;
}
attach {
zone untrust;
}
}
global {
address g1 198.51.100.2/32;
}
Verifying Global Address Book Configuration
Purpose
Display information about configured addresses in the global address book.

44
Action
From configuration mode, enter the show security address-book global command.
user@host# show security address-book global

address g1 198.51.100.2/32;
Excluding Addresses from Policies
Junos OS allows users to add any number of source and destination addresses to a policy. If you need to
exclude certain addresses from a policy, you can configure them as negated addresses. When an address
is configured as a negated address, it is excluded from a policy. You cannot, however, exclude the
following IP addresses from a policy:
• Wildcard
• IPv6
• any
• any-ipv4
• any-ipv6
• 0.0.0.0
When a range of addresses or a single address is negated, it can be divided into multiple addresses.
These negated addresses are shown as a prefix or a length that requires more memory for storage on a
Packet Forwarding Engine.
Each platform has a limited number of policies with negated addresses. A policy can contain 10 source
or destination addresses. The capacity of the policy depends on the maximum number of policies that
the platform supports.
Before you configure a negated source address, destination address, or both, perform the following
tasks:
1. Create a source, destination, or both address book.
2. Create address names and assign source and destination addresses to the address names.
3. Create address sets to group source, destination, or both address names.

45
4. Attach source and destination address books to security zones. For example, attach the source
address book to the from-zone trust and the destination address book to the to-zone untrust.
5. Specify the match source, destination, or both address names.
6. Execute source-address-excluded, destination-address excluded, or both commands. A source,

destination, or both addresses added in the source, destination, or both address books will be
excluded from the policy.
NOTE: The global address book does not need to be attached to any security zone.
Example: Excluding Addresses from Policies
IN THIS SECTION
Requirements | 45
Overview | 46
Configuration | 46
Verification | 50
This example shows how to configure negated source and destination addresses. It also shows how to
configure address books and address sets.
Requirements
This example uses the following hardware and software components:
• An SRX Series device
• A PC
• Junos OS Release 12.1X45-D10
Before you begin, configure address books and address sets. See "Example: Configuring Address Books
and Address Sets" on page 36.
46
Overview
In this example, you create source and destination address books, SOUR-ADDR and DES-ADDR, and
add source and destination addresses to it. You create source and destination address sets, as1 and as2,
and group source and destination addresses to them. Then you attach source address book to the
security zone trust and the destination address book to the security zone untrust.
You create security zones from-zone trust and to-zone untrust. You specify the policy name to p1 and
then you set the name of the match source address to as1 and the match destination address to as2.
You specify the commands source -address-excluded and destination -address-excluded to exclude
source and destination addresses configured in the policy p1. Finally, you set the policy p1 to permit
traffic from-zone trust to to-zone untrust.
Configuration
IN THIS SECTION
Procedure | 46
Procedure
set security address-book SOU-ADDR address ad1 255.255.255.255/32

set security address-book SOU-ADDR address ad3 range-address 192.0.2.6 to 192.0.2.116
set security address-book SOU-ADDR address-set as1 address ad1
set security address-book SOU-ADDR attach zone trust
set security address-book DES-ADDR address ad8 198.51.100.1/24
set security address-book DES-ADDR address ad9 range-address 192.0.2.117 to 192.0.2.199
set security address-book DES-ADDR address ad10 198.51.100.0/24
set security address-book DES-ADDR address ad11 range-address 192.0.2.199 to 192.0.2.250
47
set security address-book DES-ADDR address-set as2 address ad8

set security address-book DES-ADDR attach zone untrust
set security policies from-zone trust to-zone untrust policy p1 match source-address as1
set security policies from-zone trust to-zone untrust policy p1 match source-address-excluded
set security policies from-zone trust to-zone untrust policy p1 match destination-address as2
set security policies from-zone trust to-zone untrust policy p1 match destination-address-
excluded
set security policies from-zone trust to-zone untrust policy p1 match application any
set security policies from-zone trust to-zone untrust policy p1 then permit
To configure negated addresses:
1. Create a source address book and address names. Add the source addresses to the address book.
[edit security address book ]

user@host#set SOU-ADDR address ad1 255.255.255.255/32
user@host#set SOU-ADDR ad3 range-address 192.0.2.6 to 192.0.2.116
2. Create an address set to group source address names.

user@host# set SOU-ADDR address-set as1 address ad1
48
3. Attach the source address book to the security from zone.

user@host# set SOU-ADDR attach zone trust
4. Create a destination address book and address names. Add the destination addresses to the
address book.

user@host#set DES-ADDR address ad8 198.51.100.1/24
user@host#set DES-ADDR address ad9 range-address 192.0.2.117 to 192.0.2.199
user@host#set DES-ADDR address ad10 198.51.100.0/24
user@host#set DES-ADDR address ad11 range-address 192.0.2.199 to 192.0.2.250
5. Create another address set to group destination address names.

user@host# set DES-ADDR address-set as1 address ad8
6. Attach the destination address book to the security to zone.

user@host# set DES-ADDR attach zone untrust
7. Specify the policy name and source address.
[edit security policies]

user@host# set from-zone trust to-zone untrust policy p1 match source-address as1
8. Exclude source addresses from the policy.

user@host# set from-zone trust to-zone untrust policy p1 match source-address-excluded
49
9. Specify the destination address.

user@host# set from-zone trust to-zone untrust policy p1 match destination-address as2
10. Exclude destination addresses from the policy.

user@host# set from-zone trust to-zone untrust policy p1 match destination-address-
excluded
11. Configure the security policy application.

user@host# set from-zone trust to-zone untrust policy p1 match application any
12. Permit the traffic from-zone trust to to-zone untrust.

user@host# set from-zone trust to-zone untrust policy p1 then permit
Results
From configuration mode, confirm your configuration by entering the show security policies command. If
the output does not display the intended configuration, repeat the configuration instructions in this
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
policy p1 {
match {
source-address as1;
destination-address as2;
source-address-excluded;
destination-address-excluded;
application any;
}
50
then {
permit;
}
}
}
Verification
IN THIS SECTION
Verifying the Policy Configuration | 50
Verifying the Policy Configuration Detail | 51
Verifying the Policy Configuration
Purpose
Verify that the policy configuration is correct.
Action
From operational mode, enter the show security policies policy-name p1 command.
user@host>show security policies policy-name p1

node0:
--------------------------------------------------------------------------
From zone: trust, To zone: untrust
Policy: p1, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1
Source addresses(excluded): as1
Destination addresses(excluded): as2
Applications: any
Action: permit
This output summarizes the policy configuration.

51
Verifying the Policy Configuration Detail
Purpose
Verify that the policy and the negated source and destination address configurations are correct.
Action
From operational mode, enter the show security policies policy-name p1 detail command.
user@host>show security policies policy-name p1 detail

Policy: p1, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
Source addresses(excluded):
ad1(SOU-ADDR): 255.255.255.255/32
ad2(SOU-ADDR): 203.0.113.130/25
ad3(SOU-ADDR): 192.0.2.6 ~ 192.0.2.116
ad4(SOU-ADDR): 192.0.2.128/25
Destination addresses(excluded):
ad8(DES-ADDR): 198.51.100.1/24
ad9(DES-ADDR): 192.0.2.117 ~ 192.0.2.199
ad10(DES-ADDR): 198.51.100.0/24
ad11(DES-ADDR): 192.0.2.199 to 192.0.2.250
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No
This output summarizes the policy configuration and shows the names of negated source and
destination addresses excluded from the policy.
SEE ALSO

52
Release History Table
Release Description
12.3X48-D15 and Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the maximum
17.3R1 number of policies per context for SRX3400 and SRX3600 devices increases from 10,240
to 40,000, and for SRX5400, SRX5600, and SRX5800 devices, from 10240 to 80,000.
4 CHAPTER
Security Policy Applications and

Application Sets

54
Security Policy Applications and Application Sets
IN THIS SECTION
Example: Configuring Security Policy Applications and Application Sets | 55
Understanding Policy Application Timeout Configuration and Lookup | 58
Understanding Policy Application Timeouts Contingencies | 59
Example: Setting a Policy Application Timeout | 59
Policy applications are types of traffic for which protocol standards exist. The policy application set is a
group of policy applications. Junos OS simplifies the process by allowing you to manage a small number
of policy application sets, rather than a large number of individual policy application entries.
The policy application or application set is referred by security policies as match criteria for packets
initiating sessions. Junos OS allows you to configure policy applications and application sets. You can
create an application set that contains all the approved applications.
Security Policy Applications Overview
Applications are types of traffic for which protocol standards exist. Each application has a transport
protocol and destination port number(s) associated with it, such as TCP/port 21 for FTP and TCP/port
23 for Telnet. When you create a policy, you must specify an application for it.
You can select one of the predefined applications from the application book, or a custom application or
application set that you created. You can see which application you can use in a policy by using the show
applications CLI command.
NOTE: Each predefined application has a source port range of 1–65535, which includes the entire
set of valid port numbers. This prevents potential attackers from gaining access by using a source
port outside of the range. If you need to use a different source port range for any predefined
55
application, create a custom application. For information, see "Understanding Custom Policy
Applications" on page 85.
SEE ALSO
Security Policy Application Sets Overview
When you create a policy, you must specify an application, or service, for it to indicate that the policy
applies to traffic of that type. Sometimes the same applications or a subset of them can be present in
multiple policies, making it difficult to manage. Junos OS allows you to create groups of applications
called application sets. Application sets simplify the process by allowing you to manage a small number
of application sets, rather than a large number of individual application entries.
The application (or application set) is referred to by security policies as match criteria for packets
initiating sessions. If the packet matches the application type specified by the policy and all other criteria
match, then the policy action is applied to the packet.
You can specify the name of an application set in a policy. In this case, if all of the other criteria match,
any one of the applications in the application set serves as valid matching criteria; any is the default
application name that indicates all possible applications.
Applications are created in the .../applications/application/application-name directory. You do not need to

configure an application for any of the services that are predefined by the system.
In addition to predefined services, you can configure a custom service. After you create a custom
service, you can refer to it in a policy.
Example: Configuring Security Policy Applications and Application Sets
IN THIS SECTION
Requirements | 56
Overview | 56
56
Configuration | 57
Verification | 57
This example shows how to configure applications and application sets.
Requirements
Before you begin, configure the required applications. See "Security Policy Application Sets Overview"
on page 55.
Overview
IN THIS SECTION
Topology | 56
Rather than creating or adding multiple individual application names to a policy, you can create an
application set and refer to the name of the set in a policy. For example, for a group of employees, you
can create an application set that contains all the approved applications.
In this example, you create an application set that are used to log in to the servers in the ABC (intranet)
zone, to access the database, and to transfer files.
• Define the applications in the configured application set.
• Managers in zone A and managers in zone B use these services. Therefore, give the application set a
generic name, such as MgrAppSet.
• Create an application set for the applications that are used for e-mail and Web-based applications
that are delivered by the two servers in the external zone.
Topology
57
Configuration
IN THIS SECTION
Procedure | 57
Procedure
To configure an application and application set:
1. Create an application set for managers.
[edit applications]
user@host# set application-set MgrAppSet application junos-ssh
user@host# set application-set MgrAppSet application junos-telnet
2. Create another application set for e-mail and Web-based applications.
[edit applications]
user@host# set application-set WebMailApps application junos-smtp
user@host# set application-set WebMailApps application junos-pop3
[edit]
user@host# commit
Verification
To verify the configuration is working properly, enter the show applications command in configuration
mode.
58
Understanding Policy Application Timeout Configuration and Lookup
The application timeout value you set for an application determines the session timeout. You can set the
timeout threshold for a predefined or custom application; you can use the application default timeout,
specify a custom timeout, or use no timeout at all.
Application timeout values are stored in the root TCP and UDP port-based timeout table and in the
protocol-based default timeout table. When you set an application timeout value, Junos OS updates
these tables with the new value. There are also default timeout values in the applications entry
database, which are taken from predefined applications. You can set a timeout, but you cannot alter a
default value.
Each custom application can be configured with its own custom application timeout. If multiple custom
applications are configured with custom timeouts, then each application will have its own custom
application timeout.
If the application that is matched for the traffic has a timeout value, that timeout value is used.
Otherwise, the lookup proceeds in the following order until an application timeout value is found:
1. The root TCP and UDP port-based timeout table is searched for a timeout value.
2. The protocol-based default timeout table is searched for a timeout value. See Table 3 on page 58.
Table 3: Protocol-Based Default Timeout
Protocol Default Timeout (seconds)
TCP 1800
UDP 60
ICMP 60
OSPF 60
Other 1800
59
Understanding Policy Application Timeouts Contingencies
When setting timeouts, be aware of the following contingencies:
• If an application contains several application rule entries, all rule entries share the same timeout. You
need to define the application timeout only once. For example, if you create an application with two
rules, the following commands will set the timeout to 20 seconds for both rules:
user@host# set applications application test protocol tcp destination-port 1035-1035

inactivity-timeout 20
user@host# set applications application test term test protocol udp
user@host# set applications application test term test source-port 1-65535
user@host# set applications application test term test destination-port 1111-1111
• If multiple custom applications are configured with custom timeouts, then each application will have
its own custom application timeout. For example:
user@host# set applications application ftp-1 protocol tcp source-port 0-65535 destination-
port 2121-2121 inactivity-timeout 10
user@host# set applications application telnet-1 protocol tcp source-port 0-65535 destination-
port 2300-2348 inactivity-timeout 20
With this configuration, Junos OS applies a 10-second timeout for destination port 2121 and a 20-
second timeout for destination port 2300 in an application group.
Example: Setting a Policy Application Timeout
IN THIS SECTION
Requirements | 60
Overview | 60
Configuration | 60
Verification | 61
60
This example shows how to set a policy application timeout value.
Requirements
Before you begin, understand policy application timeouts. See "Understanding Policy Application
Timeout Configuration and Lookup" on page 58.
Overview
Application timeout values are stored in the application entry database and in the corresponding vsys
TCP and UDP port-based timeout tables. In this example, you set the device for a policy application
timeout to 75 minutes (4500 seconds) for the FTP predefined application.
When you set an application timeout value, Junos OS updates these tables with the new value.
Configuration
IN THIS SECTION
Procedure | 60
Procedure
To set a policy application timeout:
1. Set the inactivity timeout value.
[edit applications application ftp]

user@host# set inactivity-timeout 4500
2. Commit the configuration if you are done configuring the device.
[edit]
user@host# commit
61
Verification
To verify the configuration is working properly, enter the show applications command.
Predefined Policy Applications
IN THIS SECTION
Understanding Internet-Related Predefined Policy Applications | 62
Understanding Microsoft Predefined Policy Applications | 64
Understanding Dynamic Routing Protocols Predefined Policy Applications | 66
Understanding Streaming Video Predefined Policy Applications | 67
Understanding Sun RPC Predefined Policy Applications | 68
Understanding Security and Tunnel Predefined Policy Applications | 69
Understanding IP-Related Predefined Policy Applications | 70
Understanding Instant Messaging Predefined Policy Applications | 70
Understanding Management Predefined Policy Applications | 71
Understanding Mail Predefined Policy Applications | 73
Understanding UNIX Predefined Policy Applications | 74
Understanding Miscellaneous Predefined Policy Applications | 74
Understanding ICMP Predefined Policy Applications | 75
Predefined policy allows you to choose the applications to permit or deny. You can specify the
predefined applications for the policy, depending on your network requirements.
62
Understanding Internet-Related Predefined Policy Applications
When you create a policy, you can specify predefined Internet-related applications for the policy.
Table 4 on page 62 lists Internet-related predefined applications. Depending on your network

requirements, you can choose to permit or deny any or all of these applications. Each entry lists the
application name, default receiving port, and application description.
Table 4: Predefined Applications
Application Name Port(s) Application Description
AOL 5190-5193 America Online Internet service provider (ISP) provides Internet,
chat, and instant messaging applications.
DHCP relay 67 (default) Dynamic Host Configuration Protocol.
DHCP 68 client Dynamic Host Configuration Protocol allocates network addresses

and delivers configuration parameters from server to hosts.
67 server
DNS 53 Domain Name System translates domain names into IP addresses.
FTP File Transfer Protocol (FTP) allows the sending and receiving of
files between machines. You can choose to deny or permit ANY or
20 data to selectively permit or deny.
21 control We recommend denying FTP applications from untrusted sources

(Internet).
Gopher 70 Gopher organizes and displays Internet servers' contents as a

hierarchically structured list of files.
We recommend denying Gopher access to avoid exposing your

network structure.
63
Table 4: Predefined Applications (Continued)
HTTP 80 HyperText Transfer Protocol is the underlying protocol used by the

World Wide Web (WWW).
Denying HTTP application disables your users from viewing the

Internet.
Permitting HTTP application allows your trusted hosts to view the

Internet.
HTTP-EXT — Hypertext Transfer Protocol with extended nonstandard ports
HTTPS 443 Hypertext Transfer Protocol with Secure Sockets Layer (SSL) is a
protocol for transmitting private documents through the Internet.
Denying HTTPS disables your users from shopping on the Internet

and from accessing certain online resources that require secure
password exchange.
Permitting HTTPS allows your trusted hosts to participate in

password exchange, shop online, and visit various protected online
resources that require user login.
Internet Locator — Internet Locator Service includes LDAP, User Locator Service, and
Service LDAP over TSL/SSL.
IRC 6665-6669 Internet Relay Chat (IRC) allows people connected to the Internet
to join live discussions.
LDAP 389 Lightweight Directory Access Protocol is a set of protocols used to

access information directories.
PC-Anywhere — PC-Anywhere is a remote control and file transfer software.
TFTP 69 Trivial File transfer Protocol (TFTP) is a protocol for simple file
transfer.
64
Table 4: Predefined Applications (Continued)
WAIS — Wide Area Information Server is a program that finds documents

on the Internet.
NOTE: Starting in Junos OS Release Junos OS Release 18.4R1, encrypted applications such as
HTTP, SMTP, IMAP and POP3 over SSL are identified as junos:HTTPS, junos:SMTPS,
junos:IMAPS, and junos:POP3S in Junos OS predefined applications and application sets. For
example: If you configure a security policy to allow or deny HTTPS traffic, you must specify
application matching criteria as junos:HTTPS. In previous Junos OS Releases, both HTTP and
encrypted HTTP (HTTPS) applications can be configured using a same application matching
criteria as junos:HTTP.
Understanding Microsoft Predefined Policy Applications
When you create a policy, you can specify predefined Microsoft applications for the policy.
Table 5 on page 64 lists predefined Microsoft applications, parameters associated with each
application, and a brief description of each application. Parameters include universal unique identifiers
(UUIDs) and TCP/UDP source and destination ports. A UUID is a 128-bit unique number generated
from a hardware address, a timestamp, and seed values.
Table 5: Predefined Microsoft Applications
Application Parameter/UUID Description
Junos MS-RPC-EPM 135 Microsoft remote procedure call

(RPC) Endpoint Mapper (EPM)
e1af8308-5d1f-11c9-91a4-0800 Protocol.
2b14a0fa
Junos MS-RPC — Any Microsoft remote procedure

call (RPC) applications.
65
Table 5: Predefined Microsoft Applications (Continued)
Junos MS-RPC-MSEXCHANGE 3 members Microsoft Exchange application

group includes:
• Junos-MS-RPC-
MSEXCHANGE-DATABASE
• Junos-MS-RPC-
MSEXCHANGE-DIRECTORY
• Junos-MS-RPC-
MSEXCHANGE-INFO-STORE
Junos-MS-RPC-MSEXCHANGE- 1a190310- Microsoft Exchange Database

DATABASE bb9c-11cd-90f8-00aa00466520 application.
Junos-MS-RPC-MSEXCHANGE- f5cc5a18-4264-101a-8c59-0800 Microsoft Exchange Directory

DIRECTORY 2b2f8426 application.
f5cc5a7c-4264-101a-8c59-0800
2b2f8426
f5cc59b4-4264-101a-8c59-0800
2b2f8426
Junos-MS-RPC-MSEXCHANGE- 0e4a0156- Microsoft Exchange Information

INFO-STORE dd5d-11d2-8c2f-00c04fb6bcde Store application.
1453c42c-0fa6-11d2-
a910-00c04f990f3b
10f24e8e-0fa6-11d2-
a910-00c04f990f3b
1544f5e0-613c-11d1-93df-00c0
4fd7bd09
Junos-MS-RPC-TCP — Microsoft Transmission Control

Protocol (TCP) application.
66
Table 5: Predefined Microsoft Applications (Continued)
Junos-MS-RPC-UDP — Microsoft User Datagram Protocol

(UDP) application.
Junos-MS-SQL — Microsoft Structured Query

Language (SQL).
Junos-MSN — Microsoft Network Messenger

application.
Understanding Dynamic Routing Protocols Predefined Policy

Applications
When you create a policy, you can specify predefined dynamic routing protocol applications for the
policy.
Depending on your network requirements, you can choose to permit or deny messages generated from
these dynamic routing protocols and packets of these dynamic routing protocols. Table 6 on page 66
lists each supported dynamic routing protocol by name, port, and description.
Table 6: Dynamic Routing Protocols
Dynamic Routing Protocol Port Description
RIP 520 RIP is a common distance-vector routing

protocol.
OSPF 89 OSPF is a common link-state routing

protocol.
BGP 179 BGP is an exterior/interdomain routing

protocol.
67
Understanding Streaming Video Predefined Policy Applications
When you create a policy, you can specify predefined streaming video applications for the policy.
Table 7 on page 67 lists each supported streaming video application by name and includes the default
port and description. Depending on your network requirements, you can choose to permit or deny any
or all of these applications.
Table 7: Supported Streaming Video Applications
Application Port Description
H.323 TCP source 1-65535; TCP destination H.323 is a standard approved by the
1720, 1503, 389, 522, 1731 International Telecommunication Union
(ITU) that defines how audiovisual
UDP source 1-65535; UDP source 1719 conference data is transmitted across
networks.
NetMeeting TCP source 1-65535; TCP destination Microsoft NetMeeting uses TCP to provide
1720, 1503, 389, 522 teleconferencing (video and audio)
applications over the Internet.
UDP source 1719
Real media TCP source 1-65535; TCP destination Real Media is streaming video and audio
7070 technology.
RTSP 554 Real-Time Streaming Protocol (RTSP) is for

streaming media applications
SIP 5056 Session Initiation Protocol (SIP) is an

Application-Layer control protocol for
creating, modifying, and terminating
sessions.
VDO Live TCP source 1-65535; TCP destination VDOLive is a scalable, video streaming
7000-7010 technology.
68
Understanding Sun RPC Predefined Policy Applications
When you create a policy, you can specify predefined Sun RPC applications for the policy.
Table 8 on page 68 lists each Sun remote procedure call Application Layer Gateway (RPC ALG)
application name, parameters, and full name.
Table 8: RPC ALG Applications
Application Program Numbers Full Name
SUN-RPC-PORTMAPPER 111100000 Sun RPC Portmapper protocol
SUN-RPC-ANY ANY Any Sun RPC applications
SUN-RPC-PROGRAM-MOUNTD 100005 Sun RPC Mount Daemon
SUN-RPC-PROGRAM-NFS 100003 Sun RPC Network File System
100227
SUN-RPC-PROGRAM-NLOCKMGR 100021 Sun RPC Network Lock Manager
SUN-RPC-PROGRAM-RQUOTAD 100011 Sun RPC Remote Quota Daemon
SUN-RPC-PROGRAM-RSTATD 100001 Sun RPC Remote Status Daemon
SUN-RPC-PROGRAM-RUSERD 100002 Sun RPC Remote User Daemon
SUN-RPC-PROGRAM-SADMIND 100232 Sun RPC System Administration Daemon
SUN-RPC-PROGRAM-SPRAYD 100012 Sun RPC Spray Daemon
SUN-RPC-PROGRAM-STATUS 100024 Sun RPC Status
SUN-RPC-PROGRAM-WALLD 100008 Sun RPC Wall Daemon

69
Table 8: RPC ALG Applications (Continued)
Application Program Numbers Full Name
SUN-RPC-PROGRAM-YPBIND 100007 SUN RPC Yellow Page Bind application
Understanding Security and Tunnel Predefined Policy Applications
When you create a policy, you can specify predefined security and tunnel applications for the policy.
Table 9 on page 69 lists each supported application and gives the default port(s) and a description of
each entry.
Table 9: Supported Applications
IKE UDP source 1-65535; UDP destination Internet Key Exchange is the protocol that
500 sets up a security association in the IPsec
protocol suite.
Internet Key protocol (IKE) is a protocol to

obtain authenticated keying material for
use with ISAKMP.
IKE-NAT 4500 IKE-Network Address Translation (NAT)

performs Layer 3 NAT for S2C IKE traffic.
L2TP 1701 L2TP combines PPTP with Layer 2

Forwarding (L2F) for remote access.
PPTP 1723 Point-to-Point Tunneling Protocol allows

corporations to extend their own private
network through private tunnels over the
public Internet.
70
Understanding IP-Related Predefined Policy Applications
When you create a policy, you can specify predefined IP-related applications for the policy.
Table 10 on page 70 lists the predefined IP-related applications. Each entry includes the default port
and a description of the application.
TCP-ANY means any application that is using TCP, so there is no default port for it. The same is true for
UDP-ANY.
Table 10: Predefined IP-Related Applications
Any — Any application
TCP-ANY 0-65,535 Any protocol using the TCP
UDP-ANY 0-65,535 Any protocol using the UDP
Understanding Instant Messaging Predefined Policy Applications
When you create a policy, you can specify predefined instant messaging applications for the policy.
Table 11 on page 70 lists predefined Internet-messaging applications. Each entry includes the name of
the application, the default or assigned port, and a description of the application.
Table 11: Predefined Internet-Messaging Applications
Gnutella 6346 (default) Gnutella is a public domain file sharing protocol that operates over
a distributed network. You can assign any port, but the default is
6346.
MSN 1863 Microsoft Network Messenger is a utility that allows you to send
instant messages and talk online.
71
Table 11: Predefined Internet-Messaging Applications (Continued)
NNTP 119 Network News Transport Protocol is a protocol used to post,

distribute, and retrieve USENET messages.
SMB 445 Server Message Block (SMB) over IP is a protocol that allows you
to read and write files to a server on a network.
YMSG 5010 Yahoo! Messenger is a utility that allows you to check when others
are online, send instant messages, and talk online.
Understanding Management Predefined Policy Applications
When you create a policy, you can specify predefined management applications for the policy.
Table 12 on page 71 lists the predefined management applications. Each entry includes the name of
the application, the default or assigned port, and a description of the application.
Table 12: Predefined Management Applications
NBNAME 137 NetBIOS Name application displays all NetBIOS name packets sent
on UDP port 137.
NDBDS 138 NetBIOS Datagram application, published by IBM, provides

connectionless (datagram) applications to PCs connected with a
broadcast medium to locate resources, initiate sessions, and
terminate sessions. It is unreliable and the packets are not
sequenced.
NFS — Network File System uses UDP to allow network users to access
shared files stored on computers of different types. SUN RPC is a
building block of NFS.
72
Table 12: Predefined Management Applications (Continued)
NS Global — NS-Global is the central management protocol for Juniper

Networks Firewall/VPN devices.
NS Global PRO — NS Global-PRO is the scalable monitoring system for the Juniper
Networks Firewall/VPN device family.
NSM — Network and Security Manager
NTP 123 Network Time Protocol provides a way for computers to

synchronize to a time reference.
RLOGIN 513 RLOGIN starts a terminal session on a remote host.
RSH 514 RSH executes a shell command on a remote host.
SNMP 161 Simple Network Management Protocol is a set of protocols for

managing complex networks.
SQL*Net V1 66 SQL*Net Version 1 is a database language that allows for the

creation, access, modification, and protection of data.
SQL*Net V2 66 SQL*Net Version 2 is a database language that allows for the

creation, access, modification, and protection of data.
MSSQL 1433 (default Microsoft SQL is a proprietary database server tool that allows for
instance) the creation, access, modification, and protection of data.
SSH 22 SSH is a program to log in to another computer over a network

through strong authentication and secure communications on an
unsecure channel.
SYSLOG 514 Syslog is a UNIX program that sends messages to the system
logger.
73
Table 12: Predefined Management Applications (Continued)
Talk 517-518 Talk is a visual communication program that copies lines from your
terminal to that of another user.
Telnet 23 Telnet is a UNIX program that provides a standard method of

interfacing terminal devices and terminal-oriented processes to
each other.
WinFrame — WinFrame is a technology that allows users on non-Windows

machines to run Windows applications.
X-Windows — X-Windows is the windowing and graphics system that Motif and
OpenLook are based on.
Understanding Mail Predefined Policy Applications
When you create a policy, you can specify predefined mail applications for the policy.
Table 13 on page 73 lists the predefined mail applications. Each includes the name of the application,
the default or assigned port number, and a description of the application.
Table 13: Predefined Mail Applications
IMAP 143 Internet Message Access Protocol is used for retrieving messages.
Mail (SMTP) 25 Simple Mail Transfer Protocol is used to send messages between
servers.
POP3 110 Post Office Protocol is used for retrieving e-mail.

74
Understanding UNIX Predefined Policy Applications
When you create a policy, you can specify predefined UNIX applications for the policy.
Table 14 on page 74 lists the predefined UNIX applications. Each entry includes the name of the
application, the default or assigned port, and a description of the application.
Table 14: Predefined UNIX Applications
FINGER 79 Finger is a UNIX program that provides information about the

users.
UUCP 117 UNIX-to-UNIX Copy Protocol (UUCP) is a UNIX utility that enables
file transfers between two computers over a direct serial or
modem connection.
Understanding Miscellaneous Predefined Policy Applications
When you create a policy, you can specify miscellaneous predefined applications for the policy.
Table 15 on page 74 lists predefined miscellaneous applications. Each entry includes the application
name, default or assigned port, and a description of the application.
Table 15: Predefined Miscellaneous Applications
CHARGEN 19 Character Generator Protocol is a UDP- or TCP-based debugging

and measurement tool.
DISCARD 9 Discard protocol is an Application Layer protocol that describes a

process for discarding TCP or UDP data sent to port 9.
IDENT 113 Identification protocol is a TCP/IP Application Layer protocol used

for TCP client authentication.
75
Table 15: Predefined Miscellaneous Applications (Continued)
LPR 515 listen; Line Printer Daemon protocol is a TCP-based protocol used for
printing applications.
721-731 source
range (inclusive)
RADIUS 1812 Remote Authentication Dial-In User Service application is a server

program used for authentication and accounting purposes.
RADIUS Accounting 1813 A RADIUS Accounting server receives statistical data about users
logging in to or out of a LAN.
SQLMON 1434 (SQL Monitor SQL monitor (Microsoft)

Port)
VNC 5800 Virtual Network Computing facilitates viewing and interacting with
another computer or mobile Juniper Networks device connected
to the Internet.
WHOIS 43 Network Directory Application Protocol is a way to look up

domain names.
SCCP 2000 Cisco Station Call Control Protocol (SCCP) uses the signaling
connection control port to provide high availability and flow
control.
Understanding ICMP Predefined Policy Applications
IN THIS SECTION
Default Behavior of ICMP Unreachable Errors | 81

76
When you create a policy, you can specify the ICMP predefined application for the policy.
Internet Control Message Protocol (ICMP) is a part of IP and provides a way to query a network (ICMP
query messages) and to receive feedback from the network for error patterns (ICMP error messages).
ICMP does not, however, guarantee error message delivery or report all lost datagrams; and it is not a
reliable protocol. ICMP codes and type codes describe ICMP query messages and ICMP error messages.
You can choose to permit or deny any or specific types of ICMP messages to improve network security.
Some types of ICMP messages can be exploited to gain information about your network that might
compromise security. For example, ICMP, TCP, or UDP packets can be constructed to return ICMP error
messages that contain information about a network, such as its topology, and access list filtering
characteristics. Table 16 on page 76 lists ICMP message names, the corresponding code, type, and
description.
Table 16: ICMP Messages
ICMP Message Name Type Code Description
ICMP-ANY all all ICMP-ANY affects any protocol using

ICMP.
Denying ICMP-ANY impairs any attempt to

ping or monitor a network using ICMP.
Permitting ICMP-ANY allows all ICMP

messages.
ICMP-ADDRESS-MASK 17 0 ICMP address mask query is used for

systems that need the local subnet mask
• Request 18 0 from a bootstrap server.
• Reply Denying ICMP address mask request

messages can adversely affect diskless
systems.
Permitting ICMP address mask request

messages might allow others to fingerprint
the operating system of a host in your
network.
77
Table 16: ICMP Messages (Continued)
ICMP-DEST-UNREACH 3 0 ICMP destination unreachable error

message indicates that the destination host
is configured to reject the packets.
Codes 0, 1, 4, or 5 can be from a gateway.

Codes 2 or 3 can be from a host (RFC 792).
Denying ICMP destination unreachable

error messages can remove the assumption
that a host is up and running behind an SRX
Series device.
Permitting ICMP destination unreachable

error messages can allow some
assumptions, such as security filtering, to
be made about the network.
ICMP Fragment Needed 3 4 ICMP fragmentation error message

indicates that fragmentation is needed but
the don't fragment flag is set.
We recommend denying these messages

from the Internet to an internal network.
ICMP FragmentReassembly 11 1 ICMP fragment reassembly time exceeded

error indicates that a host reassembling a
fragmented message ran out of time and
dropped the packet. This message is
sometimes sent.

from the Internet (external) to the trusted
(internal) network.
78
ICMP-HOST-UNREACH 3 1 ICMP host unreachable error messages

indicate that routing table entries do not
list or list as infinity a particular host.
Sometimes this error is sent by gateways
that cannot fragment when a packet
requiring fragmentation is received.

from the Internet to a trusted network.
Permitting these messages allows others to

be able to determine your internal hosts IP
addresses by a process of elimination or
make assumptions about gateways and
fragmentation.
ICMP-INFO 15 0 ICMP-INFO query messages allow diskless

host systems to query the network and
• Request 16 0 self-configure.
• Reply Denying ICMP address mask request

messages can adversely affect diskless
systems.
Permitting ICMP address mask request

messages might allow others to broadcast
information queries to a network segment
to determine computer type.
ICMP-PARAMETER-PROBLEM 12 0 ICMP parameter problem error messages

notify you when incorrect header
parameters are present and have caused a
packet to be discarded

Permitting ICMP parameter problem error

messages allows others to make
assumptions about your network.
79
ICMP-PORT-UNREACH 3 3 ICMP port unreachable error messages

indicate that gateways processing
datagrams requesting certain ports are
unavailable or unsupported in the network.

Permitting ICMP port unreachable error

messages can allow others to determine
which ports you use for certain protocols.
ICMP-PROTOCOL-UNREACH 3 2 ICMP protocol unreachable error messages

indicate that gateways processing
datagrams requesting certain protocols are
unavailable or unsupported in the network.

Permitting ICMP protocol unreachable

error messages can allow others to
determine what protocols your network is
running.
ICMP-REDIRECT 5 0 ICMP redirect network error messages are

sent by an SRX Series device.

ICMP-REDIRECT-HOST 5 1 ICMP redirect messages indicate datagrams

destined for the specified host to be sent
along another path.
ICMP-REDIRECT-TOS-HOST 5 3 ICMP redirect type of service (TOS) and

host error is a type of message.
80
ICMP-REDIRECT-TOS-NET 5 2 ICMP redirect TOS and network error is a

type of message.
ICMP-SOURCE-QUENCH 4 0 ICMP source quench error message

indicates that a device does not have the
buffer space available to accept, queue, and
send the packets on to the next hop.
Denying these messages will not help or

impair internal network performance.
Permitting these messages can allow others

to know that a device is congested, making
it a viable attack target.
ICMP-SOURCE-ROUTE-FAIL 3 5 ICMP source route failed error message

from the Internet (external).
ICMP-TIME-EXCEEDED 11 0 ICMP time-to-live (TTL) exceeded error

message indicates that a packet's TTL
setting reached zero before the packet
reached its destination. This ensures that
older packets are discarded before resent
ones are processed.

from a trusted network out to the Internet.
ICMP-TIMESTAMP 13 0 ICMP-TIMESTAMP query messages

provide the mechanism to synchronize time
• Request 14 0 and coordinate time distribution in a large,
diverse network.
• Reply
81
Ping (ICMP ECHO) 8 0 Ping is a utility to determine whether a

specific host is accessible by its IP address.
Denying ping functionality removes your

ability to check to see if a host is active.
Permitting ping can allow others to execute

a denial-of-service (DoS) or Smurf attack.
ICMP-ECHO-FRAGMENT-ASSEMBLY- 11 1 ICMP fragment echo reassembly time

EXPIRE expired error message indicates that the
reassembly time was exceeded.
We recommend denying these messages.
Traceroute 30 0 Traceroute is a utility to indicate the path to

access a specific host.
• Forward 30 1
We recommend denying this utility from
• Discard the Internet (external) to your trusted
network (internal).
Default Behavior of ICMP Unreachable Errors
For different levels of security, the default behavior for ICMP unreachable errors is handled as follows:
• Sessions are closed for ICMP type-3, code-0, code-1, code-2, and code-3 messages only when the
following conditions are met:
• The ICMP unreachable message is received in the server–to-client direction.
• No normal packet is received in the server-to-client direction.
Otherwise, sessions do not close.
• Sessions do not close for ICMP type-3, code-4 messages.

82
Example: Defining a Custom ICMP Application
IN THIS SECTION
Requirements | 82
Overview | 82
Configuration | 83
Verification | 84
This example shows how to define a custom ICMP application.
Requirements
Before you begin:
• Understand custom policy application. See "Understanding Custom Policy Applications" on page 85.
• Understand the ICMP predefined policy application. See "Understanding ICMP Predefined Policy
Applications" on page 75.
Overview
Junos OS supports ICMP—as well as several ICMP messages—as predefined or custom applications.
When configuring a custom ICMP application, you define a type and code.
• There are different message types within ICMP. For example:
• type 0 = Echo Request message
• type 3 = Destination Unreachable message
• An ICMP message type can also have a message code. The code provides more specific information
about the message, as shown in Table 17 on page 82.
Table 17: Message Descriptions
Message Type Message Code
5 = Redirect 0 = Redirect datagram for the network (or subnet)

83
Table 17: Message Descriptions (Continued)
Message Type Message Code
1 = Redirect datagram for the host
2 = Redirect datagram for the type of application and network
3 = Redirect datagram for the type of application and host
11 = Time Exceeded Codes 0 = Time to live exceeded in transit
1 = Fragment reassembly time exceeded
Junos OS supports any type or code within the range of 0 through 55 .
In this example, you define a custom application named host-unreachable using ICMP as the transport
protocol. The type is 3 (for destination unreachable) and the code is 1 (for host unreachable). You set the
timeout value at 4 minutes.
NOTE: For more information about ICMP types and codes, refer to RFC 792, Internet Control
Message Protocol.
Configuration
IN THIS SECTION
Procedure | 84
84
Procedure
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User
Guide.
To define a custom ICMP application:
1. Set the application type and code.
[edit applications application host-unreachable]

user@host# set icmp-type 5 icmp-code 0
2. Set the inactivity timeout value.
[edit applications application host-unreachable]

[edit]
user@host# commit
Verification
To verify the configuration is working properly, enter the show applications command.

85
Custom Policy Applications
IN THIS SECTION
Custom Application Mappings | 85
Example: Adding and Modifying Custom Policy Applications | 86
Example: Configuring Custom Policy Application Term Options | 89
Custom policy application is an alternate feature for predefined policy applications. If you do not want
to use predefined policy applications in your policy, you can create custom applications. Junos OS allows
you to configure custom applications for your policy.
Understanding Custom Policy Applications
If you do not want to use predefined applications in your policy, you can easily create custom
applications.
You can assign each custom application the following attributes:
• Name
• Transport protocol
• Source and destination port numbers for applications using TCP or UDP
• Type and code values for applications using ICMP
• Timeout value
Custom Application Mappings
The application option specifies the Layer 7 application that maps to the Layer 4 application that you
reference in a policy. A predefined application already has a mapping to a Layer 7 application. However,
86
for custom applications, you must link the application to a policy explicitly, especially if you want the
policy to apply an Application Layer Gateway (ALG) or deep inspection to the custom application.
NOTE: Junos OS supports ALGs for numerous applications, including DNS, FTP, H.323, HTTP,
RSH, SIP, Telnet, and TFTP.
Applying an ALG to a custom application involves the following two steps:
• Define a custom application with a name, timeout value, transport protocol, and source and
destination ports.
• When configuring a policy, reference that application and the application type for the ALG that you
want to apply.
Example: Adding and Modifying Custom Policy Applications
IN THIS SECTION
Requirements | 86
Overview | 86
Configuration | 87
Verification | 88
This example shows how to add and modify custom policy applications.
Requirements
Before you begin, create addresses and security zones. See "Example: Creating Security Zones" on page
9.
Overview
In this example, you create a custom application using the following information:
• A name for the application: cust-telnet.
• A range of source port numbers: 1 through 65535.

87
• A destination port number: 23000.
• The protocol used by the application: TCP.
Once the custom application cust-telnet is created the following information is modified:
• The protocol used by the application is modified to : TCP.
• A range of source port numbers: 1 through 51100.
• A destination port number: 11000.
Configuration
IN THIS SECTION
Procedure | 87
Procedure
The following example requires you to navigate through various levels in the configuration hierarchy. For
instructions on how to do that, see Using the CLI Editor in Configuration Mode.
To add and modify a custom policy application:
1. Configure TCP and specify the source port and destination port.
[edit applications application cust-telnet]

user@host# set protocol tcp source-port 65535 destination-port 23000
2. Specify the length of time that the application is inactive.
[edit applications application cust-telnet]

3. Modify the custom policy application cust-telnet :
• Delete the source and destination ports configured for TCP.

88
• Configure UDP and specify the source port and destination port.
• Specify the length of time that UDP is inactive.
[edit]
user@host# delete applications application cust-telnet source-port
user@host# delete applications application cust-telnet destination-port
user@host# set applications application cust-telnet protocol udp source-port 51100
destination-port 11000
[edit]
user@host# commit
Verification
IN THIS SECTION
Verifying The Modified Custom Policy Application | 88
Verifying The Modified Custom Policy Application
Purpose
To verify if the custom policy application has been modified successfully.
Action
From operational mode, enter the show applications application cust-telnet command to display the details
of the custom policy application - cust-telnet.
user@host> show applications application cust-telnet
protocol udp;
source-port 51100;
89
destination-port 11000;
inactivity-timeout 1500;
NOTE: The timeout value is in seconds. If you do not set it, the timeout value of a custom
application is 1800 seconds. If you do not want an application to time out, type never.
Meaning
The output displays information about the cust-telnet application. Verify the following information:
• Configured policy name.
• Source and destination ports.
• Length of time (in seconds) that the application is inactive.
SEE ALSO

Example: Configuring Custom Policy Application Term Options
IN THIS SECTION
Requirements | 90
Overview | 90
Configuration | 90
Verification | 93
This example shows how to configure applications properties and term options for application protocols.
90
Requirements
• A PC
Before you begin:
• Configure the required applications. See "Example: Adding and Modifying Custom Policy
Applications" on page 86 .
Overview
In this example, you create an application name, app-name, and a term called custom-options to define
your custom policy application term options.
You configure Domain Name Service (DNS) as the Application Layer Gateway (ALG) type and UDP as
the networking protocol type. You set the source port to 24000 and the destination port to 23000.
Then you set the Internet Control Message Protocol (ICMP) packet type value to 5 and the ICMP code
value to 0. You set the remote procedure call (RPC) program number value to 50 and the Universal
Unique Identifier (UUID) value to 1be617c0-31a5-11cf-a7d8-00805f48a135. Finally, you set the
inactivity-timeout value to 60.
Configuration
IN THIS SECTION
Procedure | 90
Procedure
user@host# set applications application app-name term custom-options

user@host# set applications application app-name term custom-options alg dns
91
user@host#set applications application app-name term custom-options protocol udp

user@host#set applications application app-name term custom-options source-port 24000
user@host#set applications application app-name term custom-options destination-port 23000
user@host#set applications application app-name term custom-options icmp-type 5
user@host#set applications application app-name term custom-options icmp-code 0
user@host#set applications application app-name term custom-options rpc-program-number 50
user@host#set applications application app-name term custom-options uuid 1be617c0-31a5-11cf-
a7d8-00805f48a135
user@host#set applications application app-name term custom-options inactivity-timeout 60
To configure custom policy application term options:
1. Configure the term name.
[edit applications]
user@host# set application app-name term custom-options
2. Configure the ALG type.
[edit applications]
user@host# set application app-name term custom-options alg dns
3. Configure the networking protocol type.
[edit applications]
user@host# set application app-name term custom-options protocol udp
4. Configure the source port number.
[edit applications]
user@host#set application app-name term custom-options source-port 24000
92
5. Configure the TCP or UDP destination port number.
[edit applications]
user@host# set application app-name term custom-options destination-port 23000
6. Specify the application type value.
[edit applications]
user@host# set application app-name term custom-options icmp-type 5
7. Specify the application code value.
[edit applications]
user@host# set application app-name term custom-options icmp-code 0
8. Specify the RPC program number.
[edit applications]
user@host# set application app-name term custom-options rpc-program-number 50
9. Specify the UUID value.
[edit applications]
user@host# set application app-name term custom-options uuid 1be617c0-31a5-11cf-
a7d8-00805f48a135
10. Specify the inactivity timeout value.
[edit applications]
user@host# set application app-name term custom-options inactivity-timeout 60
93
Results
From configuration mode, confirm your configuration by entering the show applications command. If the
output does not display the intended configuration, repeat the configuration instructions in this example
to correct it.
[edit]
user@host# show applications
application app-name {
term custom-options alg dns protocol udp source-port 24000 icmp-type 5 icmp-code 0 rpc-
program-number 50 uuid 1be617c0-31a5-11cf-a7d8-00805f48a135 inactivity-timeout 60;
}
Verification
IN THIS SECTION
Verifying the Configuration | 93
Verifying the Configuration
Purpose
Verify that the configuration is correct.
Action
From operational mode, enter the show applications command.
user@host> show applications

application app-name {
term custom-options alg dns protocol udp source-port 24000 icmp-type 5 icmp-code 0 rpc-
program-number 50 uuid 1be617c0-31a5-11cf-a7d8-00805f48a135 inactivity-timeout 60;
}
94

5 CHAPTER
Security Policies
Reordering Security Policies | 222
Scheduling Security Policies | 226
Threat Profiling Support in Security Policy | 233
Configuring Security Policies for a VRF Routing Instance | 234
Configuring Security Policies Using VRF Group | 267

96
Configuring Security Policies
IN THIS SECTION
Understanding Security Policies for Self Traffic | 101
Configuring Policies Using the Firewall Wizard | 106
Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic | 119
Example: Configuring a Security Policy to Redirect Traffic Logs to an External System Log Server | 124
TAP Mode for Security Zones and Policies | 128
Dynamic Address Groups in Security Policies | 134
Configure Security Policies for VXLAN | 141
To secure a network, a network administrator must create a security policy that outlines all of the
network resources within that business and the required security level for those resources. Junos OS
allows you to configure security policies. Security policies enforce rules for transit traffic, in terms of
what traffic can pass through the firewall, and the actions that need to take place on traffic as it passes
through the firewall.
Understanding Security Policy Elements
A security policy is a set of statements that controls traffic from a specified source to a specified
destination using a specified service. A policy permits, denies, or tunnels specified types of traffic
unidirectionally between two points.
Each policy consists of:
• A unique name for the policy.

97
• A from-zone and a to-zone, for example: user@host# set security policies from-zone untrust to-zone untrust
• A set of match criteria defining the conditions that must be satisfied to apply the policy rule. The
match criteria are based on a source IP address, destination IP address, and applications. The user
identity firewall provides greater granularity by including an additional tuple, source-identity, as part
of the policy statement.
• A set of actions to be performed in case of a match—permit, deny, or reject.
• Accounting and auditing elements—counting, logging, or structured system logging.
If the SRX Series receives a packet that matches those specifications, it performs the action specified in
the policy.
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. Actions for traffic matching
the specified criteria include permit, deny, reject, log, or count.
For SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices, a factory default security
policy is provided that:
• permits all traffic from the trust zone to the trust zone.
• denies all traffic from the untrust zone to the trust zone.
• allows all traffic from the trust zone to the untrust zone.
Understanding Security Policy Rules
IN THIS SECTION
Understanding Wildcard Addresses | 100
The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone).
Each policy is uniquely identified by its name. The traffic is classified by matching its source and
destination zones, the source and destination addresses, and the application that the traffic carries in its
protocol headers with the policy database in the data plane.
Each policy is associated with the following characteristics:
• A source zone
98
• A destination zone
• One or many source address names or address set names
• One or many destination address names or address set names
• One or many application names or application set names
These characteristics are called the match criteria. Each policy also has actions associated with it: permit,
deny, reject, count, log, and VPN tunnel. You have to specify the match condition arguments when you
configure a policy, source address, destination address, and application name.
You can specify to configure a policy with IPv4 or IPv6 addresses using the wildcard entry any. When
flow support is not enabled for IPv6 traffic, any matches IPv4 addresses. When flow support is enabled
for IPv6 traffic, any matches both IPv4 and IPv6 addresses. To enable flow-based forwarding for IPv6
traffic, use the set security forwarding-options family inet6 mode flow-based command. You can also specify
the wildcard any-ipv4 or any-ipv6 for the source and destination address match criteria to include only
IPv4 or only IPv6 addresses, respectively.
When flow support for IPv6 traffic is enabled, the maximum number of IPv4 or IPv6 addresses that you
can configure in a security policy is based on the following match criteria:
• Number_of_src_IPv4_addresses + number_of_src_IPv6_addresses * 4 <= 1024
• Number_of_dst_IPv4_addresses + number_of_dst_IPv6_addresses * 4 <= 1024
Thr reason for the match criteria is that an IPv6 address uses four times the memory space that an IPv4
address uses.
NOTE: You can configure a security policy with IPv6 addresses only if flow support for IPv6
traffic is enabled on the device.
If you do not want to specify a specific application, enter any as the default application. To look up the
default applications, from configuration mode, enter show groups junos-defaults | find applications
(predefined applications). For example, if you do not supply an application name, the policy is installed
with the application as a wildcard (default). Therefore, any data traffic that matches the rest of the
parameters in a given policy would match the policy regardless of the application type of the data traffic.
NOTE: If a policy is configured with multiple applications, and more than one of the applications
match the traffic, then the application that best meets the match criteria is selected.
The action of the first policy that the traffic matches is applied to the packet. If there is no matching
policy, the packet is dropped. Policies are searched from top to bottom, so it is a good idea to place more
99
specific policies near the top of the list. You should also place IPsec VPN tunnel policies near the top.
Place the more general policies, such as one that would allow certain users access to all Internet
applications, at the bottom of the list. For example, place deny-all or reject-all policies at the bottom
after all of the specific policies have been parsed before and legitimate traffic has been allowed/count/
logged.
NOTE: Support for IPv6 addresses is added in Junos OS Release 10.2. Support for IPv6
addresses in active/active chassis cluster configurations (in addition to the existing support of
active/passive chassis cluster configurations) is added in Junos OS Release 10.4.
Policies are looked up during flow processing after firewall filters and screens have been processed and
route look up has been completed by the Services Processing Unit (SPU) (for SRX5400, SRX5600, and
SRX5800 devices). Policy look up determines the destination zone, destination address, and egress
interface.
When you are creating a policy, the following policy rules apply:
• Security policies are configured in a from-zone to to-zone direction. Under a specific zone direction, each
security policy contains a name, match criteria, an action, and miscellaneous options.
• The policy name, match criteria, and action are required.
• The policy name is a keyword.
• The source address in the match criteria is composed of one or more address names or address set
names in the from-zone.
• The destination address of the match criteria is composed of one or more address names or address
set names in the to-zone.
• The application name in the match criteria is composed of the name of one or more applications or
application sets.
• One of the following actions is required: permit, deny, or reject.
• Accounting and auditing elements can be specified: count and log.
• You can enable logging at the end of a session with the session-close command, or at the beginning of
the session with the session-init command.
• When the count alarm is turned on, specify alarm thresholds in bytes per second or kilobytes per
minute.
• You cannot specify global as either the from-zone or the to-zone except under following condition:
100
Any policy configured with the to-zone as a global zone must have a single destination address to
indicate that either static NAT or incoming NAT has been configured in the policy.
• In SRX Series Services Gateways, the policy permit option with NAT is simplified. Each policy will
optionally indicate whether it allows NAT translation, does not allow NAT translation, or does not
care.
• Address names cannot begin with the following reserved prefixes. These are used only for address
NAT configuration:
• static_nat_
• incoming_nat_
• junos_
• Application names cannot begin with the junos_ reserved prefix.
Understanding Wildcard Addresses
Source and destination addresses are two of the five match criteria that should be configured in a
security policy. You can now configure wildcard addresses for the source and destination address match
criteria in a security policy. A wildcard address is represented as A.B.C.D/wildcard-mask. The wildcard
mask determines which of the bits in the IP address A.B.C.D should be ignored by the security policy
match criteria. For example, the source IP address 192.168.0.11/255.255.0.255 in a security policy
implies that the security policy match criteria can discard the third octet in the IP address (symbolically
represented as 192.168.*.11). Therefore, packets with source IP addresses such as 192.168.1.11 and
192.168.22.11 conform to the match criteria. However, packets with source IP addresses such as
192.168.0.1 and 192.168.1.21 do not satisfy the match criteria.
The wildcard address usage is not restricted to full octets only. You can configure any wildcard address.
For example, the wildcard address 192.168. 7.1/255.255.7.255 implies that you need to ignore only the
first 5 bits of the third octet of the wildcard address while making the policy match. If the wildcard
address usage is restricted to full octets only, then wildcard masks with either 0 or 255 in each of the
four octets only will be permitted.
NOTE: The first octet of the wildcard mask should be greater than 128. For example, a wildcard
mask represented as 0.255.0.255 or 1.255.0.255 is invalid.
A wildcard security policy is a simple firewall policy that allows you to permit, deny, and reject the traffic
trying to cross from one security zone to another. You should not configure security policy rules using
wildcard addresses for services such as Unified Threat Management (UTM).
101
NOTE: Only Intrusion and Prevention (IDP) for IPv6 sessions is supported for all SRX5400,
SRX5600, and SRX5800 devices. UTM for IPv6 sessions is not supported. If your current security
policy uses rules with the IP address wildcard any, and UTM features are enabled, you will
encounter configuration commit errors because UTM features do not yet support IPv6
addresses. To resolve the errors, modify the rule returning the error so that the any-ipv4 wildcard
is used; and create separate rules for IPv6 traffic that do not include UTM features.
Configuring wildcard security policies on a device affects performance and memory usage based on the
number of wildcard policies configured per from-zone and to-zone context. Therefore, you can only
configure a maximum of 480 wildcard policies for a specific from-zone and to-zone context.
SEE ALSO
Understanding Security Policies for Self Traffic
Security policies are configured on the devices to apply services to the traffic flowing through the
device. For example UAC and UTM policies are configured to apply services to the transient traffic.
Self-traffic or host traffic, is the host-inbound traffic; that is, the traffic terminating on the device or the
host-outbound traffic that is the traffic originating from the device. You can now configure policies to
apply services on self traffic. Services like the SSL stack service that must terminate the SSL connection
from a remote device and perform some processing on that traffic, IDP services on host-inbound traffic,
or IPsec encryption on host-outbound traffic must be applied through the security policies configured
on self-traffic.
When you configure a security policy for self-traffic, the traffic flowing through the device is first
checked against the policy, then against the host-inbound-traffic option configured for the interfaces
bound to the zone.
You can configure the security policy for self-traffic to apply services to self-traffic. The host-outbound
policies will work only in cases where the packet that originated in the host device goes through the
flow and the incoming interface of this packet is set to local.
The advantages of using the self-traffic are:
• You can leverage most of the existing policy or flow infrastructure used for the transit traffic.
102
• You do not need a separate IP address to enable any service.
• You can apply services or policies to any host-inbound traffic with the destination IP address of any
interface on the device.
NOTE: You can configure the security policy for self-traffic with relevant services only. For
example, it is not relevant to configure the fwauth service on host-outbound traffic, and gprs-gtp
services are not relevant to the security policies for self-traffic.
The security policies for the self traffic are configured under the new default security zone called the
junos-host zone. The junos-host zone will be part of the junos-defaults configuration, so users cannot
delete it. The existing zone configurations such as interfaces, screen, tcp-rst, and host-inbound-traffic
options are not meaningful to the junos-host zone. Therefore there is no dedicated configuration for the
junos-host zone.
NOTE: You can use host-inbound-traffic to control incoming connections to a device; however it
does not restrict traffic going out of the device. Whereas, junos-host-zone allows you to select
the application of your choice and also restrict outgoing traffic. For example, services like NAT,
IDP, UTM, and so forth can now be enabled for traffic going in or out of the SRX Series device
using junos-host-zone.
Security Policies Configuration Overview
You must complete the following tasks to create a security policy:
1. Create zones. See "Example: Creating Security Zones" on page 9.
2. Configure an address book with addresses for the policy. See "Example: Configuring Address Books
and Address Sets" on page 36.
3. Create an application (or application set) that indicates that the policy applies to traffic of that type.
See "Example: Configuring Security Policy Applications and Application Sets" on page 55.
4. Create the policy. See "Example: Configuring a Security Policy to Permit or Deny All Traffic" on page
107, "Example: Configuring a Security Policy to Permit or Deny Selected Traffic" on page 113, and
"Example: Configuring a Security Policy to Permit or Deny Wildcard Address Traffic" on page 119.
5. Create schedulers if you plan to use them for your policies. See "Example: Configuring Schedulers for
a Daily Schedule Excluding One Day" on page 227.
103
The Firewall Policy Wizard enables you to perform basic security policy configuration. For more
advanced configuration, use the J-Web interface or the CLI.
SEE ALSO
Best Practices for Defining Policies on SRX Series Devices
A secure network is vital to a business. To secure a network, a network administrator must create a
security policy that outlines all of the network resources within that business and the required security
level for those resources. The security policy applies the security rules to the transit traffic within a
context (from-zone to to-zone) and each policy is uniquely identified by its name. The traffic is classified
by matching the source and destination zones, the source and destination addresses, and the application
that the traffic carries in its protocol headers with the policy database in the data plane.
Table 18 on page 104 provides the policy limitations for SRX300, SRX320, SRX340, SRX345, SRX380,
SRX550, SRX650, SRX550M, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600,
SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your
installation.
NOTE: Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the
maximum number of address objects per policy for SRX5400, SRX5600, and SRX5800 devices
increases from 1024 to 4096, and the maximum number of policies per context increases from
10240 to 80,000.
Starting with Junos OS Release 17.3R1, the number of security policies and the maximum
number of policies per context for SRX5400, SRX5600, and SRX5800 devices increases from
80,000 to 100,000.
Starting with Junos OS Release 15.1X49-D120, the number of address objects per policy for
SRX5400, SRX5600, and SRX5800 increases from 4096 to 16,000.
104
Table 18: Policy Limitations for SRX Series Devices
SRX Series Address Application Security Policy Policies per Policies with
Devices objects objects policies contexts context counting
(zone pairs) enabled
SRX300 2048 128 1024 256 1024 256

SRX320
SRX340 2048 128 2048 512 2048 256
SRX345 2048 128 4096 1024 4096 256
SRX380 2048 128 4096 1024 4096 256
SRX550 1024 128 10240 2048 10240 1024

SRX650
SRX550M 2048 128 10240 2048 10240 1024
SRX1400 1024 3072 16000 4096 16000 1024

SRX1500
SRX3400 4096 3072 40000 4096 40000 1024

SRX3600
SRX4100 1024 3072 60000 4096 60000 1024
SRX4200 1024 3072 60000 4096 60000 1024
SRX4600 4096 3072 80000 8192 80000 1024
SRX5400 16000 3072 100000 8192 100000 1024

SRX5600
SRX5800
105
Therefore, as you increase the number of addresses and applications in each rule, the amount of
memory that is used by the policy definition increases, and sometimes the system runs out of memory
with fewer than 80,000 policies.
To get the actual memory utilization of a policy on the Packet Forwarding Engine (PFE) and the Routing
Engine (RE), you need to take various components of the memory tree into consideration. The memory
tree includes the following two components:
• Policy context–Used to organize all policies in this context. Policy context includes variables such as
source and destination zones.
• Policy entity–Used to hold the policy data. Policy entity calculates memory using parameters such as
policy name, IP addresses, address count, applications, firewall authentication, WebAuth, IPsec,
count, application services, and Junos Services Framework (JSF).
Additionally, the data structures used to store policies, rule sets, and other components use different
memory on the Packet Forwarding Engine and on the Routing Engine. For example, address names for
each address in the policy are stored on the Routing Engine, but no memory is allocated at the Packet
Forwarding Engine level. Similarly, port ranges are expanded to prefix and mask pairs and are stored on
the Packet Forwarding Engine, but no such memory is allocated on the Routing Engine.
Accordingly, depending on the policy configuration, the policy contributors to the Routing Engine are
different from those to the Packet Forwarding Engine, and memory is allocated dynamically.
Memory is also consumed by the “deferred delete” state. In the deferred delete state, when an SRX
Series device applies a policy change, there is transitory peak usage whereby both the old and new
policies are present. So for a brief period, both old and new policies exist on the Packet Forwarding
Engine, taking up twice the memory requirements.
Therefore, there is no definitive way to infer clearly how much memory is used by either component
(Packet Forwarding Engine or Routing Engine) at any given point in time, because memory requirements
are dependent on specific configurations of policies, and memory is allocated dynamically.
The following best practices for policy implementation enable you to better use system memory and to
optimize policy configuration:
• Use single prefixes for source and destination addresses. For example, instead of using /32 addresses
and adding each address separately, use a large subnet that covers most of the IP addresses you
require.
• Use application “any” whenever possible. Each time you define an individual application in the policy,
you can use an additional 52 bytes.
• Use fewer IPv6 addresses because IPv6 addresses consume more memory.
• Use fewer zone pairs in policy configurations. Each source or destination zone uses about 16,048
bytes of memory.
106
• The following parameters can change how memory is consumed by the bytes as specified:
• Firewall authentication–About 16 bytes or more (unfixed)
• Web authentication–About 16 bytes or more (unfixed)
• IPsec–12 bytes
• Application services–28 bytes
• Count–64 bytes
• Check memory utilization before and after compiling policies.
NOTE: The memory requirement for each device is different. Some devices support 512,000
sessions by default, and the bootup memory is usually at 72 to 73 percent. Other devices can
have up to 1 million sessions and the bootup memory can be up to 83 to 84 percent. In the
worst-case scenario, to support about 80,000 policies in the SPU, the SPU should boot with a
flowd kernel memory consumption of up to 82 percent, and with at least 170 megabytes of
memory available.
SEE ALSO

Configuring Policies Using the Firewall Wizard
The Firewall Policy Wizard enables you to perform basic security policy configuration on SRX300,
SRX320, SRX340, SRX345, SRX380, and SRX550M devices.. For more advanced configuration, use the
J-Web interface or the CLI.
To configure policies using the Firewall Policy Wizard:
1. Select Configure>Tasks>Configure FW Policy in the J-Web interface.

2. Click the Launch Firewall Policy Wizard button to launch the wizard.
3. Follow the prompts in the wizard.
107
The upper-left area of the wizard page shows where you are in the configuration process. The lower-left
area of the page shows field-sensitive help. When you click a link under the Resources heading, the
document opens in your browser. If the document opens in a new tab, be sure to close only the tab (not
the browser window) when you close the document.
Example: Configuring a Security Policy to Permit or Deny All Traffic
IN THIS SECTION
Requirements | 107
Overview | 107
Configuration | 109
Verification | 112
This example shows how to configure a security policy to permit or deny all traffic.
Requirements
Before you begin:
• Create zones. See "Example: Creating Security Zones" on page 9.
• Configure an address book and create addresses for use in the policy. See "Example: Configuring
Address Books and Address Sets" on page 36.
• Create an application (or application set) that indicates that the policy applies to traffic of that type.
Overview
IN THIS SECTION
Topology | 108
108
In the Junos OS, security policies enforce rules for transit traffic, in terms of what traffic can pass
through the device, and the actions that need to take place on traffic as it passes through the device.
From the perspective of security policies, the traffic enters one security zone and exits another security
zone. In this example, you configure the trust and untrust interfaces, ge-0/0/2 and ge-0/0/1. See Figure
4 on page 108.
Figure 4: Permitting All Traffic
This configuration example shows how to:
• Permit or deny all traffic from the trust zone to the untrust zone but block everything from the
untrust zone to the trust zone.
• Permit or deny selected traffic from a host in the trust zone to a server in the untrust zone at a
particular time.
Topology
109
Configuration
IN THIS SECTION
Procedure | 109
Procedure
set security zones security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services

all
set security zones security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-
services all
set security policies from-zone trust to-zone untrust policy permit-all match source-address any
set security policies from-zone trust to-zone untrust policy permit-all match destination-
address any
set security policies from-zone trust to-zone untrust policy permit-all match application any
set security policies from-zone trust to-zone untrust policy permit-all then permit
set security policies from-zone untrust to-zone trust policy deny-all match source-address any
set security policies from-zone untrust to-zone trust policy deny-all match destination-address
any
set security policies from-zone untrust to-zone trust policy deny-all match application any
set security policies from-zone untrust to-zone trust policy deny-all then deny
To configure a security policy to permit or deny all traffic:

110
1. Configure the interfaces and security zones.
[edit security zones]

user@host# set security-zone trust interfaces ge-0/0/2 host-inbound-traffic system-services
all
user@host# set security-zone untrust interfaces ge-0/0/1 host-inbound-traffic system-services
all
2. Create the security policy to permit traffic from the trust zone to the untrust zone.
[edit security policies from-zone trust to-zone untrust]

user@host# set policy permit-all match source-address any
user@host# set policy permit-all match destination-address any
user@host# set policy permit-all match application any
user@host# set policy permit-all then permit
3. Create the security policy to deny traffic from the untrust zone to the trust zone.
[edit security policies from-zone untrust to-zone trust]

user@host# set policy deny-all match source-address any
user@host# set policy deny-all match destination-address any
user@host# set policy deny-all match application any
user@host# set policy deny-all then deny
Results
From configuration mode, confirm your configuration by entering the show security policies and show
security zones commands. If the output does not display the intended configuration, repeat the
NOTE: The configuration example is a default permit-all from the trust zone to the untrust zone.
[edit]
policy permit-all {
match {
111
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone untrust to-zone trust {
policy deny-all {
match {
source-address any;
application any;
}
then {
deny;
}
}
}

interfaces {
ge-0/0/2.0 {
system-services {
all;
}
}
}
}
}
interfaces {
ge-0/0/1.0 {
system-services {
all;
}
112
}
}
}
}
Verification
IN THIS SECTION
Verifying Policy Configuration | 112
Verifying Policy Configuration
Purpose
Verify information about security policies.
Action
From operational mode, enter the show security policies detail command to display a summary of all
security policies configured on the device.
Meaning
The output displays information about policies configured on the system. Verify the following
information:
• From and to zones
• Source and destination addresses
• Match criteria
113
Example: Configuring a Security Policy to Permit or Deny Selected Traffic
IN THIS SECTION
Requirements | 113
Overview | 113
Configuration | 115
Verification | 118
This example shows how to configure a security policy to permit or deny selected traffic.
Requirements
Before you begin:
• Permit traffic to and from trust and untrust zones. See "Example: Configuring a Security Policy to
Permit or Deny All Traffic" on page 107.
Overview
In Junos OS, security policies enforce rules for the transit traffic, in terms of what traffic can pass
through the device, and the actions that need to take place on the traffic as it passes through the device.
From the perspective of security policies, the traffic enters one security zone and exits another security
114
zone. In this example, you configure a specific security policy to allow only e-mail traffic from a host in
the trust zone to a server in the untrust zone. No other traffic is allowed. See Figure 5 on page 114.
Figure 5: Permitting Selected Traffic

115
Configuration
IN THIS SECTION
Procedure | 115
Procedure

all
services all
set security address-book book1 address mail-untrust 203.0.113.14/24
set security address-book book1 attach zone untrust
set security address-book book2 address mail-trust 192.168.1.1/32
set security address-book book2 attach zone trust
set security policies from-zone trust to-zone untrust policy permit-mail match source-address
mail-trust
set security policies from-zone trust to-zone untrust policy permit-mail match destination-
address mail-untrust
set security policies from-zone trust to-zone untrust policy permit-mail match application junos-
mail
set security policies from-zone trust to-zone untrust policy permit-mail then permit
To configure a security policy to allow selected traffic:

116

all
all
2. Create address book entries for both the client and the server. Also, attach security zones to the
address books.

user@host# set address mail-untrust 203.0.113.14/24
user@host# set attach zone untrust

user@host# set address mail-trust 192.168.1.1/32
3. Define the policy to permit mail traffic.

user@host# set policy permit-mail match source-address mail-trust
user@host# set policy permit-mail match destination-address mail-untrust
user@host# set policy permit-mail match application junos-mail
user@host# set policy permit-mail then permit
Results
[edit]
policy permit-mail {
117
match {
source-address mail-trust;
destination-address mail-untrust;
application junos-mail;
}
then {
permit;
}
}
}

system-services {
all;
}
interfaces {
ge-0/0/2 {
system-services {
all;
}
}
}
}
}
interfaces {
ge-0/0/1 {
system-services {
all;
}
}
}
118
}
}

book1 {
address mail-untrust 203.0.113.14/24;
attach {
zone untrust;
}
}
book2 {
address mail-trust 192.168.1.1/32;
attach {
zone trust;
}
}
Verification
IN THIS SECTION
Purpose
Action
From operational mode, enter the show security policies detail command to display a summary of all
security policies configured on the device.
119
Meaning
The output displays information about policies configured on the system. Verify the following
information:
• From and to zones
• Match criteria
Example: Configuring a Security Policy to Permit or Deny Wildcard

Address Traffic
IN THIS SECTION
Requirements | 119
Overview | 120
Configuration | 120
Verification | 123
This example shows how to configure a security policy to permit or deny wildcard address traffic.
Requirements
Before you begin:
• Understand wildcard addresses. See "Understanding Security Policy Rules" on page 97.
• Permit traffic to and from trust and untrust zones. See "Example: Configuring a Security Policy to
Permit or Deny All Traffic" on page 107.
120
• Permit e-mail traffic to and from trust and untrust zones. See "Example: Configuring a Security Policy
to Permit or Deny Selected Traffic" on page 113
Overview
In the Junos operating system (Junos OS), security policies enforce rules for the transit traffic, in terms
of what traffic can pass through the device, and the actions that need to take place on the traffic as it
passes through the device. From the perspective of security policies, the traffic enters one security zone
and exits another security zone. In this example, you configure a specific security to allow only wildcard
address traffic from a host in the trust zone to the untrust zone. No other traffic is allowed.
Configuration
IN THIS SECTION
Procedure | 120
Procedure
commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.

all
services all
set security address-book book1 address wildcard-trust wildcard-address
192.168.0.11/255.255.0.255
set security address-book book1 attach zone trust
set security policies from-zone trust to-zone untrust policy permit-wildcard match source-
address wildcard-trust
set security policies from-zone trust to-zone untrust policy permit-wildcard match destination-
address any
set security policies from-zone trust to-zone untrust policy permit-wildcard match application
any
set security policies from-zone trust to-zone untrust policy permit-wildcard then permit
121
To configure a security policy to allow selected traffic:

all
all
2. Create an address book entry for the host and attach the address book to a zone.

user@host# set address wildcard-trust wildcard-address 192.168.0.11/255.255.0.255
3. Define the policy to permit wildcard address traffic.

user@host# set policy permit-wildcard match source-address wildcard-trust
user@host# set policy permit-wildcard match destination-address any
user@host# set policy permit-wildcard match application any
user@host# set policy permit-wildcard then permit
Results
[edit]
policy permit-wildcard {
122
match {
source-address wildcard-trust;
application any;
}
then {
permit;
}
}
}

system-services {
all;
}
interfaces {
ge-0/0/2 {
system-services {
all;
}
}
}
}
}
}
interfaces {
ge-0/0/1 {
system-services {
all;
}
}
}
}
}
book1 {
123
address wildcard-trust {
wildcard-address 192.168.0.11/255.255.0.255;
}
attach {
zone trust;
}
}
Verification
IN THIS SECTION
Purpose
Action
From operational mode, enter the show security policies policy-name permit-wildcard detail command to
display details about the permit-wildcard security policy configured on the device.
Meaning
The output displays information about the permit-wildcard policy configured on the system. Verify the
following information:
• From and To zones
• Match criteria
124
Example: Configuring a Security Policy to Redirect Traffic Logs to an

External System Log Server
IN THIS SECTION
Requirements | 124
Overview | 124
Configuration | 125
Verification | 128
This example shows how to configure a security policy to send traffic logs generated on the device to an
external system log server.
Requirements
• A client connected to an SRX5600 device at the interface ge-4/0/5
• A server connected to the SRX5600 device at the interface ge-4/0/1
The logs generated on the SRX5600 device are stored in a Linux-based system log server.
• An SRX5600 device connected to the Linux-based server at interface ge-4/0/4
No special configuration beyond device initialization is required before configuring this feature.
Overview
In this example, you configure a security policy on the SRX5600 device to send traffic logs, generated by
the device during data transmission, to a Linux-based server. Traffic logs record details of every session.
The logs are generated during session establishment and termination between the source and the
destination device that are connected to the SRX5600 device.
125
Configuration
IN THIS SECTION
Procedure | 125
Procedure
commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.
set security log source-address 127.0.0.1

set security log stream trafficlogs severity debug
set security log stream trafficlogs host 203.0.113.2
set security zones security-zone client host-inbound-traffic system-services all
set security zones security-zone client host-inbound-traffic protocols all
set security zones security-zone client interfaces ge-4/0/5.0
set security zones security-zone server host-inbound-traffic system-services all
set security zones security-zone server interfaces ge-4/0/4.0
set security zones security-zone server interfaces ge-4/0/1.0
set security policies from-zone client to-zone server policy match source-address any
set security policies from-zone client to-zone server policy match destination-address any
set security policies from-zone client to-zone server policy match application any
126
set security policies from-zone client to-zone server policy match then permit
set security policies from-zone client to-zone server policy match then log session-init
set security policies from-zone client to-zone server policy match then log session-close
To configure a security policy to send traffic logs to an external system log server:
1. Configure security logs to transfer traffic logs generated at the SRX5600 device to an external
system log server with the IP address 203.0.113.2. The IP address 127.0.0.1 is the loopback address
of the SRX5600 device.
[edit security log]

user@host# set source-address 127.0.0.1
user@host# set stream trafficlogs severity debug
user@host# set stream trafficlogs host 203.0.113.2
2. Configure a security zone and specify the types of traffic and protocols that are allowed on interface
ge-4/0/5.0 of the SRX5600 device.

user@host# set security-zone client host-inbound-traffic system-services all
user@host# set security-zone client host-inbound-traffic protocols all
user@host# set security-zone client interfaces ge-4/0/5.0
3. Configure another security zone and specify the types of traffic that are allowed on the interfaces
ge-4/0/4.0 and ge-4/0/1.0 of the SRX5600 device.

user@host# set security-zone server host-inbound-traffic system-services all
user@host# set security-zone server interfaces ge-4/0/4.0
user@host# set security-zone server interfaces ge-4/0/1.0
127
4. Create a policy and specify the match criteria for that policy. The match criteria specifies that the
device can allow traffic from any source, to any destination, and on any application.
[edit security policies from-zone client to-zone server]

user@host# set policy match source-address any
user@host# set policy match destination-address any
user@host# set policy match application any
user@host# set policy match then permit any
5. Enable the policy to log traffic details at the beginning and at the end of the session.
[edit security policies from-zone client to-zone server]

user@host# set policy match then log session-init
user@host# set policy match then log session-close
Results
From configuration mode, confirm your configuration by entering the show security log command. If the
to correct it.
[edit]
user@host# show security log
format syslog;
source-address 127.0.0.1;
stream trafficlogs {
severity debug;
host {
203.0.113.2;
}
}
If you are done configuring the device, enter commit from the configuration mode.
128
Verification
IN THIS SECTION
Verifying Zones | 128
Verifying Policies | 128
Verifying Zones
Purpose
Verify that the security zone is enabled or not.
Action
From operational mode, enter the show security zones command.
Verifying Policies
Purpose
Verify that the policy is working.
Action
From operational mode, enter the show security policies command on all the devices.
TAP Mode for Security Zones and Policies
IN THIS SECTION
Understanding TAP Mode Support for Security Zones and Policies | 129
129
Example: Configuring Security Zones and Policies in TAP mode | 129
The Terminal Access Point (TAP) mode for security zones and policy allows you to passively monitor
traffic flows across a network by way of a switch SPAN or mirror port.
Understanding TAP Mode Support for Security Zones and Policies

The Terminal Access Point (TAP) mode is a standby device, which checks the mirrored traffic through
switch. If security zones and policies are configured, then the TAP mode inspects the incoming and
outgoing traffic by configuring the TAP interface and generating a security log report to display the
number of threats detected and the user usage. If some packet gets lost in the tap interface, the security
zones and policies terminates the connection, as a result no report generates for this connection. The
security zone and policy configuration remains the same as non-TAP mode.
When you configure an SRX Series device to operate in TAP mode, the device generates security log
information to display the information on threats detected, application usage, and user details. When
the device is configured to operate in TAP mode, the SRX Series device receives packets only from the
configured TAP interface. Except the configured TAP interface, other interface are configured to normal
interface that is used as management interface or connected to the outside server. The SRX Series
device will generate security report or log according to the incoming traffic.
The security zone and default security policy will be configured after TAP interface is configured. You
can configure other zones or policies if required. If one interface is used to connect a server then the IP
address, routing-interface, and security configuration also need be configured.
NOTE: You can configure only one TAP interface when you operate the device in TAP mode.
Example: Configuring Security Zones and Policies in TAP mode
IN THIS SECTION
Requirements | 130
Overview | 130
Configuration | 130
Verification | 133
130
This example shows how to configure security zones, and policies when the SRX device is configured in
TAP (Terminal Access Point) mode.
Requirements
• Junos OS Release 19.1R1
Before you begin:
• Read the Understanding TAP Mode Support for Security Zones and Policies to understand how and
where this procedure fits in the overall support for Security Zones and Policies.
Overview
In this example, you configure the SRX Series device to operate in TAP mode. When you configure the
SRX Series device to operate in TAP mode, the device generates security log information to display the
information on threats detected, application usage, and user details.
Configuration
IN THIS SECTION
CLI Quick Configuration | 130
Procedure | 131
Results | 132
set security zones security-zone tap-zone interfaces ge-0/0/0.0

set security zones security-zone tap-zone application-tracking
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match source-address
131
any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match destination -
address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match application any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then permit
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-init
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-
close
Procedure
Guide.
To configure zones in TAP mode:
1. Configure security zone tap-zone interface.
user@host# set security zones security-zone tap-zone interfaces ge-0/0/0.0
2. Configure security zone tap-zone application-tracking.
user@host# set security zones security-zone tap-zone application-tracking
3. Configure security policy that permits traffic from zone tap-zone to zone tap-zone policy tap and
configure the match condition.
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match
source-address any
destination -address any
application any
user@host# set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then
permit
log session-init
132
log session-close
Results
From configuration mode, confirm your configuration by entering the show security zones and show security
policies commands. If the output does not display the intended configuration, repeat the instructions in
this example to correct the configuration.
[edit]
user@host#show security zones
security-zone tap-zone {
interfaces {
ge-0/0/0.0;
}
application-tracking;
}
[edit]
user@host#show security policies
from-zone tap-zone to-zone tap-zone {
policy tap-policy {
match {
source-address any;
application any;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
}
133
Verification
IN THIS SECTION
Verifying Policy Configuration in TAP Mode | 133
To confirm that the configuration is working properly, perform these tasks:
Verifying Policy Configuration in TAP Mode
Purpose
Action
From operational mode, enter the show security policies detail command.
user@host> show security policies detail

node0:
--------------------------------------------------------------------------
Default policy: permit-all
Pre ID default policy: permit-all
Policy: Trust_to_Untrust, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
Sequence number: 1
From zone: izone, To zone: ozone
Source addresses:
any-ipv4(global): 0.0.0.0/0
any-ipv6(global): ::/0
Destination addresses:
Application: any
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
134
Session log: at-create, at-close

Policy: Untrust_to_Trust, action-type: permit, State: enabled, Index: 5, Scope Policy: 0
Sequence number: 1
From zone: ozone, To zone: izone
Source addresses:
Application: any
Meaning
Displays a summary of all security policies configured on the device in TAP mode.
Dynamic Address Groups in Security Policies
IN THIS SECTION
Bundle Feeds | 138
Feed Server Support for SRX Series Devices | 140
Manually adding address entries into a policy can be time consuming. There are external sources that
provide lists of IP addresses that have a specific purpose (such as a blocklist) or that have a common
attribute (such as a particular location or behavior that might pose a threat). You can use the external
source to identify threat sources by their IP address, then group those addresses into a dynamic address
entry, and reference that entry in a security policy. Thereby you can control the traffic to and from those
addresses. Each such group of IP addresses is referred to as a dynamic address entry.
135
The following types of IP addresses are supported:
• Single IP. For example : 192.0.2.0
• IP range. For example : 192.0.2.0- 192.0.2.10
• CIDR. For example : 192.0.2.0/24
Each entry occupies one line. Starting in Junos OS Release 19.3R1, IP address ranges do not need to be
sorted in ascending order and the value of the IP entries can overlap in the same feed file. In Junos OS
Releases before 19.3R1, IP address ranges need to be sorted in ascending order and the value of the IP
entries cannot overlap in the same feed file.
NOTE: A dynamic address entry is a group of IP addresses, not a single IP prefix. A dynamic
address entry is different from the security address concepts of address books and address entry
addresses.
The following are the benefits of deploying dynamic address entries in security policies:
• The network administrator has more control over the traffic to and from groups of IP addresses.
• The external server provides updated IP address feeds to the SRX Series device.
• The administrator’s efforts are dramatically reduced. For example, in a legacy security policy
configuration, adding 1000 address entries for a policy to reference would require some 2000 lines
of configuration. By defining a dynamic address entry and referencing it in a security policy, up to
millions of entries could flow into the SRX Series device without much additional configuration
effort.
• No commit process is required to add new addresses. Adding thousands of addresses to a

configuration through a legacy method takes a long time to commit. Alternatively, IP addresses in a
dynamic address entry come from an external feed, so no commit process is required when the
addresses in an entry change.
136
Figure 6 on page 136 illustrates a functional overview of how the dynamic address entry in a security
policy works.
Figure 6: Functional Components of the Dynamic Address Entry in a Security Policy
A security policy references the dynamic address entry in a source address or destination address field
(in much the same way that a security policy references a legacy address entry).
137
Figure 7 on page 137 illustrates a policy that uses a dynamic address entry in the Destination-address
field.
Figure 7: A Dynamic Address Entry in a Security Policy
In Figure 7 on page 137, Policy 1 uses the destination address 10.10.1.1, which is a legacy security
address entry. Policy 2 uses the destination address Vendor blocklist, which is a dynamic address entry
named by the network administrator. Its content is the list of IP addresses retrieved from an external
feed file. Packets that match all five criteria (the From-zone named untrust, the To-zone named engineer,
any source address, a destination IP address that belongs to the Vendor blocklist dynamic address entry,
and the mail application) are handled according to the policy actions, which are to deny and log the
packet.
NOTE: The dynamic address entry names share the same name space as legacy security address
entries, so do not use the same name for more than one entry. The Junos OS commit process
checks that names are not duplicated to avoid a conflict.
Dynamic address groups support the following data feeds:
• Custom lists (allowlists and blocklists)
• GeoIP
• Feed Servers
138
Bundle Feeds
IP addresses, IP prefixes or IP ranges contained in a dynamic address entry can be updated periodically
by downloading an external feed. SRX Series devices periodically initiate a connection to the feed server
to download and update the IP lists which contain the updated dynamic addresses.
Starting in Junos OS Release 19.3R1, you can download a single tgz file from server and extract it into
multiple children feed files. Each individual file corresponds to one feed. Let individual dynamic-
addresses reference the feed inside the bundle file. The bundle file reduces the CPU overhead when too
many feeds are configured, where multiple child feeds are compressed into one .tgz file
The following bundle feed modes are supported:
Archive Mode
In the archive mode, you need to compress all feed files for the SRX Series device into one tgz file. The
SRX Series device downloads this file and extract all the feeds after extraction. This process is explained
below:
• When the feed server's url is a url of a file with the suffix .tgz instead of original url of folder, this
means this server uses a single file to carry all its feeds for SRX Series dynamic-address deployment.
In this case, feeds under this server inherit the update-interval or hold-interval from the server. Any
user configuration of the update-interval or hold-interval for this feed is ignored.
• After this change, follow the steps below to maintain server feeds as below example.
The example below shows the steps required to maintain the server feeds:
1. Place all feed files for the SRX Series device under the folder feeds-4-srx
2. Generate all feed files fd1 fd2 fd3 ..fdN in the folder feeds-4-srx
3. Add or remove the IP ranges from the feeds
4. Access the files by running the following command: cd feeds-4-srx;tar -zcvf ../feeds-4-srx.tgz *;cd-
• Post Step 4, the file feeds-4-srx.tgz is ready for download on the SRX Series device containing the
same folder which contains the feeds-4-srx.tgz file. After the download, the extracted files are placed
in the same folder as feeds-4-srx.tgz. The following example shows a samle configuration on an SRX
Series device:
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.tgz
set security dynamic-address feed-server server-4-srx feed-name feed1 path fd1
139
set security dynamic-address feed-server server-4-srx feed-name feed2 path.fd2

set security dynamic-address feed-server server-4-srx feed-name feed3 path fdN
The path parameter requires the relative path of the feed inside the bundle archive.
• If the tar -zxf feeds-4-srx.tgz file generates a folder feeds-4-srx and this folder holds the feed file fd1,
then use the following command to configure the feed:
[edit]
set security dynamic-address feed-server server-4-srx feed fd1 path feeds-4-srx/fd1
• If the tar -zxf feeds-4-srx.tgz file extracts the file fd1 directly, then use the following command to
configure the feed:
[edit]
set security dynamic-address feed-server server-4-srx feed fd1 path fd1
Flat File Mode
Flat file mode offers ultimate simplicity for user by introducing one syntax change in existing feed file
format. The content of all the feed files are compiled into a single file, with .bundle as a suffix. This
allows you to manage a single file. The SRX Series device classifies IP ranges in this bundle file into
numerous feed files. You can gzip this file as .bundle.gz if you can save some bandwidth for transmission.
In addition to file format defined earlier, an upper case tag FEED: followed by the feed name is
introduced. The lines below this tag are regarded as IP ranges belonging to the feed. An example of the
file format looks is given below:
root>cat feeds-4-srx.bundle
FEED:fd1
12.1.1.1-12.1.1.2
11.1.1.1-11.1.1.2
FEED:fd2
14.1.1.1-14.1.1.2
140
The configuration on an SRX Series device is similar to archive mode and is given below:
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle
set security dynamic-address feed-server server-4-srx feed-name fd1 path fd1
The difference between flat mode and archive mode is the file’s suffix and the layout inside the file. You
can select the mode that is most convenient for you.
As the feed files are in the plaintext format, gzip can reduce the file size. If a server and an SRX Series
device has WAN link in between, use a smaller sized file to be transmitted on the network, in this case,
gzip the bundle file and configure the following commands:
[edit]
set security dynamic-address feed-server server-4-srx url 10.170.40.50/feeds-4-srx.bundle.gz
Feed Server Support for SRX Series Devices
Table 19:
Platform Maximum Number of Feed Maximum Number of Feeds Maximum Number of Dynamic
Servers Addresses entries
SRX300 10 500 500

SRX320
SRX340
SRX345
SRX550
SRX550M
SRX650
141
SRX4100 100 5000 5000

SRX4200
SRX4600
SRX5400
SRX5600
SRX5800
vSRX
vSRX 3.0
SRX1500 40 2000 2000
SEE ALSO
url
Configure Security Policies for VXLAN
SUMMARY IN THIS SECTION
Use this example to configure security policies for Requirements | 141

EVPN (Ethernet VPN) Virtual Extensible LAN Overview | 142
(VXLAN) tunnel inspection.
Configuration | 143
Verification | 147
Requirements
VXLAN support on SRX series devices provides the flexibility to bring an enterprise grade firewall to
connect end points in their campus, data center, branch and public cloud environments while providing
embedded security.
• SRX4600 device
• Junos OS Release 20.4R1

142
Before you begin:
• Make sure you understand how EVPN and VXLAN works.
Overview
IN THIS SECTION
Topology | 143
The EVPN solution provides large enterprises a common framework used to manage their campus and
data center networks. An EVPN-VxLAN architecture supports efficient Layer 2 and Layer 3 network
connectivity with scale, simplicity, and agility. Figure 8 on page 143 shows an simplified VXLAN traffic
flow topology.
143
Topology
Figure 8: Simplified VXLAN Traffic Flow Topology
Configuration
IN THIS SECTION
Procedure | 144
Results | 146
144
set security zones security-zone cloud-1

set security zones security-zone dc
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 vni r1
set security tunnel-inspection inspection-profile ins-pf1 vxlan vx1 policy-set pset1
set security tunnel-inspection vni r1 vni-range 160 to 200
set security tunnel-inspection vni r2 vni-id 155
set security tunnel-inspection vni v1 vni-range 1 to 100
set security policies from-zone dc to-zone cloud-1 policy p1 match source-address any
set security policies from-zone dc to-zone cloud-1 policy p1 match destination-address any
set security policies from-zone dc to-zone cloud-1 policy p1 match application junos-vxlan
set security policies from-zone dc to-zone cloud-1 policy p1 then permit tunnel-inspection ins-
pf1
set security policies from-zone cloud-1 to-zone dc policy p1 match source-address any
set security policies from-zone cloud-1 to-zone dc policy p1 match destination-address any
set security policies from-zone cloud-1 to-zone dc policy p1 match application junos-vxlan
set security policies from-zone cloud-1 to-zone dc policy p1 then permit tunnel-inspection ins-
pf1
set security policies policy-set pset1 policy pset_p1 match source-address any
set security policies policy-set pset1 policy pset_p1 match destination-address any
set security policies policy-set pset1 policy pset_p1 match application any
set security policies policy-set pset1 policy pset_p1 then permit
set security policies default-policy deny-all
Procedure
Guide.
145
To configure VXLAN:
1. Define Security Zones.

user@host# set security-zone cloud-1
user@host# set zones security-zone dc
2. Define tunnel-inspection profile.
[edit security tunnel-inspection]

user@host# set inspection-profile ins-pf1 vxlan vx1 vni r1
user@host# set inspection-profile ins-pf1 vxlan vx1 policy-set pset1
user@host# set vni r1 vni-range 160 to 200
user@host# set vni r2 vni-id 155
user@host# set vni v1 vni-range 1 to 100
3. Define outer session policies.

user@host# set from-zone dc to-zone cloud-1 policy p1 match source-address any
user@host# set from-zone dc to-zone cloud-1 policy p1 match destination-address any
user@host# set from-zone dc to-zone cloud-1 policy p1 match application junos-vxlan
user@host# set from-zone dc to-zone cloud-1 policy p1 then permit tunnel-inspection profile-1
user@host# set from-zone cloud-1 to-zone dc policy p1 match source-address any
user@host# set from-zone cloud-1 to-zone dc policy p1 match destination-address any
user@host# set from-zone cloud-1 to-zone dc policy p1 match application junos-vxlan
user@host# set from-zone cloud-1 to-zone dc policy p1 then permit tunnel-inspection ins-pf1
4. Define policy-set.

user@host# set policy-set pset1 policy pset_p1 match source-address any
user@host# set policy-set pset1 policy pset_p1 destination-address any
146
user@host# set policy-set pset1 policy pset_p1 match application any

user@host# set policy-set pset1 policy pset_p1 then permit
user@host# set default-policy deny-all
Results
from-zone dc to-zone cloud-1 {

policy p1 {
match {
source-address any;
application junos-vxlan;
}
then {
permit {
tunnel-inspection {
ins-pf1;
}
}
}
}
}
from-zone cloud-1 to-zone dc {
policy p1 {
match {
source-address any;
application junos-vxlan;
}
then {
permit {
tunnel-inspection {
ins-pf1;
}
147
}
}
}
}
policy-set pset1 {
policy pset_p1 {
match {
source-address any;
application any;
}
then {
permit;
}
}
}
default-policy {
deny-all;
}
If you are done configuring the feature on your device, enter commit from configuration mode.
Verification
IN THIS SECTION
Verify tunnel inspection profiles and VNI | 147
Verify Safe Search Function | 149
Verify tunnel inspection profiles and VNI
Purpose
Verify that the tunnel inpection profile and VNI are confugured..
148
Action
From operational mode, enter the show security tunnel-inspection profiles ins-pf1 and show security tunnel-
inspection vnis commands.
user@host> show security tunnel-inspection profiles ins-pf1

node0:
--------------------------------------------------------------------------
Logical system: root-logical-system
Profile count: 1
Profile: ins-pf1
Type: VXLAN
Vxlan count: 1
Vxlan name: vx1
VNI count: 4
VNI:r1, r2, r3, r4
Policy set: pset1
Inspection level: 1
user@host> show security tunnel-inspection vnis

node0:
--------------------------------------------------------------------------
VNI count: 5
VNI name: r1
VNI id count: 1
[160 - 200]
VNI name: r2
VNI id count: 1
[155 - 155]
VNI name: r3
VNI id count: 1
[300 - 399]
VNI name: r4
VNI id count: 1
[100 - 120]
VNI name: v1
VNI id count: 1
[1 - 100]
149
Meaning
The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe
search rewrites.
Verify Safe Search Function
Purpose
Verify that the safe search feature is enabled for UTM Web filtering solutions.
Action
From operational mode, enter the Show security flow tunnel-inspection statistic command to view the
tunnel-inspection statistics.
user@host> show security flow tunnel-inspection statistics

node0:
--------------------------------------------------------------------------
Flow Tunnel-inspection statistics:

Tunnel-inspection statistics of FPC4 PIC1:
Tunnel-inspection type VXLAN:
overlay session active: 0
overlay session create: 269
overlay session close: 269
underlay session active: 0
underlay session create: 566
underlay session close: 566
input packets: 349717
input bytes: 363418345
output packets: 348701
output bytes: 363226339
bypass packets: 501
bypass bytes: 50890

150

bypass packets: 617
bypass bytes: 92902

bypass packets: 2038
bypass bytes: 270480
Tunnel-inspection statistics summary:

bypass packets: 3156
bypass bytes: 414272
node1:
--------------------------------------------------------------------------
Flow Tunnel-inspection statistics:

151

input packets: 0
input bytes: 0
output packets: 0
output bytes: 0
bypass packets: 0
bypass bytes: 0

input packets: 0
input bytes: 0
output packets: 0
output bytes: 0
bypass packets: 0
bypass bytes: 0

input packets: 0
input bytes: 0
output packets: 0
output bytes: 0
bypass packets: 0
152
bypass bytes: 0
Tunnel-inspection statistics summary:

input packets: 0
input bytes: 0
output packets: 0
output bytes: 0
bypass packets: 0
bypass bytes: 0
Meaning
The output displays that the VXLAN feature is enabled and there are no safe search redirects and safe
search rewrites.
SEE ALSO
tunnel-inspection
Release History Table

Release Description
17.3R1 Starting with Junos OS Release 17.3R1, the number of security policies and the maximum number
of policies per context for SRX5400, SRX5600, and SRX5800 devices increases from 80,000 to
100,000.
15.1X49-D120 Starting with Junos OS Release 15.1X49-D120, the number of address objects per policy for
SRX5400, SRX5600, and SRX5800 increases from 4096 to 16,000.
12.3X48-D15 Starting with Junos OS Release 12.3X48-D15 and Junos OS Release 17.3R1, the maximum
number of address objects per policy for SRX5400, SRX5600, and SRX5800 devices increases
from 1024 to 4096, and the maximum number of policies per context increases from 10240 to
80,000.
153
10.4 Support for IPv6 addresses in active/active chassis cluster configurations (in addition to the
existing support of active/passive chassis cluster configurations) is added in Junos OS Release
10.4.
10.2 Support for IPv6 addresses is added in Junos OS Release 10.2.
Security Zones | 7
Unified Security Policies
IN THIS SECTION
Configure a URL Category with Unified Policies | 170
Unified policies are the security policies that enable you to use dynamic applications as match
conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to
detect application changes over time.
154
Unified Policies Overview
IN THIS SECTION
Benefits | 154
Starting in Junos OS Release 18.2R1, unified policies are supported on SRX Series devices, allowing
granular control and enforcement of dynamic Layer 7 applications within the security policy.
Unified policies are the security policies that enable you to use dynamic applications as match
conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to
detect application changes over time. If the traffic matches the security policy rule, one or more actions
defined in the policy are applied to the traffic.
By adding dynamic applications to the match criteria, the data traffic is classified based on the Layer 7
application inspection results. AppID identifies dynamic or real-time Layer 4 through Layer 7
applications. After a particular application is identified and the matching policy is found, then the actions
are applied according to the policy.
Configuring dynamic applications as match criteria in a security policy is not mandatory.
Examples of configuring dynamic applications as a match condition within a security policy are as
follows:
• set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:FTP
• set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:HTTP
• set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:GOOGLE
Examples of configuring dynamic application groups as a match condition within a security policy are as
follows:
• set security policies from-zone trust to-zone untrust policy p1 match dynamic-application junos:p2p
• set security policies from-zone trust to-zone untrust policy p1 match dynamic-application junos:web:shopping
Benefits
• Simplifies application-based security policy management at Layer 7.
• Enables your device to adapt to the dynamic traffic changes in the network.
155
• Provides greater control and extensibility to manage dynamic applications traffic than a traditional
security policy.
Unified Policies Configuration Overview
IN THIS SECTION
Dynamic Application Configuration Options | 155
Default Ports and Protocols as Application Matching Criteria | 157
Default Policy Actions Prior to Dynamic Application Identification | 157
Global Policy Utilization with Unified Policies | 158
Unified Policy Actions | 159
Redirect Profile for Reject Action | 159
SSL Proxy Profile for Reject Action | 159
Match Criteria and Rules for Unified Policies | 161
Limitations to Configuring Unified Policies | 163
The following sections provide more information on unified policies:
Dynamic Application Configuration Options
Table 20 on page 156 provides options for configuring a unified policy with dynamic applications.
156
Table 20: Dynamic Application Configuration Options
Dynamic Application Description

Configuration
Options
Dynamic Specify dynamic applications or a dynamic application group.

Applications or
Examples are as follows:
Application Groups
• junos:FTP (dynamic application)
• junos:web:shopping (dynamic application group)
Any Configuring the dynamic application as any installs the policy with the application as a
wildcard (default). If an application cannot be specified, configure any as the default
application. Data traffic that match the parameters in a unified policy matches the policy
regardless of the application type.
None Configuring the dynamic application as none ignores classification results from AppID and
does not use the dynamic application in security policy lookups. Within the list of
potential match policies, if there is any policy configured with a dynamic application as
none, this policy is matched as the final policy and is terminal. If any Layer 7 services are
configured in this policy, deep packet inspection for the traffic is performed.
When upgrading the Junos OS release (where dynamic applications were not supported),
all existing traditional policies are considered to be policies with the dynamic application
configured as none.
Dynamic Application If a dynamic application is not configured within a security policy, the policy is
Not Configured considered to be a traditional security policy This policy is similar to a policy with the
dynamic application configured as none.
Starting in Junos OS Releases 19.4R1 and 20.1R1, security policy does not support using following
applications as dynamic-applications match criteria:
• junos:HTTPS
• junos:POP3S
• junos:IMAPS
• junos:SMTPS
157
Software upgrade to the Junos OS Releases 19.4R1 and 20.1R1 and later releases fails during the
validation if any of the security policies are configured with junos:HTTPS, junos:POP3S, junos:IMAPS,
junos:SMTPS as dynamic-applications as match criteria.
We recommend you to use therequest system software validate package-name option before upgrading to the
above mentioned releases.
We recommend you to remove any configuration that includes the dynamic-application junos:HTTPS,
junos:IMAPS, junos:SMTPS or junos:POP3S as match criteria in security policies.
Default Ports and Protocols as Application Matching Criteria
Starting in Junos OS Release 18.2R1, the junos-defaults option is introduced in the security policy
configuration as application match criteria. The junos-defaults group contains preconfigured statements
that include predefined values for common applications. As the default protocols and ports are inherited
from junos-defaults, there is no requirement to explicitly configure the ports and protocols, thus
simplifying the security policy configuration.
In the following example, the security policy L7-test-policy uses junos:HTTP as the dynamic application
and inherits destination TCP ports: 80, 3128, 8000, and 8080 as the application match criteria.
set security policies from-zone trust to-zone untrust policy L7-test-policy match application junos-defaults
dynamic-application junos:HTTP
If the application does not have default ports and protocols, then the application uses the default ports
and protocols of the dependent application. For example, junos:FACEBOOK-CHAT uses default
protocols and ports of HTTP2, HTTPS, and SPDY.
The junos-defaults option must be configured along with a dynamic application. If you configure the junos-
defaults option without specifying any dynamic application, then an error message displays and the
configuration commit fails. Use the show security policies detail command to validate the junos-defaults
option.
Default Policy Actions Prior to Dynamic Application Identification
Before an application is identified by Application Identification (AppID), the pre-id-default-policy options

are applied to the session. The session timeout value, along with the required mode of session logging,
are applied according to the pre-id-default-policy configuration. If there is no configuration within the pre-
id-default-policy stanza, the default session timeout values are applied to the session and no logs are
generated for the pre-id-default-policy.
158
We recommend that customers implement the set security policies pre-id-default-policy then log session-
close configuration, as shown below, in their own environments.
# show security policies pre-id-default-policy

then {
log {
session-close;
}
}
This configuration will ensure security logs are generated by the SRX if a flow is unable to leave the pre-
id-default-policy. These events are generally a result of JDPI being unable to properly classify traffic,
although they may also indicate potential attempts at evading the APPID engine.
In recent versions of Junos OS, the factory-default configuration of an SRX includes the session-close
configuration.
CAUTION: Configuring session-init logging for the pre-id-default-policy can generate a

large amount of logs. Each session that enters the SRX that initially matches the pre-id-
default-policy will generate an event. We recommend only using this option for
troubleshooting purposes.
Global Policy Utilization with Unified Policies
Zone-based security policies are prioritized over global policies when a policy lookup is implemented.
Starting in Junos OS Release 18.2R1, if a unified policy is configured within the zone-based security
policies, then global policy lookup is not performed. Prior to Junos OS Release 18.2R1, if no zone-based
policy is matched, then a global policy lookup is performed.
Starting in Junos OS Release 20.4R1, SRX Series devices support unified policies at both zone-context
and global-level policies at the same time. In previous releases, unified policies supported only zone-
context policies.
If the session matches any unified policy, either at a zone-level or at a global-level, then the policy is
added to potential policy match list. If the session does not match a policy at zone-level then the next
policy match occurs at the global-level. Global-level policies have the same match criteria as any other
security policy (example: source address, destination address, application, dynamic-application and so
on).
159
Unified Policy Actions
In a unified policy configuration, specify one of the following actions:
• Permit—Permit the traffic.
• Deny—Drop the traffic and close the session.
• Reject—Notify the client, drop the traffic, and close the session.
Redirect Profile for Reject Action
Unified policies log drop and reject actions. Unified policies do not notify connected clients for drop and
reject actions. The clients are unaware that the webpage is not accessible and might continue their
attempts to access it.
Starting in Junos OS Release 18.2R1, a redirect profile can be configured within a unified policy. When a
policy blocks HTTP or HTTPS traffic with a deny or reject action, you can define a response in the
unified policy to notify the connected clients.
To provide an explanation for the action or to redirect the client to an informative webpage, use the
redirect-message option at the [edit security dynamic-application profile name] hierarchy level with the reject
or deny action in a unified policy configuration to display a custom message.
When you configure the redirect option, you can specify the custom message or the URL to which the
client is redirected.
Limitations to Configuring a Redirect Profile in Unified Policies
There are limitations to configuring a redirect profile in unified policies. They include:
• Support for the redirect action with block messages with a redirect URL are not available for non-
HTTP or non-HTTPS applications.
• A unified policy does not check the validity and accessibility of a user-configured redirect URL.
• For clear text processing, out-of-order HTTP packets, or segmented HTTP requests, the available
policy actions are reject or deny. A redirect profile is not available.
• The redirect profile can be applied in unified policies only. The reject action for traditional security
policies do not support a redirect action with block message profiles or a redirect URL.
SSL Proxy Profile for Reject Action
Starting in Junos OS Release 18.2R1, you can configure a redirect profile within a unified policy. When a
policy blocks HTTP or HTTPS traffic with a deny or reject action, you can apply an SSL proxy profile to
160
the traffic. SSL proxy decrypts the traffic and application identification functionality identifies the
application. Next, you can take action to redirect or drop the traffic as per the configuration.
Consider the following example:
In this example, you are rejecting some of the Facebook applications such as chat, Farmville, and so on in
the policy ’policy-1’. As Facebook is an encrypted application, you need SSL proxy to decrypt the traffic
first.
policy policy-1 {
match {
source-address any;
application any;
dynamic-application [ junos:FACEBOOK-CHAT junos:FACEBOOK-FARMVILLE junos:FACEBOOK-MOBILE-
CHAT junos:FACEBOOK-SUPERPOKE junos:FACEBOOK-WINDOWSLIVEMESSENGER junos:FACEBOOK-VIDEO ];
}
then {
reject {
ssl-proxy {
profile-name test;
}
}
log {
session-init;
session-close;
}
}
}
In this example, the policy rejects the encrypted Facebook traffic and applies the configured SSL proxy
profile. The SSL proxy decrypts the traffic, and JDPI identifies the application.
Now the policy takes following actions based on your configuration:
• Redirects the client access to other URL, and closes the original session.
• Notifies the client with pre-defined text messages, and closes the session
• Closes the session only. In the example, the policy closes the session.
161
Match Criteria and Rules for Unified Policies
Unified Policy Implicit and Explicit Match
Starting in Junos OS Release 18.2R1, the command unified-policy-explicit-match is introduced at the [edit
security policies] hierarchy level. This command defines the explicit and implicit policy match behavior
and is disabled by default.
• Explicit match—If a dependent application does not have any matching policy, then the traffic is
dropped if explicit match is enabled. Only those security policies that are explicitly configured for the
application are applied.
• Implicit Match—If the dependent application does not have any matching policy, then the security
policy that is configured for the base application is applied.
By default, the unified policies enforce implicit rules on dependent applications.
In the example shown in Table 21 on page 161, the unified policy P3 is configured for FACEBOOK-
ACCESS traffic. HTTP is a dependent application of FACEBOOK-ACCESS and does not have any
security policy explicitly configured for it.
Table 21: Example of an Explicit and Implicit Policy Match for a Dependent Application
Dynamic Application Policy Configured
HTTP None
FACEBOOK-ACCESS P3
The results for implicit and explicit match behavior is shown in Table 22 on page 161.
Table 22: Example of a Policy Match ( Implicit and Explicit Match Criteria)
Application Policy Explicit or Result

Identified Matched Implicit Rule
Type
None P3 Implicit (Explicit The identified application is HTTP. There is no matching

is not Enabled) security policy configured for HTTP. The explicit match is not
enabled (implicit match), so traffic is further processed until
162
Table 22: Example of a Policy Match ( Implicit and Explicit Match Criteria) (Continued)
Application Policy Explicit or Result

Identified Matched Implicit Rule
Type
FACEBOOK-ACCESS is identified. The security policy that is

HTTP
configured for FACEBOOK-ACCESS (policy P3) is applied.
FACEBOOK-
ACCESS
HTTP None Explicit The identified application is HTTP. There is no matching

policy available for HTTP. The explicit match is enabled, so
no security policy is applied in this case.
Profile Overlap for Layer 7 Services
While using unified policies, if AppID results have not yet identified the final application, a policy search
might return a list of policies instead of a fixed policy. These policies are referred to as potential match
policies. Before the final application is identified, a conflict might occur due to multiple policy matches.
In this case, an appropriate profile or default profile is applied for services such as AppQoS, SSL proxy,
UTM, and IDP.
Policy Rematch
When the policy rematch option is enabled, the unified policy allows the device to reevaluate an active
session when its associated security policy is modified.
The session remains open if it continues to match the policy that allowed the session initially. The
session closes if its associated policy is renamed, deactivated, or deleted. Use the extensive option to
reevaluate an active session when its associated security policy is renamed, deactivated, or deleted.
If policy rematch is configured in a unified policy before a final match, then rematch behavior might lead
to a session closure. After the final match, a policy rematch triggers another policy lookup based on the
6-tuple match criteria and the final identified application.
Configure policy-rematch and the policy-rematch extensive options at the [edit security policies] hierarchy
level.
163
Limitations to Configuring Unified Policies
There are limitations to configuring unified policies. They include:
• An existing session might close in the following cases:
• When there is a change in the final match for the policy.
• When a new policy is inserted within the existing policies, and if this new policy is configured with
new services.
• When a final match policy enables new services after the session is created and before the final
match.
• Policy-based VPN is not supported for unified policies and can be applied only to the traditional
policy.
• ALGs are applied in one of the following conditions:
• Traditional security policy is configured.
• Unified policy is configured with dynamic application as none.
Configuring a dynamic application with junos:FTP triggers an FTP ALG to support UTM antivirus
scanning. See Enabling FTP Antivirus Scanning (CLI Procedure)
• A security policy that is configured with GPRS might not work if the policy is part of a potential
match list.
• A group VPN and user firewall authentication can be applied to a traditional security policy.
• Final policy match information might not be available within session-init logs for policies leveraging
dynamic applications.
SEE ALSO
Unified Policies Support for Flow
Understanding Unified Policies [Unified Threat Management (UTM)]
Overview of IDP Policy support for Unified Policies
164
Example: Configure a Unified Policy Using a Redirect Message Profile
IN THIS SECTION
Requirements | 164
Overview | 164
Configuration | 165
Verification | 167
This example describes how to configure a unified policy with a redirect message profile. In this example,
you configure a redirect profile with a redirect URL. You use the redirect profile as a block message in
the policy for traffic in the dynamic applications GMAIL and FACEBOOK-CHAT. Simultaneously, you
configure the application junos-defaults so that the default port and protocol from the dynamic
applications are inherited as the current policy’s destination port and protocol match criteria.
Requirements
• SRX Series device running Junos OS Release 18.2R1. This configuration example is tested with Junos
OS release 18.2R1.
Overview
In this example, you define the redirect profile as a response when a policy blocks HTTP or HTTPS
traffic with a deny or reject action. Through a redirect profile, you provide an explanation for the action
or you redirect the client request to an informative webpage when the reject or deny action is applied in
a security policy.
To accomplish these objectives, you perform the following tasks:
• Configure the redirect profile with a redirect URL such as http://abc.company.com/information/

block-message and use it in the policy as a block message.
• Configure the security policy match criteria source-address and destination-address with the value any.
165
• Configure the application with junos-defaults, so that the default port and protocol from dynamic-
application is inherited as the current policy’s destination port and protocol match criteria.
• Configure dynamic-application with [junos:GMAIL, junos:FACEBOOK-CHAT] so that the policy can apply the
block message profile on the applications.
Configuration
IN THIS SECTION
Procedure | 165
Results | 166
set security zones security-zone trust

set security zones security-zone untrust
set security dynamic-application profile profile1 redirect-message type redirect-url content
http://abc.company.com/information/block-message
set security policies from-zone trust to-zone untrust policy p2 match source-address any
set security policies from-zone trust to-zone untrust policy p2 match destination-address any
set security policies from-zone trust to-zone untrust policy p2 match application junos-defaults
set security policies from-zone trust to-zone untrust policy p2 match dynamic-application
[junos:GMAIL, junos:FACEBOOK-CHAT]
set security policies from-zone trust to-zone untrust policy p2 then reject profile profile1
Procedure
166
To configure a unified policy with a redirect message profile:
1. Configure security zones.
[edit security]
user@host# set security-zone trust
user@host# set security-zone untrust
2. Create a profile for the redirect message.
[edit security]
user@host# set dynamic-application profile profile1 redirect-message type redirect-url
content http://abc.company.com/information/block-message
3. Create a security policy with a dynamic application as the match criteria.

user@host# set from-zone trust to-zone untrust policy p2 match source-address any
user@host# set from-zone trust to-zone untrust policy p2 match destination-address any
user@host# set from-zone trust to-zone untrust policy p2 match application junos-defaults
user@host# set from-zone trust to-zone untrust policy p2 match dynamic-application junos:GMAIL
user@host# set from-zone trust to-zone untrust policy p2 match dynamic-application
junos:FACEBOOK-CHAT
4. Define the policy action.

user@host# set security policies from-zone trust to-zone untrust policy p2 then reject
profile profile1
Results
security dynamic-application commands. If the output does not display the intended configuration, repeat
[edit]
167

policy p2 {
match {
source-address any;
application junos-defaults;
dynamic-application [ junos:GMAIL, junos:FACEBOOK-CHAT ];
}
then {
reject {
profile profile1;
}
}
}
}
[edit]
user@host# show security dynamic-application
profile profile1 {
redirect-message {
type {
redirect-url {
content http://abc.company.com/information/block-message;
}
}
}
}
Verification
IN THIS SECTION
Verifying Unified Policy Configuration | 168

168
Verifying Unified Policy Configuration
Purpose
Verify that the unified policy configuration is correct.
Action
From operational mode, enter the show security policies command to display a summary of all security
policies on the device.
user@host> show security policies
Default policy: deny-all

Source addresses: any
Destination addresses: any
Applications: junos-defaults
Dynamic Applications: junos:GMAIL, junos:FACEBOOK-CHAT
dynapp-redir-profile: profile1
From operational mode, enter the show security policies detail command to display a detailed summary of
all security policies on the device.

Policy: p2, action-type: reject, State: enabled, Index: 4, Scope Policy: 0
Sequence number: 1
Source addresses:
169
Application: junos-defaults
Dynamic Application:
junos:GMAIL: 51
Meaning
The output displays information about all currently active security sessions on the device. Verify the
• Configured policy name
• Configured applications
• Configured dynamic applications
• Policy reject action

170
SEE ALSO

Configure a URL Category with Unified Policies
IN THIS SECTION
Understanding URL Category with Unified Policies | 170
Example: Configuring a Unified Policy Using URL Category | 171
Understanding URL Category with Unified Policies
IN THIS SECTION
Limitations of URL Category with Unified Policies | 170
Starting from Junos OS Release 18.4R1, the unified policies feature is enhanced to include URL
categories as match criteria for web filtering category. URL categories can be configured to unified
policies with or without dynamic-application been applied. .
When the URL category is configured as url-category any to a policy, the policy matches all categories of
traffic configured to the unified policies.
When the URL category is configured as url-category none to a policy, the URL category is not used in the
policy look-up. The unified policy configured with url-category none is considered as the highest priority to
policy match for a traffic. When the URL category to a policy is not configured, or when you upgrade a
device from previous release to latest release, the URL category of all the policies are considered as url-
category none.
Limitations of URL Category with Unified Policies
Using URL categories in an unified policy has the following limitation:

171
• Only the ports that are generally used such as HTTP and HTTPs traffics are supported by url-category.
Hence, the policy lookup supports HTTP and HTTPs traffics.
Example: Configuring a Unified Policy Using URL Category
IN THIS SECTION
Requirements | 171
Overview | 171
Configuration | 172
Verification | 174
This example describes how to configure a unified policy with a URL category.
Requirements
OS release 18.4R1.
Overview
In this example, URL category is added to security policy as match criteria for web filtering category.
To accomplish these objectives, you perform the following tasks:
• Configure the application with junos-defaults, so that the default port and protocol from dynamic-
application is inherited as the current policy’s destination port and protocol match criteria.
• Configure dynamic-application with [junos:GMAIL, junos:FACEBOOK-CHAT] so that the policy can apply the
block message profile on the applications.
• Configure url-category with Enhanced_News_and_Media as match criteria for web filtering category.
172
Configuration
IN THIS SECTION
Step-by-Step Procedure | 172
Results | 173

set security policies from-zone trust to-zone untrust policy p2 match application junos-defaults
[junos:GMAIL, junos:FACEBOOK-CHAT]
set security policies from-zone trust to-zone untrust policy p2 match url-category
Enhanced_News_and_Media
set security policies from-zone trust to-zone untrust policy p2 then reject profile profile1
To configure a unified policy with a redirect message profile:

173
[edit security]
2. Create a security policy with a URL category as the match criteria.

user@host# set from-zone trust to-zone untrust policy p2 match application junos-defaults
user@host# set from-zone trust to-zone untrust policy p2 match dynamic-application junos:GMAIL
user@host# set security policies from-zone trust to-zone untrust policy p2 match url-category
Enhanced_News_and_Media
user@host# set from-zone trust to-zone untrust policy p2 match dynamic-application
junos:FACEBOOK-CHAT

user@host# set security policies from-zone trust to-zone untrust policy p2 then reject
profile profile1
Results
security dynamic-application commands. If the output does not display the intended configuration, repeat
[edit]

policy p2 {
match {
174
source-address any;
application junos-defaults;
dynamic-application [ junos:GMAIL, junos:FACEBOOK-CHAT ];
url-category Enhanced_News_and_Media;
}
then {
reject {
profile profile1;
}
}
}
}
Verification
IN THIS SECTION
Purpose
Action

175
From zone: untrust, To zone: internet

Policy: ip1, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
Applications: junos-ping, junos-pingv6, junos-dns-udp, junos-dns-tcp
Action: permit, log
Policy: ip2, State: enabled, Index: 7, Scope Policy: 0, Sequence number: 2
Applications: junos-ping, junos-pingv6, junos-telnet, junos-dns-udp, junos-dns-tcp, junos-
ftp, junos-http, junos-https
Action: permit, log
From zone: untrust, To zone: trust
Policy: up3, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
Source addresses: H1, H1_v6
Destination addresses: H0, H0_v6
Applications: junos-ping, junos-telnet, junos-ftp, junos-http, junos-https, my_app_udp,
my_app_tcp
Dynamic Applications: junos:HTTP, junos:GOOGLE-GEN, junos:YAHOO, junos:SSL
Url-category: Enhanced_Search_Engines_and_Portals, cust_white
Action: permit, log
Policy: up4, State: enabled, Index: 9, Scope Policy: 0, Sequence number: 2
Source addresses: as1
Destination addresses: as0
Applications: junos-ping, junos-telnet, junos-ftp, junos-http, junos-https, my_app_udp,
my_app_tcp
Dynamic Applications: junos:web, junos:FTP
Url-category: Enhanced_Private_IP_Addresses, cust_white
Action: permit, log
Meaning
• Configured URL Category

176
• Policy reject action
Configure Applications in Unified Policies
IN THIS SECTION
Applications in Unified Policies | 176
Example: Configure a Unified Policy Using Dynamic Applications | 176
Applications in Unified Policies
Starting in Junos OS Release 19.1R1, configuring the application statement at the [edit security policies
from-zone zone-name to-zone zone-name policy policy-name match] hierarchy level is optional if the dynamic-
application statement is configured at the same hierarchy level.
In releases before Junos OS Release 19.1R1, it is mandatory to configure the application statement even
if the dynamic-application statement is configured.
• When the application option is defined then the defined application is used.
• When the application option is not defined and the dynamic-application option is defined as any, then the
application any is implicitly added.
• When the application option is not defined and the dynamic-application option is defined (and is not
configured as any), then the application junos-defaults is implicitly added.
Example: Configure a Unified Policy Using Dynamic Applications
IN THIS SECTION
Requirements | 177
Overview | 177
Configuration | 177
Verification | 179
177
This example describes how to configure a unified policy using dynamic applications.
Requirements
OS release 19.1R1.
Overview
In this example, dynamic applications are added to the security policy as match criteria.
To accomplish these objectives, perform the following tasks:
• Configure dynamic-application with [junos:CNN, junos:BBC] so that the policy can permit the applications
junos:CNN and junos:BBC.
Configuration
IN THIS SECTION
Step-by-Step Procedure | 178
Results | 179

178
junos:CNN
junos:BBC
set security policies from-zone trust to-zone untrust policy p3 then permit
To configure a unified policy using dynamic applications:
[edit security]
2. Create a security policy with a dynamic application as the match criteria.

user@host# set from-zone trust to-zone untrust policy p3 match dynamic-application junos:CNN
user@host# set from-zone trust to-zone untrust policy p3 match dynamic-application junos:BBC

user@host# set from-zone trust to-zone untrust policy p3 then permit
179
Results
[edit]

policy p3 {
match {
source-address any;
dynamic-application [ junos:CNN junos:BBC ];
}
then {
permit;
}
}
}
Verification
IN THIS SECTION
Purpose

180
Action

Dynamic Applications: junos:CNN, junos:BBC
Action: permit
From operational mode, enter the show security policies detail command to display a detailed summary of
all security policies on the device.

Sequence number: 1
Source addresses:
IP protocol: TCP, ALG: 0, Inactivity timeout: 1800
Destination ports: 80, 443, 3128, 8000, 8080
junos:BBC: 1754
junos:CNN: 988
181
Meaning
NOTE: The Applications field is autopopulated and its value junos-defaults is added implicitly.
• Policy action
SEE ALSO
Configure Micro-Applications in Unified Policies
IN THIS SECTION
Limit the Number of Policy Lookups | 182
Configure Micro-Applications | 182
Starting in Junos OS Release 19.2R1, you can configure micro-applications in a unified policy. Micro-
applications are sub-functions of an application. Micro-applications enable granular control of an
application at a sub-function level instead of blocking or allowing the entire application. By default,
detection of micro-applications is disabled.
The application identification (AppID) module detects an application at a sub-function level on your
network. Security policies leverage the application identity information determined by the AppID
module. After a specific application is identified, an action such as permit, deny, reject, or redirect is
182
applied to the traffic according to the policy configured on the device. You must enable detection of
micro-applications to use them in a security policy. See Enabling and Disabling Micro-Applications
Detection.
Limit the Number of Policy Lookups
To process a policy, the policy lookup must return the final match state for the application. When using a
micro-application, application classification does not reach the final match state because the micro-
application constantly changes for the session. Because the micro-application changes from one
transaction to another, an unlimited number of policy lookups is attempted.
Use the unified-policy max-lookups statement at the [edit security policies] hierarchy level to limit the
number of policy lookups.
Configure Micro-Applications
To permit a base-level application and all its dependent micro-applications, you can configure a unified
policy by specifying the base-level application as a matching criterion. You do not have to explicitly
specify each dependent application as matching criteria for the policy. For example, if you specify the
base-level application junos-MODBUS as a matching criterion in a unified policy, then you don't have to
configure the micro-applications of the junos-MODBUS application (junos:MODBUS-READ-COILS and
junos:MODBUS-WRITE-SINGLE-COIL) as matching criteria for the policy.
If you want to define a unified policy for granular-level control, then you must specify the micro-
applications of the base-level application as matching criteria for the policy. You must not define the
base-level application as match criteria in the policy. For more granular-level policy configuration,
specify junos:MODBUS-READ-COILS as matching criteria in a unified policy. Ensure that the base-level
application junos:MODBUS is not defined as as a matching criterion in the same unified policy.
Policy Lookup with Micro-Applications
Detection of micro-applications is disabled by default. To use micro-applications as matching criteria for

policy lookup, you must enable detection of micro-applications and then specify them as matching
criteria for the unified policy. If you have not enabled detection of micro-applications, the application
identification (AppID) module does not detect any micro-application and considers the base-level
application as the final matching criterion. For example, consider the base-level application
junos-:MODBUS that has two micro-applications junos:MODBUS-READ-COILS and junos:MODBUS-
WRITE-SINGLE-COIL:
• If you have not enabled detection of micro-applications, junos:MODBUS is considered as the final
match state for the AppID classification. If you enable micro-applications, then you can configure
them in a unified policy as any other pre-defined dynamic application. This micro-application is used
for policy lookup.
183
• If you have enabled detection of micro-applications, the AppID module considers junos:MODBUS as
the pre-match state. When the AppID module detects either junos:MODBUS-READ-COILS or
junos:MODBUS-WRITE-SINGLE-COIL, AppID considers this result as the final match state and
proceeds with policy lookup using this matching criterion.
SEE ALSO
Application Identification Support for Micro-Applications

Dynamic Application Classification States
Unified Policies Support for Flow

Understanding Unified Policies [Unified Threat Management (UTM)]
Overview of IDP Policy support for Unified Policies
Global Security Policies
IN THIS SECTION
A security policy is a stateful firewall policy and controls the traffic flow from one zone to another zone
by defining the kind(s) of traffic permitted from specific IP sources to specific IP destinations at
scheduled times. To avoid creating multiple policies across every possible context, you can create a
global policy that encompasses all zones, or a multizone policy that encompasses several zones. Using a
global policy, you can regulate traffic with addresses and applications, regardless of their security zones,
by referencing user-defined addresses or the predefined address and also provides access to multiple
source zones and multiple destination zones in one policy.
184
Global Policy Overview
In a Junos OS stateful firewall, security policies enforce rules for transit traffic, in terms of what traffic
can pass through the firewall, and the actions that need to take place on traffic as it passes through the
firewall. 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. Traffic is classified by
matching the policy’s from-zone, to-zone, source address, destination address, and the application that
the traffic carries in its protocol header. Each global policy, as with any other security policy, has the
following actions: permit, deny, reject, log, count.
You can configure a security policy from the user interface. Security policies control traffic flow from one
zone to another zone by defining the kind(s) of traffic permitted from specific IP sources to specific IP
destinations at scheduled times. This works well in most cases, but it is not flexible enough. For
example, if you want to perform actions on traffic you have to configure policies for each possible
context. To avoid creating multiple policies across every possible context, you can create a global policy
that encompasses all zones, or a multizone policy that encompasses several zones.
Using a global policy, you can regulate traffic with addresses and applications, regardless of their security
zones, by referencing user-defined addresses or the predefined address “any.” These addresses can span
multiple security zones. For example, if you want to provide access to or from multiple zones, you can
create a global policy with the address “any,” which encompasses all addresses in all zones. Selecting the
“any” address matches any IP address, and when “any” is used as a source/destination address in any
global policy configuration, it matches the source/destination address of any packet.
Using a global policy you can also provide access to multiple source zones and multiple destination
zones in one policy. However, we recommend that, for security reasons and to avoid spoofing traffic,
when you create a multizone policy you use identical matching criteria (source address, destination
address, application) and an identical action. In Figure 9 on page 185, for example, if you create a
185
multizone policy that includes DMZ and Untrust from-zones, spoofing traffic from 203.0.113.0/24 from
the DMZ zone could match the policy successfully and reach the protected host in the Trust to-zone.
Figure 9: Multizone Global Policy Security Consideration
NOTE: Global policies without from-zone and to-zone information do not support VPN tunnels
because VPN tunnels require specific zone information.
186
When policy lookup is performed, policies are checked in the following order: intra-zone (trust-to-trust),
inter-zone (trust-to-untrust), then global. Similar to regular policies, global policies in a context are
ordered, such that the first matched policy is applied to the traffic.
NOTE: If you have a global policy, make sure you have not defined a “catch-all” rule such as,
match source any, match destination any, or match application any in the intra-zone or inter-zone
policies because the global policies will not be checked. If you do not have a global policy, then it
is recommended that you include a “deny all” action in your intra-zone or inter-zone policies. If
you do have a global policy, then you should include a “deny all” action in the global policy.
In logical systems, you can define global policies for each logical system. Global policies in one logical
system are in a separate context than other security policies, and have a lower priority than regular
security policies in a policy lookup. For example, if a policy lookup is performed, regular security policies
have priority over global policies. Therefore, in a policy lookup, regular security policies are searched first
and if there is no match, global policy lookup is performed.
SEE ALSO

Example: Configuring a Global Policy with No Zone Restrictions
IN THIS SECTION
Requirements | 187
Overview | 187
Configuration | 188
Verification | 191
Unlike other security policies in Junos OS, global policies do not reference specific source and
destination zones. Global policies reference the predefined address “any” or user-defined addresses that
187
can span multiple security zones. Global policies give you the flexibility of performing actions on traffic
without any zone restrictions. For example, you can create a global policy so that every host in every
zone can access the company website, for example, www.example.com. Using a global policy is a
convenient shortcut when there are many security zones. Traffic is classified by matching its source
address, destination address, and the application that the traffic carries in its protocol header.
This example shows how to configure a global policy to deny or permit traffic.
Requirements
Before you begin:
• Review the firewall security policies.
See "Security Policies Overview" on page 2, "Global Policy Overview" on page 184, "Understanding
Security Policy Rules" on page 97, and"Understanding Security Policy Elements" on page 96.
• Configure an address book and create addresses for use in the policy.
See "Example: Configuring Address Books and Address Sets" on page 36.
Overview
IN THIS SECTION
Topology | 187
This configuration example shows how to configure a global policy that accomplishes what multiple
security policies (using zones) would have accomplished. Global policy gp1 permits all traffic while policy
gp2 denies all traffic.
Topology
188
Configuration
IN THIS SECTION
Procedure | 188
set security address-book global address server1 dns-name www.example.com

set security address-book global address server2 dns-name www.mail.example.com
set security policies global policy gp1 match source-address server1
set security policies global policy gp1 match destination-address server2
set security policies global policy gp1 match application any
set security policies global policy gp1 then permit
set security policies global policy gp2 match source-address server2
set security policies global policy gp2 match destination-address server1
set security policies global policy gp2 match application junos-ftp
set security policies global policy gp2 then deny
Procedure
To configure a global policy to permit or deny all traffic:

189
1. Create addresses.
[edit security]
user@host# set security address-book global address server1 dns-name www.example.com
user@host# set security address-book global address server2 dns-name www.mail.example.com
2. Create the global policy to permit all traffic.
[edit security]
user@host# set policy global policy gp1 match source-address server1
user@host# set policy global policy gp1 match destination-address server2
user@host# set policy global policy gp1 match application any
user@host# set policy global policy gp1 then permit
3. Create the global policy to deny all traffic.
[edit security]
user@host# set policy global policy gp2 match source-address server2
user@host# set policy global policy gp2 match destination-address server1
user@host# set policy global policy gp2 match application junos-ftp
user@host# set policy global policy gp2 then deny
Results
security policies global commands. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.

global {
policy gp1 {
match {
source-address server1;
destination-address server2;
application any;
}
then {
permit;
190
}
}
policy gp2 {
match {
application junos-ftp;
}
then {
deny;
}
}
}
user@host# show security policies global

policy gp1 {
match {
application any;
}
then {
permit;
}
}
policy gp2 {
match {
application junos-ftp;
}
then {
deny;
}
}
191
Verification
IN THIS SECTION
Verifying Global Policy Configuration | 191
Verifying Global Policy Configuration
Purpose
Verify that global policies gp1 and gp2 are configured as required.
Action
From operational mode, enter the show security policies global command.
user@host> show security policies global
Global policies:
Policy: gp1, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
From zones: any
To zones: any
Source addresses: server1
Destination addresses: server2
Applications: any
Action: permit
Policy: gp2, State: enabled, Index: 7, Scope Policy: 0, Sequence number: 2
From zones: any
To zones: any
Source addresses: server2
Destination addresses: server1
Applications: junos-ftp
Action: deny
Meaning
The output displays information about all the global policies configured on the device.
192
Example: Configuring a Global Policy with Multiple Zones
IN THIS SECTION
Requirements | 192
Overview | 192
Configuration | 193
Verification | 195
Unlike other security policies in Junos OS, global policies allow you to create multizone policies. A global
policy is a convenient shortcut when there are many security zones, because it enables you to configure
multiple source zones and multiple destination zones in one global policy instead of having to create a
separate policy for each from-zone/to-zone pair, even when other attributes, such as source-address or
destination-address, are identical.
Requirements
Before you begin:
• Review the firewall security policies.
See "Security Policies Overview" on page 2, "Global Policy Overview" on page 184, "Understanding
Security Policy Rules" on page 97, and "Understanding Security Policy Elements" on page 96.
• Create security zones.
See "Example: Creating Security Zones" on page 9
Overview
IN THIS SECTION
Topology | 193
193
This configuration example shows how to configure a global policy that accomplishes what multiple
security policies would have accomplished. Global policy Pa permits all traffic from zones 1 and 2 to
zones 3 and 4.
Topology
Configuration
IN THIS SECTION
Procedure | 193
set security policies global policy Pa match source-address any

set security policies global policy Pa match destination-address any
set security policies global policy Pa match application any
set security policies global policy Pa match from-zone zone1
set security policies global policy Pa match to-zone zone3
set security policies global policy Pa then permit
Procedure
instructions on how to do that, see Using the CLI Editor in Configuration Mode.
To configure a global policy with multiple zones:

194
1. Create a global policy to allow any traffic from zones 1 and 2 to zones 3 and 4.
[edit security]
set security policies global policy Pa match source-address any
set security policies global policy Pa match destination-address any
set security policies global policy Pa match application any
set security policies global policy Pa then permit
Results
From configuration mode, confirm your configuration by entering the show security policies global
command. If the output does not display the intended configuration, repeat the instructions in this
example to correct the configuration.
[edit]
user@host# show security policies global
policy Pa {
match {
source-address any;
application any;
from-zone [ zone1 zone2 ];
to-zone [ zone3 zone4 ];
}
then {
permit;
}
}
195
Verification
IN THIS SECTION
Verifying Global Policy Configuration | 195
Verifying Global Policy Configuration
Purpose
Verify that the global policy is configured as required.
Action
From operational mode, enter the show security policies global command.

User Role Firewall Security Policies
IN THIS SECTION
User Role Retrieval and the Policy Lookup Process | 197
Obtaining Username and Role Information Through Firewall Authentication | 206
Configuring a User Role Firewall For Captive Portal Redirection | 208

196
Configuring Resource Policies Using UAC | 219
User role firewall policies allows the administrators to permit or restrict network access for users based
on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more
informative forensic resources, improve record archiving for regulatory compliance, and enhance routine
access provisioning.
Understanding User Role Firewalls
Network security enforcement, monitoring, and reporting based solely on IP information soon will not
be sufficient for today’s dynamic and mobile workforce. By integrating user firewall policies,
administrators can permit or restrict network access of employees, contractors, partners, and other
users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide
more informative forensic resources, improve record archiving for regulatory compliance, and enhance
routine access provisioning.
User role firewalls trigger two actions:
• Retrieve user and role information associated with the traffic
• Determine the action to take based on six match criteria within the context of the zone pair
The source-identity field distinguishes a user role firewall from other types of firewalls. If the source
identity is specified in any policy for a particular zone pair, it is a user role firewall. The user and role
information must be retrieved before policy lookup occurs. If the source identity is not specified in any
policy, user and role lookup is not required.
To retrieve user and role information, authentication tables are searched for an entry with an IP address
corresponding to the traffic. If an entry is found, the user is classified as an authenticated user. If not
found, the user is classified as an unauthenticated user.
The username and roles associated with an authenticated user are retrieved for policy matching. Both
the authentication classification and the retrieved user and role information are used to match the
source-identity field.
Characteristics of the traffic are matched to the policy specifications. Within the zone context, the first
policy that matches the user or role and the five standard match criteria determines the action to be
applied to the traffic.
197
The following sections describe the interaction of user and role retrieval and the policy lookup process,
methods for acquiring user and role assignments, techniques for configuring user role firewall policies,
and an example of configuring user role firewall policies.
User Role Retrieval and the Policy Lookup Process
For policy lookup, firewall policies are grouped by zone pair (the from zone and to zone). Within the
context of the zone pair, IP-based firewall policies are matched to traffic based on five criteria—source
IP, source port, destination IP, destination port, and protocol.
User role firewall policies include a sixth match criteria—source identity. The source-identity field
specifies the users and roles to which the policy applies. When the source-identity field is specified in
any policy within the zone pair, user and role information must be retrieved before policy lookup can
proceed. (If all policies in the zone pair are set to any or have no entry in the source-identity field, user
and role information is not required and the five standard match criteria are used for policy lookup.)
The user identification table (UIT) provides user and role information for an active user who has already
been authenticated. Each entry in the table maps an IP address to an authenticated user and any roles
associated with that user.
When traffic requires user and role data, each registered UIT is searched for an entry with the same IP
address. If a user has not been authenticated, there is no entry for that IP address in the table. If no UIT
entry exists, the user is considered an unauthenticated user.
Policy lookup resumes after the user and role information has been retrieved. The characteristics of the
traffic are matched against the match criteria in the policies. The source-identity field of a policy can
specify one or more users or roles, and the following keywords:
authenticated-user Users that have been authenticated.
unauthenticated-user Users that have not been authenticated.
any All users regardless of authentication. If the source-identity field is not

configured or is set to any in all of the policies for the zone pair, only five criteria
are matched.
unknown-user Users unable to be authenticated due to an authentication server disconnection,

such as a power outage.
For example, consider user-c who is assigned to the mgmt role. When traffic from the trust zone to the
untrust zone is received from user-c at IP address 198.51.100.3, policy lookup is initiated. Table 23 on
page 198 represents three policies in a user role firewall for the trust to untrust zone pair.
198
Table 23: Trust Zone to Untrust Zone Policy Sequence
src-zone src-zone dest-zone src-IP dest-IP source- Application Action Services

identity
P1 trust untrust 192.0.2.0 203.0.113.0 any http deny –
P2 trust untrust any any mgmt any permit –
P3 trust untrust 198.51.100.3 any employee http deny –
All policies for the zone pair are checked first for a source-identity option. If any of the policies specifies
a user, a role, or a keyword, user and role retrieval must occur before policy lookup continues. Table 23
on page 198 shows that policy P2 specifies mgmt as the source identity, making this a user role firewall.
User and roles must be retrieved before policy lookup can continue.
NOTE: User and role retrieval would not be performed if the keyword any or if no source identity
was specified in all of the policies in the zone context. In such cases, only the five remaining
values are matched to the policy criteria.
The UIT represented in Table 24 on page 198 is checked for the IP address. Because the address is
found, the username user-c, all roles listed for user-c (in this case, mgmt and employee), and the
keyword authenticated-user become data used to match the traffic to the source-identity field of a policy.
Table 24: UIT Authentication Details
Source IP Address Username Roles
192.0.2.4 user-a employee
198.51.100.3 user-c mgmt, employee
203.0.113.2 user-s contractor
Policy lookup resumes and compares the match criteria in each policy in Table 23 on page 198 to the
incoming traffic. Assuming all other criteria match, the first policy that specifies user-c, mgmt, employee,
authenticated-user, or any in the source-identity field could be a match for this traffic. Policy P1
matches one of the retrieved roles for user-c, but the source IP address does not match; therefore policy
199
lookup continues. For policy P2, all criteria match the traffic; therefore the policy action is followed and
the traffic is permitted. Note that the traffic also matches policy P3, but user firewall policies are
terminal—policy lookup ends when the first policy match is found. Because policy P2 matches all criteria,
policy lookup ends and policy P3 is not checked.
Policies can also be based on the classification assigned to a user from the user and role retrieval results.
Consider a different set of policies for the same zone pair represented by Table 25 on page 199. If traffic
is received from user-q at IP 198.51.100.5, user and role retrieval is required because the source-
identity field is specified in at least one of the policies.
Table 25: Trust Zone to Untrust Zone Policy Sequence
policy- src-zone dest-zone src-IP dest-IP source- applicati action Services

name identity on
P1 trust untrust any any un- http deny –

authentic
ated-
user
P2 trust untrust any any mgmt any permit –
P3 trust untrust 198.51.1 any employee http deny –

00.3
When the UIT entries in Table 24 on page 198 are checked, no entry is found for IP address
198.51.100.5. Therefore, the user is considered an unauthenticated user. When policy lookup resumes,
the traffic matches policy P1 and the traffic is denied.
Understanding the User Identification Table
IN THIS SECTION
Local Authentication Table | 201
UAC Authentication Table | 203
Firewall Authentication Table | 204
Policy Provisioning With Users and Roles | 205

200
On the SRX Series device, the user identification table (UIT) contains the IP address, username, and role
information for each authenticated user. Entries are ordered by IP address. When username and role
information is required by a security policy, all UITs are checked. Finding the IP address in an entry in
one of the UITs means that the user at that address has already been successfully authenticated.
Each authentication source maintains its own UIT independently and provides query functions for
accessing data. Three types of UITs are supported—the local authentication table, the Unified Access
Control (UAC) authentication table, and the firewall authentication table.
Local A static UIT created on the SRX Series device either manually or programmatically
authentication using CLI commands. All users included in the local authentication table are
table
considered authenticated users. When a matching IP address is found, user and role
information is retrieved from the table entry and associated with the traffic. User and
role information can be created on the device manually or ported from a third-party
authentication server, but the data in the local authentication table is not updated in
real time.
UAC A dynamic UIT pushed from the Junos Pulse Access Control Service to the SRX Series
authentication device. The UAC authentication table of a Junos Pulse Access Control Service
table
contains an entry for each authenticated user. The data in this table is updated and
pushed to the SRX Series device whenever its authentication table is updated.
Depending on the device configuration, authentication could occur on the Junos
Pulse Access Control Service itself or on a third-party authentication server. If the
Access Control Service is relaying data from a third-party server, the data is
restructured by the Access Control Service to match the file format of its
authentication table and pushed to the SRX Series device.
Firewall A dynamic UIT created on the SRX when user-firewall is specified as the firewall
authentication authentication type in a security policy. This UIT provides an alternative user role
table
source to UAC when firewall authentication is already in use on your SRX Series
device. In this way, users defined for pass-through authentication can also be used as
a source for usernames and roles when the user-firewall option is specified as the
firewall authentication type in a policy.
The user-firewall authentication type initiates firewall authentication to verify the user
by using either local authentication information or external authentication servers
supporting RADIUS, LDAP, or SecureID authentication methods. When this type is
specified for firewall authentication, the username and associated groups (roles) from
the authentication source are mapped to the IP address and added to the firewall
authentication UIT.
201
Local Authentication Table
The local authentication table is managed with CLI commands that insert or delete entries. A local
authentication table can be used as a backup solution when a dynamic UIT is not available, or to assign
user and role information to devices that cannot authenticate to the network, such as printers or file
servers. The local authentication table can be used for testing or to demonstrate how a user role firewall
works without firewall authentication or the Access Control Service configured.
The IP addresses, user names, and roles from a third-party authentication source can be downloaded
and added to the local authentication table programmatically using CLI commands. If an authentication
source defines users and groups, the groups can be configured as roles and associated with the user as
usual.
To be compliant with the UAC authentication table, user names are limited to 65 characters and role
names are limited to 64 characters. The local authentication table has a maximum of 10,240
authentication entries on SRX1500 devices and above, 5120 authentication entries on SRX650 devices
and below, depending on the Junos OS release in your installation. The local authentication table has
5120 authentication entries on the vSRX. Each authentication entry can be associated with up to 200
roles. The maximum capacity is based on an average of 10 roles assigned to each user. This is the same
capacity specified for a UAC authentication table.
Use the following command to add an entry to a local authentication table. Note that each entry is
keyed by IP address.
user@host> request security user-identification local-authentication-table add user user-name ip-

address ip-address role [role-name role-name ]
The role option in a single CLI command accepts up to 40 roles. To associate more than 40 roles with a
single user, you need to enter multiple commands. Keep the following characteristics in mind when
adding or modifying authentication user and role entries.
• Role names cannot be the same as usernames.
• Using the add option with an existing IP address and username aggregates the role entries. The table
can support up to 200 roles per user.
• Using the add option with an existing IP address and a new username overwrites the existing
username for that IP address.
• Role aggregation does not affect existing sessions.
• To change the role list of an existing entry, you need to delete the existing entry and add an entry
with the new role list.
202
• To change the IP address of an existing entry, you need to delete the existing entry and add an entry
with the new IP address.
An entry can be deleted by IP address or by username.
user@host> request security user-identification local-authentication-table delete (ip-address |

user-name)
The local authentication table can be cleared with the following command:
user@host> clear security user-identification local-authentication-table
To display the content of the local authentication table, use the following show... command:
user@host> show security user-identification local-authentication-table all (brief | extensive)
The brief option (the default) displays information in a tabular format sequenced by IP address. User
names and role lists are truncated to fit the format.
user@host> show security user-identification local-authentication-table all
Total entries: 2
Source IP Username Roles
198.51.100.1 user1 role1
203.0.113.2 user2 role2, role3
The extensive option displays the full content for each field. Other options limit the display to a single
username, IP address, or role.
user@host> show security user-identification local-authentication-table all extensive
Total entries: 3
Ip-address: 198.51.100.2
Username: user1
Roles: role1
Ip-address: 203.0.113.2
203
Username: user1
Roles: role2
Ip-address: 192.0.2.3
Username: user3
Roles: role1, role2
UAC Authentication Table
An SRX Series device can act as an enforcer for a Junos Pulse Access Control Service. In this
implementation, the SRX Series device acts as a Layer 3 enforcement point and controls access to
resources with IP-based resource policies that have been pushed down from the Access Control Service.
When implemented as a user role firewall, the SRX Series device can access the UAC network in a
similar way for user role retrieval. In this instance, user and role information for all authenticated users is
pushed from the Access Control Service.
The SRX Series device configuration is similar to that of an enforcer. To establish communication, both
devices require configuration and password settings to recognize the other. From the SRX Series device,
connect the Access Control Service as an infranet controller.
[edit]
user@host# set services unified-access-control infranet-controller ic-name address ip-address
user@host# set services unified-access-control infranet-controller ic-name interface interface-
name
user@host# set services unified-access-control infranet-controller ic-name password password
From the Access Control Service, define the SRX Series device as a New Enforcer. Use the same
password specified on the SRX Series device.
Users and passwords are defined on the Access Control Service as in a standard authentication
configuration. One or more roles can also be associated with users. When a user is authenticated, an
entry containing the IP address, username, and associated roles is added to the UAC authentication
table on the Access Control Service.
The UAC authentication table is pushed from the Access Control Service to the SRX Series device when
the connection between the two devices is initialized. Whenever an entry is added, removed, or updated
on the Access Control Service, the updated UAC authentication table is pushed to the SRX Series
device.
Resource access policies are not necessary on the Access Control Service for a user role firewall
implementation. The access behavior is provided in the policy configurations on the SRX Series device. If
resource access policies are defined on the Access Control Service, they are pushed to the SRX Series
204
device, but they are not used unless a specific firewall policy implements UAC policies in the policy’s
action field.
The following show services command displays the content of the UAC authentication table on the SRX
Series device, confirming that the table has been pushed from the Access Control Service successfully:
user@host> show services unified-access-control authentication-table extended
Id Source IP Username Age Role name

3 192.0.2.1 april 60 Users
6 192.0.2.2 june 60 Employeees
Total: 2
The SRX Series device monitors connections and detects if communication to the Access Control
Service has been lost. Based on the UAC configuration, the SRX Series device waits for a response for a
configured interval before issuing another request. If a response is received, the Access Control Service
is considered functional. If no response is received after a specified timeout period, communication is
considered lost and the timeout action is applied. The following UAC command syntax configures the
interval, timeout, and timeout action:
user@host# set services unified-access-control interval seconds

user@host# set services unified-access-control timeout seconds
user@host# set services unified-access-control timeout-action (close | no-change | open)
During a disconnection, if user and role lookup is attempted for the disconnected device, it returns a
failure code regardless of the timeout action. If access to all authentication sources is lost, the keyword
unknown-user is associated with the IP address. When policy lookup resumes, a policy with unknown-
user as the source identity would match the traffic. By implementing a specific policy for unknown-user,
you can create a method for handling the loss of authentication sources.
Firewall Authentication Table
Firewall authentication requires users to authenticate to the SRX firewall before permitting access
between zones and devices. When traffic is received, the user is prompted for a username and
password, and verified against a specified profile of valid users. Depending on the device configuration,
firewall authentication verifies that telnet, HTTP, HTTPS (for SRX5800, SRX5600, and SRX5400
devices), and FTP traffic has been authenticated locally or by a RADIUS, LDAP, or SecureID
authentication server.
205
If firewall authentication is in use on a device, the authentication process can also provide the username
and role information needed for user role firewall match criteria. In this case, the information is collected
and maintained in a UIT called the firewall authentication table. One or more access policies in the edit
access hierarchy define authentication methods to be used for firewall authentication.
The firewall authentication table must be enabled as the authentication source for user role information
retrieval. The priority option specifies the sequence in which all UITs will be checked.
user@host# set security user-identification authentication-source firewall-authentication

priority priority
In a firewall policy for a given zone pair, the firewall-authentication service specified for the permit action
initiates authentication of matching traffic. The user-firewall authentication type generates the UIT entry
for the authenticated user. The name specified in the access-profile option identifies the profile to be
used to authenticate valid users.
[edit security policies from-zone zone to-zone zone policy policy-name]

user@host# set match source-identity unauthenticated-user
user@host# set then permit firewall-authentication user-firewall access-profile profile-name
The UIT table entry contains the IP address of the traffic mapped to the authenticated user and the
user’s associated groups. When the user is no longer active, the entry is removed from the table.
Because entries are continuously added and removed as the traffic and authenticated users change, the
firewall authentication table is considered dynamic.
When policies within the same zone pair specify the source-identity field as part of its match criteria, all
enabled UITs are searched for an entry corresponding to the IP address of the traffic. If found, the
associated username and groups are retrieved for source-identity matching. (User authentication group
names are considered role names for source-identity matching.)
Policy Provisioning With Users and Roles
All users and roles, whether defined on the SRX Series device or on the Access Control Service, are
maintained in a user role file on the SRX Series device. To display all users and roles available for
provisioning, use the following show security... commands.
NOTE: Usernames and roles in the firewall authentication table are not included in the following
displays.
206
• To display all of the roles that are available for provisioning, use the show security user-identification
role-provision all command. Note that the roles from all UITs are listed together.
• To display all of the users that are available for provisioning, use the show security user-identification
user-provision all command.
• To display all of the users and roles that are available for provisioning, use the show security user-
identification source-identity-provision all command.
When a policy configuration is committed, the user role file is checked to determine if all users and roles
specified in the policy are available for provisioning. If a user or role is not found, a warning identifies the
missing user or role so that you can define it later.
NOTE: The policy is committed even if a user or role is not yet defined.
SEE ALSO
Acquiring User Role Information from an Active Directory Authentication Server
Obtaining Username and Role Information Through Firewall

Authentication
User role firewall policies can be integrated with firewall authentication both to authenticate users and
to retrieve username and role information. The information is mapped to the IP address of the traffic,
stored in the firewall authentication table, and used for user role firewall policy enforcement.
The following CLI statements configure firewall authentication for user role firewall enforcement.
1. If not already established, define the access profile to be used for firewall authentication. You can
skip this step if an existing access profile provides the client data needed for your implementation.
The access profile is configured in the [edit access profile] hierarchy as with other firewall
authentication types. It defines clients as firewall users and the passwords that provide them access.
Use the following command to define a profile and add client names and passwords for firewall
authentication.
set access profile profile-name client client-name firewall-user password pwd

207
2. If HTTPS traffic is expected, define the access profile to be used for SSL termination services. You
can skip this step if an existing SSL termination profile provides the services needed for your
implementation.
The SSL termination profile is configured in the [edit services ssl] hierarchy.
set services ssl termination profile ssl-profile-name server-certificate certificate-type
3. Enable the firewall authentication table as an authentication source.
set security user-identification authentication-source firewall-authentication priority

priority
The priority value determines the sequence in which authentication sources are checked. The default
value is 150 for the firewall authentication table. (It is 100 for the local authentication table and 200
for the Unified Access Control (UAC) authentication table.) By default, the local authentication table
is checked first, the firewall authentication table is next, and the UAC authentication table is third if it
is enabled. You can change this sequence by changing the priority value of one or more of the tables.
4. Configure policies that permit traffic for user firewall authentication.
edit security policies from-zone zone to-zone zone policy policy-name

set match source-identity unauthenticated-user
set then permit firewall-authentication user-firewall access-profile profile-name ssl-
termination-profile profile-name
When unauthenticated traffic is permitted for firewall authentication, the user is authenticated based
on the access profile configured in this statement. The ssl-termination-profile option is needed only
for HTTPS traffic.
By specifying the authentication type user-firewall, the firewall authentication table is propagated
with the IP address, the username, and any group names associated with the authenticated user.
(Group names from firewall authentication are interpreted as roles by the user role firewall.) Any
further traffic from this IP address will match the IP address in the firewall authentication table, and
not require authentication. The associated username and roles are retrieved from the table for use as
potential match criteria in subsequent security policies.
208
Configuring a User Role Firewall For Captive Portal Redirection
To automatically redirect unauthenticated users to the Access Control Service, use the UAC captive
portal feature. The following syntax defines the profile for the captive portal:
set services unified-access-control captive-portal profile-name redirect-traffic

[unauthenticated | all]
set services unified-access-control captive-portal profile-name redirect-url host-url
The Kerberos protocol, used for authentication encryption, identifies the Access Control Service only by
its service principal name (SPN). The protocol does not accept an IP address. Therefore, the format for
the redirect URL must be
service://hostname/options
In this implementation, the service is HTTP and the hostname is the FQDN of the Access Control
Service. Options specified after the hostname pass additional information to the Access Control Service
directing the user back to the original destination, to the SRX Series device, or to the policy that
originated the redirection. You can configure the options using the following keyword and variable pairs:
?target=%dest-url% Specifies the protected resource which the user is trying to access.
&enforcer=%enforcer-id% Specifies the ID assigned to the SRX Series device when it is configured as
an enforcer by the Access Control Service.
&policy=%policy-id% Specifies the encrypted policy ID for the security policy that redirected the
traffic.
The following statements define the profile of the captive portal named auth-redirect. The captive-
portal redirects unauthenticated users to the URL of the Access Control Service for authentication. After
successful authentication, the traffic will be directed back to the SRX Series device.
[edit]
user@host# set services unified-access-control captive-portal auth-redirect redirect-traffic
unauthenticated
user@host# set services unified-access-control captive-portal auth-redirect redirect-url "http://
ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=%policy-id%"
209
A defined captive-portal profile is displayed as part of the UAC configuration.
[edit]
user@host#show services
unified-access-control {
captive-portal auth-redirect {
redirect-traffic unauthenticated;
redirect-url "http://ic6000.example.com/?target=%dest-url%&enforcer=%enforcer-id%&policy=
%policy-id%";
}
}
After the profile is defined, a policy can apply the captive portal as an application service when certain
criteria is matched. Whenever a user role is unauthenticated, auth-redirect captive portal diverts the
traffic from trust zone to untrust zone. The following example defines policy P1 to apply the auth-
redirect captive portal profile to any HTTP traffic from the trust to untrust:
[edit]
user@host# set security policies from-zone trust to-zone untrust policy P1 match application http
user@host# set security policies from-zone trust to-zone untrust policy P1 match source-identity
unauthenticated-user
user@host# set security policies from-zone trust to-zone untrust policy P1 then permit
application-services uac-policy captive-portal auth-redirect
Example: Configuring a User Role Firewall on an SRX Series Device
IN THIS SECTION
Requirements | 210
Overview | 210
Configuration | 212
210
The following example configures a user role firewall on an SRX Series device. The firewall controls
access from the trust zone to the untrust zone based on active, authenticated users or their associated
roles. User role firewall policies establish the following restrictions:
• Only authenticated users are permitted from the trust zone to the untrust zone.
Unauthenticated users are redirected to an Access Control Service for authentication.
• Traffic from IP 192.0.2.0 to IP 203.0.113.0 within the zone context is restricted. Only the traffic from
users with the dev-abc, http-juniper-accessible, or ftp-accessible role is permitted. Permitted traffic is
further evaluated by AppFW rules.
• Permitted traffic identified as junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK, or junos:MEEBO

application traffic is denied.
• Permitted traffic for any other application is permitted.
• All other traffic from the trust zone to the untrust zone is permitted.
Requirements
Before you begin, ensure that the SRX Series device with Junos OS Release 12.1 or later is configured
and initialized.
In this example, user and role information associated with the IP address of the traffic is provided by an
Access Control Service. For instructions on configuring the Access Control Server, see Acquiring User
Role Information from an Active Directory Authentication Server.
Overview
Table 26 on page 210 outlines a firewall that meets the requirements for this example. The user role
firewall consists of four policies.
Table 26: User Role Firewall Policies
policy- src-zone dest-zone src-IP dest-IP source- applicatio action Services

name identity n
user-role- trust untrust any any un- http permit UAC

fw1 authentic captive
ated- portal
user
211
Table 26: User Role Firewall Policies (Continued)
policy- src-zone dest-zone src-IP dest-IP source- applicatio action Services

name identity n
user-role- trust untrust 192.0.2.0 203.0.11 dev-abc http permit AppFW

fw2 3.0 http- ruleset
juniper- RS1
accessible
ftp-
accessible
user-role- trust untrust 192.0.2.0 203.0.11 any http deny

fw3 3.0
user-role- trust untrust any any any http permit

fw4
Because the source-identity field is specified for at least one of the policies in this firewall, user and role
information must be retrieved before policy lookup is conducted. The source IP of the traffic is
compared to the items in the UIT. If the source IP address is found, the keyword authenticated, the
username, and any roles associated with this user are stored for later use in policy lookup. If a matching
entry for the IP address is not found in the UIT, the keyword unauthenticated-user is stored for policy
lookup.
After retrieving the username, roles, and keywords, policy lookup begins. Characteristics of the incoming
traffic are compared to each policy’s match criteria. If a match is found, the action specified in that policy
is taken.
A policy match is a terminal event, and no policies after the match are checked. Policy sequence
influences the action to be taken for matching traffic. In this example, policies are applied in the
following sequence:
user-role- Applies the UAC captive portal service to matching HTTP traffic with the
fw1 unauthenticated-user keyword, and redirects it to the Access Control Service for
authentication. A UAC profile must also be configured to identify the captive portal
specifications.
user-role- Applies an AppFW rule set to any HTTP traffic from address 192.0.2.0 to address
fw2 203.0.113.0 that has a matching username or role. An application firewall must also be
configured to define the rule set.
212
user-role- Denies all remaining HTTP traffic from address 192.0.2.0 to address 203.0.113.0 for this
fw3 zone pair.
user-role- Permits all remaining HTTP traffic for this zone pair.
fw4
Configuration
IN THIS SECTION
Configuring Redirection For Unauthenticated Users | 212
Creating a User Role Policy With an Application Firewall | 214
Creating Remaining Security Policies Based on User and Role | 216
Configuring Redirection For Unauthenticated Users
When an IP address is not listed in the UIT, the unauthenticated-user keyword is used in policy lookup.
Instead of denying access to this traffic, a policy can redirect the traffic to a UAC captive portal for
authentication.
NOTE: It is important to position a redirection policy for unauthenticated-user before a policy for
“any” user so that UAC authentication is not shadowed by a policy intended for authenticated
users.
To configure redirection from the SRX Series device to the Access Control Service:
1. From configuration mode, configure the UAC profile for the captive portal acs-device.
[edit]
user@host# set services unified-access-control captive-portal acs-device redirect-traffic
unauthenticated-user
213
2. Configure the redirection URL for the Access Control Service or a default URL for the captive portal.
[edit]
user@host# set services unified-access-control captive-portal acs-device redirect-url
“https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
This policy specifies the default target and enforcer variables to be used by the Access Control
Service to direct the user back after authentication. This ensures that changes to system
specifications will not affect configuration results.
NOTE: When variables, such as ?target=, are included in the command line, you must enclose
the URL and variables in quotation marks.
3. Configure a user role firewall policy that redirects HTTP traffic from zone trust to zone untrust if the
source-identity is unauthenticated-user. The captive portal profile name is specified as the action to
be taken for traffic matching this policy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 match
source-address any
destination-address any
application http
source-identity unauthenticated-user
user@host# set security policies from-zone trust to-zone untrust policy user-role-fw1 then
permit application-services uac-policy captive-portal acs-device
4. If you are done configuring the policies, commit the changes.
[edit]
user@host# commit
214
Results
From configuration mode, confirm your configuration by entering the show services and show security
policies commands. If the output does not display the intended configuration, repeat the instructions in
this example to correct the configuration.
[edit]
user@host# show services
unified-access-control {
captive-portal acs-device {
redirect-traffic unauthenticated;
redirect-url “https://%ic-ip%/?target=%dest-url%&enforcer=%enforcer-id%”

policy user-role-fw1 {
match {
source-address any;
application http;
}
then {
permit {
application-services {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
Creating a User Role Policy With an Application Firewall
This policy restricts traffic from IP192.0.2.0 to IP 203.0.113.0 based on its user and roles, and also its
application. The configuration defines an application rule set and applies it to matching user role traffic.
215
1. Configure the AppFW rule set rs1. The following rule set denies junos:FACEBOOK-ACCESS,
junos:GOOGLE-TALK, or junos:MEEBO application traffic. It applies the default setting, permit, to the
remaining traffic.
[edit security application-firewall rule-sets rs1]

user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK
junos:MEEBO]
user@host# set rule r1 then deny
user@host# set default-rule permit
2. Configure a policy to apply the rs1 application firewall rule set to traffic from IP 192.0.2.0 to IP
203.0.113.0 with the dev-abc, http-mgmt-accessible, or ftp-accessible user role.
[edit]
source-address 192.0.2.0
destination-address 203.0.113.0
application http
source-identity [dev-abc http-mgmt-accessible ftp-accessible]
permit application-services application-firewall rule-set rs1
3. If you are done configuring the policy, commit the changes.
[edit]
user@host# commit
Results
Verify that the AppFW rule set is configured properly. If the output does not display the intended
configuration, repeat the instructions in this example to correct the configuration.
[edit]
user@host# show security application-firewall
rule-sets rs1 {
rule r1 {
216
match {
dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLE-TALK junos:MEEBO]
}
then {
deny;
}
}
default-rule {
permit;
}
}
Creating Remaining Security Policies Based on User and Role
The following procedure configures policies for the remaining traffic.
1. Configure a policy to deny traffic with the same source and destination address but with different
user and role criteria than specified in the user-role-fw2 policy.
[edit]
source-address 192.0.2.0
destination-address 203.0.113.0
application http
source-identity any
deny
2. Configure a security policy to permit all other HTTP traffic from zone trust to zone untrust.
[edit]
source-address any
217
application http
source-identity any
permit
Results
Verify the content and sequence of the user role firewall policies. If the output does not display the
intended configuration, repeat the instructions in this example to correct the configuration.
[edit]
...
match {
source-address any;
application http;
}
then {
permit {
uac-policy {
captive-portal acs-device;
}
}
}
}
}
}
match {
destination-address 203.0.113.0;
application http;
source-identity [dev-abc http-juniper-accessible ftp-accessible]
218
}
then {
permit {
application-firewall {
rule-set rs1
}
}
}
}
}
}
match {
application http;
source-identity any
}
then {
deny
}
}
}
match {
source-address any;
application http;
source-identity any
}
then {
permit
}
}
}
219
Configuring Resource Policies Using UAC
When using the user role firewall feature, resource policies are not necessary on the Access Control
Service. If, however, resource policies exist, they are pushed to the SRX Series device at connection. You
can create policies that use these resource policies by applying the UAC application service in the policy
configuration. Table 27 on page 219 shows three firewall policies that use the UAC resource policies
exclusively:
Table 27: User Role Firewall Usage
policy- src-zone dest-zone src-IP dest-IP source- applicati action Services

name identity on
P1 zone1 zone2 any 192.0.2.1 any http permit UTM
P2 zone1 zone2 any net2 any http permit IDP
P3 zone1 zone2 any any any any permit UAC
The policies for traffic from zone1 to zone2 do not initiate user and role retrieval because any is
specified in the source-identity field of every policy. In this example, traffic to the IP address 192.0.2.1 is
permitted, but must meet processing requirements for the specified application service, in this case,
UTM. Traffic to net2 is permitted and processed by the IDP processing requirements. Any remaining
traffic is permitted and processed by the UAC processing requirements.
The configuration for this firewall policy would be as follows:
[edit]
from-zone zone1 to-zone zone2 {
policy P1 {
match {
source-address any;
source-identity any;
application http;
}
then {
permit {
220
idp;
}
}
}
}
}
policy P2 {
match {
source-address any;
destination-address net2;
application http;
}
then {
permit {
utm;
}
}
}
}
}
policy P3 {
match {
source-address any;
application any;
}
then {
permit {
uac-policy;
}
}
}
}
}
221
In this sample configuration, the action fields in P1 and P2 apply any requirements that have been
configured for IDP and UTM respectively. By specifying the uac-policy option, the resource policies
pushed to the SRX Series device determine whether the destination is accessible.
A user role firewall can implement both user role policies and the resource policies pushed from the
Access Control Service. Table 28 on page 221 shows the policies for three zone pairs.
Table 28: User Role Firewall Usage
policy- src-zone dest- src-IP dest-IP source-identity application action Services

name zone
P1 zone1 zone2 any any unauthenticated- any permit UAC

user captive
portal
P2 zone1 zone2 any 192.0.2.1 role2 http permit IDP
P3 zone1 zone2 any net2 authenticated-user http permit UTM
P4 zone1 zone2 any any any any permit
Traffic from zone1 to zone2 is subject to one of four user role policies. The first of these policies uses
the UAC captive portal to redirect unauthenticated users to the Access Control Service for
authentication.
The access of traffic from zone1 to zone3 and from zone2 to zone3 is controlled by the resource policies
pushed from the Access Control Service.

222
Reordering Security Policies
IN THIS SECTION
Reordering security policy allows to move the policies around after they have been created. Junos OS
offers a tool for verifying that the order of policies in the policy list is valid.
Understanding Security Policy Ordering
Junos OS offers a tool for verifying that the order of policies in the policy list is valid.
It is possible for one policy to eclipse, or shadow, another policy. Consider the following examples:
Example 1
[edit]
user@host# set security zones security-zone trust interfaces ge-0/0/2 host-inbound-traffic
system-services all
user@host# set security zones security-zone untrust interfaces ge-0/0/1 host-inbound-traffic
system-services all
user@host# set security policies from-zone trust to-zone untrust policy permit-all match source-
address any
user@host# set security policies from-zone trust to-zone untrust match destination-address any
user@host# set security policies from-zone trust to-zone untrust match application any
user@host# set security policies from-zone trust to-zone untrust set then permit
user@host# set security policies from-zone untrust to-zone trust policy deny-all match source-
address any
user@host# set security policies from-zone untrust to-zone trust policy deny-all match
user@host# set security policies from-zone untrust to-zone trust policy deny-all match
application any
user@host# set security policies from-zone untrust to-zone trust policy deny-all then deny
223
Example 2
[edit]
user@host# set security zones security-zone trust interfaces ge-0/0/2.0 host-inbound-traffic
system-services all
user@host# set security zones security-zone untrust interfaces ge-0/0/1.0 host-inbound-traffic
system-services all
user@host# set security address-book book1 address mail-untrust 192.0.2.1/24
user@host# set security address-book book1 attach zone untrust
user@host# set security address-book book2 address mail-trust 192.168.1.1/24
user@host# set security address-book book2 attach zone trust
user@host# set security policies from-zone trust to-zone untrust policy permit-mail match source-
address mail-trust
user@host# set security policies from-zone trust to-zone untrust policy permit-mail match
destination-address mail-untrust
user@host# set security policies from-zone trust to-zone untrust policy permit-mail match
application junos-mail
user@host# set security policies from-zone trust to-zone untrust policy permit-mail then permit
In examples 1 and 2, where policy permit-mail is configured after policy permit-all from zone trust to zone
untrust. All traffic coming from zone untrust matches the first policy permit-all and is allowed by default.
No traffic matches policy permit-mail.
Because Junos OS performs a policy lookup starting from the top of the list, when it finds a match for
traffic received, it does not look any lower in the policy list. To correct the previous example, you can
simply reverse the order of the policies, putting the more specific one first:
[edit]
user@host# insert security policies from-zone trust to-zone untrust policy permit-mail before policy permit-
all
224
In cases where there are dozens or hundreds of policies, the eclipsing of one policy by another might not
be so easy to detect. To check if policies are being shadowed, enter any of the following commands:
[edit]
user@host# run show security shadow-policies logical-system lsys-name from-zone from-zone-name to-zone to-
zone-name
[edit]
user@host# run show security shadow-policies logical-system lsys-name global
This command reports the shadowing and shadowed policies. It is then the administrator's responsibility
to correct the situation.
NOTE: The concept of policy shadowing refers to the situation where a policy higher in the
policy list always takes effect before a subsequent policy. Because the policy lookup always uses
the first policy it finds that matches the five-part tuple of the source and destination zone, source
and destination address, and application type, if another policy applies to the same tuple (or a
subset of the tuple), the policy lookup uses the first policy in the list and never reaches the
second one.
SEE ALSO

Example: Reordering Security Policies
IN THIS SECTION
Requirements | 225
Overview | 225
225
Configuration | 225
Verification | 226
This example shows show how to move policies around after they have been created.
Requirements
Before you begin:
• Configure the address book and create addresses for use in the policy. See "Example: Configuring
Overview
To reorder policies to correct shadowing, you can simply reverse the order of the policies, putting the
more specific one first.
Configuration
IN THIS SECTION
Procedure | 225
Procedure
To reorder existing policies:
1. Reorder two existing policies by entering the following command:
[edit]
user@host# insert security policies from-zone trust to-zone untrust policy permit-mail before
policy permit-all
226
[edit]
user@host# commit
Verification
To verify the configuration is working properly, enter the show security policies command.
Scheduling Security Policies
IN THIS SECTION
Example: Configuring Schedulers for a Daily Schedule Excluding One Day | 227
Verifying Scheduled Policies | 232
Scheduler is a security feature that allows a policy to be activated for a specified duration. You can
define schedulers for a single (nonrecurrent) or recurrent time slot within which a policy is active. You
can create schedulers irrespective of a policy, meaning that a scheduler cannot be used by any policies.
Security Policy Schedulers Overview
Schedulers are powerful features that allow a policy to be activated for a specified duration. You can
define schedulers for a single (nonrecurrent) or recurrent time slot within which a policy is active. You
can create schedulers irrespective of a policy, meaning that a scheduler cannot be used by any policies.
However, if you want a policy to be active within a scheduled time, then you must first create a
scheduler.
227
When a scheduler times out, the associated policy is deactivated. All sessions associated with the policy
are subsequently timed out only if policy-rematch is used
If a policy contains a reference to a scheduler, the schedule determines when the policy is active, that is,
when it can be used as a possible match for traffic. Schedulers allow you to restrict access to a resource
for a period of time or remove a restriction.
The following guidelines apply to schedulers:
• A scheduler can have multiple policies associated with it; however, a policy cannot be associated
with multiple schedulers.
• A policy is active during the time when the scheduler it refers to is also active.
• When a scheduler is off, the policy is unavailable for policy lookup.
• A scheduler can be configured as one of the following:
• Scheduler can be active for a single time slot, as specified by a start date and time and a stop date
and time.
• Scheduler can be active forever (recurrent), but as specified by the daily schedule. The schedule
on a specific day (time slot) takes priority over the daily schedule.
• Scheduler can be active within a time slot as specified by the weekday schedule.
• Scheduler can have a combination of two time slots (daily and timeslot).
Example: Configuring Schedulers for a Daily Schedule Excluding One Day
IN THIS SECTION
Requirements | 228
Overview | 228
Configuration | 228
Verification | 231
This example shows how to configure schedulers for packet match checks every day, from 8:00 AM to
5:00 PM, except Sunday.
228
Requirements
Before you begin:
• Understand security policies schedulers. See "Security Policies Overview" on page 2.
• Configure security zones before applying this configuration.
Overview
Schedulers are powerful features that allow a policy to be activated for a specified duration. You can
define schedulers for a single (nonrecurrent) or recurrent time slot within which a policy is active. If you
want a policy to be active within a scheduled time, then you must first create a scheduler.
To configure a scheduler, you enter a meaningful name and a start and stop time for the scheduler. You
can also attach comments.
In this example, you:
• Specify the scheduler, sch1, that allows a policy, which refers to it, to be used for packet match
checks every day, from 8:00 AM to 5:00 PM, except Sunday.
NOTE: Use the 24-hour format (hh:mm) to specify the hours and minutes for the daily time.
• Create a policy, abc, and specify the match conditions and action to be taken on traffic that matches
the specified conditions. and bind the schedulers to the policy to allow access during the specified
days.
Configuration
IN THIS SECTION
Procedure | 229
229
Procedure
line breaks, change any details necessary to match your network configuration, and then copy and paste
the commands into the CLI at the [edit] hierarchy level.
set schedulers scheduler sch1 daily start-time 08:00 stop-time 17:00

set schedulers scheduler sch1 sunday exclude
set security policies from-zone green to-zone red policy abc match source-address any
set security policies from-zone green to-zone red policy abc match destination-address any
set security policies from-zone green to-zone red policy abc match application any
set security policies from-zone green to-zone red policy abc then permit
set security policies from-zone green to-zone red policy abc scheduler-name sch1
set security policies default-policy permit-all
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure a scheduler:
1. Set a scheduler.
[edit schedulers ]
user@host# set scheduler sch1 daily start-time 08:00 stop-time 17:00
user@host# set scheduler sch1 sunday exclude
2. Specify the match conditions for the policy.
[edit security policies from-zone green to-zone red policy abc]

user@host# set match source-address any destination-address any application any
230
3. Specify the action.
[edit security policies from-zone green to-zone red policy abc]

user@host# set then permit
4. Associate the scheduler to the policy.
[edit security policies from-zone green to-zone red policy abc ]

user@host# set scheduler-name sch1
Results
From configuration mode, confirm your configuration by entering the show schedulers command. If the
to correct it.
[edit]
[user@host]show schedulers
scheduler sch1 {
daily {
start-time 08:00 stop-time 17:00;
sunday exclude;
}
[edit]
[user@host]show security policies
from-zone green to-zone red {
policy abc {
match {
source-address any;
application any;
}
then {
permit;
}
scheduler-name sch1;
}
}
default-policy {
231
permit-all;
}
Verification
IN THIS SECTION
Verifying Schedulers are Active | 231
Verifying Policies | 231
To confirm that the configuration is working properly, perform these tasks:
Verifying Schedulers are Active
Purpose
Verify if schedulers are enabled or not.
Action
From operational mode, enter the show schedulers command.
Verifying Policies
Purpose
Verify if the policies are working.
Action
From operational mode, enter the show security policies command.

232
Verifying Scheduled Policies
IN THIS SECTION
Purpose | 232
Action | 232
Meaning | 233
Purpose
Display information about scheduled security policies.
Action
Use the show schedulers CLI command to display information about schedulers configured on the system.
If a specific scheduler is identified, detailed information is displayed for that scheduler only.
user@host# show schedulers

scheduler sche1 {
/* This is sched1 */
start-date 2006-11-02.12:12 stop-date 2007-11-02.12:11;
}
scheduler sche2 {
daily {
all-day;
}
sunday {
}
friday {
exclude;
}
}
scheduler sche3 {
start-date 2006-11-02.12:12 stop-date 2007-11-02.12:11;
daily {
start-time 10:00 stop-time 17:00
233
}
sunday {
}
monday {
all-day;
}
friday {
exclude;
}
}
Meaning
The output displays information about schedulers configured on the system. Verify the following
information:
• Daily (recurrent) and one-time only (nonrecurrent) schedulers are configured correctly.
• Schedulers are active if policies are associated.
Threat Profiling Support in Security Policy
SUMMARY IN THIS SECTION
Read this topic to understand SRX Series device Support for Threat Feeds in Security
support for threat feeds in the security policies. Policies | 234
234
Support for Threat Feeds in Security Policies
SRX Series devices can generate, propagate, and consume threat feeds based on their own advanced
detection and policy-match events.
Juniper ATP Cloud service consolidates the generated feeds from SRX Series device and shares the
duplicated results back to the security device. The security device then uses the feeds to perform
actions against the designated traffic. You can enable the security device to use the feeds by configuring
security policies with the feeds as a matching criteria. When traffic matches policy conditions, the
device applies policy actions.
SRX Series devices support following types of threat feeds in the security policies:
• source and destination addresses
• user source identity (user name)
Workflow in using the threat feeds in security policies:
1. In a security policy, you can add the source address/destination address,/source identity (user name)
as a feed for the policy action (deny, reject, and permit rules).
2. Policy module adds the username to the traffic’s IP address into the feed.
3. Once the feed is created, Juniper ATP cloud consolidates feeds from all SRX Series devices in your
enterprise and sends result to SRX Series device.
4. When you create another security policy, you can add the feed as match criteria.
See Adaptive Threat Profiling Overview for more information on configuring and deploying security
policies with feeds.
Configuring Security Policies for a VRF Routing

Instance
IN THIS SECTION
Overview | 235

235
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from MPLS Network to an IP
Network | 238
Example: Configuring a Security Policy to Permit VRF-Based Traffic from an IP Network to an MPLS
Network | 244
Example: Configuring a Security Policy to Permit VRF-Based Traffic from an MPLS Network to an MPLS
Network over GRE without NAT | 250
Example: Configuring Security Policies Using VRF Routing Instances in an MPLS Network | 256
Overview
IN THIS SECTION
Controlling Traffic in SD-WAN Architecture | 235
A security policy is a set of statements that controls traffic from a specified source to a specified
destination using a specified service. A policy permits, denies, or tunnels specified types of traffic
unidirectionally between two points. 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. Actions for traffic matching the specified criteria include permit and deny.
When an SRX Series device receives a packet that matches the specifications, it performs the action
specified in the policy.
Controlling Traffic in SD-WAN Architecture
In an SD-WAN, the SRX Series device can be configured in a hub and spoke location. You can permit or
deny virtual routing and forwarding (VRF) based traffic that enters the device from overlay tunnels by
applying firewall policies. You can configure the SRX Series device to permit or deny traffic that is sent to
a VRF instance. Configuring the device at the hub location enables you to control all traffic at one
location, and provide access to specific network services by applying firewall policies.
Junos OS Release 91.1R1 supports MPLS-based SDWAN deployment on SRX1500, SRX4100,

SRX4200, SRX4600 devices.
Starting in Junos OS Release 22.2R1, we support MPLS-based SDWAN deployment for SRX5400,
SRX5600, and SRX5800 devices.
236
Each security policy consists of:
• A unique name for the policy.
• A from-zone and a to-zone, for example: user@host# set security policies from-zone GRE_Zone-GE_Zone to-zone
GRE_Zone.
• A set of match criteria defining the conditions that must be satisfied to apply the policy rule. The
match criteria are based on a source IP address, destination IP address, and applications. The user
identity firewall provides greater granularity by including an additional tuple, such as source-identity,
as part of the policy statement.
• A set of actions to be performed in case of a match—permit or deny.
• A set of source VRF group.
• A set of destination VRF group.
NOTE: The configuration options for the source and destination VRF instances are optional. You
can configure either the source VRF or a destination VRF, but we recommend that you do not
configure both source VRF and destination VRF. The main reason for configuring the source VRF
or destination VRF is to differentiate different MPLS labels going through a shared physical
network interface.
Table 29 on page 236 lists when to configure the source VRF and destination VRF.
Table 29: Recommendations for Configuring VRF Options
Network Type from Source to Recommended to Recommended to VRF Policy

Destination Configure Source VRF Configure Destination Differentiated By
VRF
IP network to IP network No No Zones
IP network to MPLS network No Yes Destination VRF
MPLS network to IP network Yes No Source VRF
MPLS network to MPLS network Yes No Source VRF

without destination NAT
237
Table 29: Recommendations for Configuring VRF Options (Continued)
Network Type from Source to Recommended to Recommended to VRF Policy

Destination Configure Source VRF Configure Destination Differentiated By
VRF
MPLS network to MPLS network Yes Yes Source VRF and

with destination NAT Destination VRF
Understanding Security Policy Rules
IN THIS SECTION
| 237
A security policy applies security rules to the transit traffic within a context (from-zone to to-zone). Each
policy is uniquely identified by its name. The traffic is classified by matching its source and destination
zones, the source and destination addresses, the application, the source VRF, and the destination VRF
that the traffic carries in its protocol headers with the policy database in the data plane.
Each policy is associated with the following characteristics:
• A source zone
• A destination zone
• One or many source address names or address set names
• One or many destination address names or address set names
• One or many application names or application set names
• One or many source VRF instances, for example, the VRF routing instance associated with an
incoming packet
• One or many destination VRF instances in which the MPLS next hop or destination address route is
located
238
These characteristics are called the match criteria. Each policy also has actions associated with it: permit,
deny, and reject. You have to specify the match condition arguments when you configure a policy,
source address, destination address, application name, source VRF, and destination VRF.
You can configure either source VRF or destination VRF, but not recommended to configure both source
VRF and destination VRF. The main reason for configuring source VRF and destination VR is to
differentiate different MPLS labels going through a shared physical network interface. If the source VRF
and destination VRF are not configured, then the device determines the source and destination VRF as
any.
Example: Configuring a Security Policy to Permit or Deny VRF-Based

Traffic from MPLS Network to an IP Network
IN THIS SECTION
Requirements | 238
Overview | 238
Configuration | 239
This example shows how to configure a security policy to permit traffic and deny traffic using the source
VRF.
Requirements
• Understand how to create a security zone. See"Example: Creating Security Zones" on page 9.
• Supported SRX Series device with Junos OS Release 15.1X49-D160 or later. This configuration
example is tested for Junos OS Release 15.1X49-D160.
• Configure network interfaces on the device. See Interfaces User Guide for Security Devices.
Overview
In Junos OS, security policies enforce rules for transit traffic, in terms of what traffic can pass through
the device and the actions that need to take place on the traffic as it passes through the device. In
Figure 10 on page 239, an SRX Series device is deployed in an SD-WAN to control traffic using the
source VRF. Traffic from the MPLS network is sent to site A and site B of the IP network. As per the
network requirement, site A traffic should be denied, and only site B traffic should be permitted.
239
• Deny traffic to VRF-a (from GRE_Zone-GE_Zone to GRE_Zone)
• Permit traffic to VRF-b (from GRE_Zone-GE_Zone to GRE_Zone)
In this example, the source VRF is configured. We recommend that you configure the source VRF when
the destination network points to the MPLS network.
Figure 10: Permitting or Denying VRF-Based Traffic from MPLS Network to an IP Network
Configuration
IN THIS SECTION
Verification | 243
Procedure
set routing-instances VRF-a instance-type vrf

set routing-instances VRF-a route-distinguisher 10:200
set routing-instances VRF-a vrf-target target:100:100
set routing-instances VRF-a vrf-table-label
set routing-instances VRF-b instance-type vrf
set routing-instances VRF-b route-distinguisher 20:200
set routing-instances VRF-b vrf-target target:200:100
240
set routing-instances VRF-b vrf-table-label

set security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone policy vrf-a_policy match
source-address any
application any
source-l3vpn-vrf-group VRF-a
set security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone policy vrf-a_policy then deny
set security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone policy vrf-b_policy match
source-address any
application any
source-l3vpn-vrf-group VRF-b
set security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone policy vrf-b_policy then permit
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS
CLI User Guide.
1. Layer 3 VPNs require a VRF table for distributing routes within the networks. Create a VRF instance
and specify the value vrf.
[edit routing-instances]
user@host# set VRF-a instance-type vrf
user@host# set VRF-b instance-type vrf
2. Assign a route distinguisher to the routing instance.
user@host# set VRF-a route-distinguisher 10:200
user@host# set VRF-b route-distinguisher 20:200
241
3. Create a community policy to import or export all routes.
user@host# set VRF-a vrf-target target:100:100
user@host# set VRF-b vrf-target target:200:100
4. Assign a single VPN label for all the routes in the VRF.
user@host# set VRF-a vrf-table-label
user@host# set VRF-b vrf-table-label
5. Create a security policy to deny VRF-a traffic.
[edit security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone]

user@host# set policy vrf-a_policy match source-address any
user@host# set policy vrf-a_policy match destination-address any
user@host# set policy vrf-a_policy match application any
user@host# set policy vrf-a_policy match source-l3vpn-vrf-group VRF-a
user@host# set policy vrf-a_policy then deny
6. Create a security policy to permit VRF-b traffic.
[edit security policies from-zone GRE_Zone-GE_Zone to-zone GRE_Zone]

user@host# set policy vrf-b_policy match source-address any
user@host# set policy vrf-b_policy match destination-address any
user@host# set policy vrf-b_policy match application any
user@host# set policy vrf-b_policy match source-l3vpn-vrf-group VRF-b
user@host# set policy vrf-b_policy then permit
NOTE: If no destination VRF group is configured then the device considers the traffic passes
from VRF-a to any-vrf.
242
Results
routing-instances commands. If the output does not display the intended configuration, repeat the
[edit]
from-zone GRE_Zone-GE_Zone to-zone GRE_Zone {
policy vrf-a_policy {
match {
source-address any;
application any;
source-l3vpn-vrf-group VRF-a;
}
then {
deny;
}
}
policy vrf-b_policy {
match {
source-address any;
application any;
source-l3vpn-vrf-group VRF-b;
}
then {
permit;
}
}
[edit]
user@host# show routing-instances
VRF-a {
instance-type vrf;
route-distinguisher 10:200;
vrf-target target:100:100;
vrf-table-label;
}
VRF-b {
243
instance-type vrf;
vrf-table-label;
}
}
Verification
IN THIS SECTION
Purpose
Action
From operational mode, enter the show security policies command to display a summary of all the security
policies configured on the device.
user@root> show security policies

From zone: GRE_Zone-GE_Zone, To zone: GRE_Zone
Policy: vrf-a_policy, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1
Source vrf: VRF-a
destination vrf: any
Applications: any
Action: deny
Policy: vrf-b_policy, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 2
Source vrf: VRF-b
244
destination vrf: any

Applications: any
Action: permit
Example: Configuring a Security Policy to Permit VRF-Based Traffic from

an IP Network to an MPLS Network
IN THIS SECTION
Requirements | 244
Overview | 244
Configuration | 245
This example shows how to configure a security policy to permit traffic using the destination VRF.
Requirements
• Understand how to create a security zone. See "Example: Creating Security Zones" on page 9.
• Configure network interfaces on the device. See the Interfaces User Guide for Security Devices.
Overview
the device and the actions that need to take place on the traffic as it passes through the device.
In this example, an SRX Series device is deployed in an SD-WAN architecture to control traffic using the
destination VRF. You need to configure policies to control the traffic. The default policy does not
support VRF options. Traffic from the IP network, that is site A and site B, is sent to the MPLS network.
By configuring the policies, you can permit both the traffic from site A and site B to the MPLS network.
245
In Figure 11 on page 245, the source VRF is not configured as the LAN interface does not belong to an
MPLS network. We recommend that you configure the destination VRF when the destination network
points to the MPLS network.
Figure 11: Permitting VRF-Based Traffic from an IP Network to an MPLS Network
Configuration
IN THIS SECTION
Verification | 249
Procedure
set routing-instances VRF-a’ instance-type vrf

set routing-instances VRF-a’ route-distinguisher 10:200
set routing-instances VRF-a’ vrf-target target:100:100
set routing-instances VRF-a’ vrf-table-label
set routing-instances VRF-b’ instance-type vrf
set routing-instances VRF-b’ route-distinguisher 20:200
set routing-instances VRF-b’ vrf-target target:200:100
set routing-instances VRF-b’ vrf-table-label
set security policies from-zone LAN-a_Zone to-zone GRE_Zone policy vrf-a_policy match source-
address any
set security policies from-zone LAN-a_Zone to-zone GRE_Zone policy vrf-a_policy match
246
application any
destination-l3vpn-vrf-group VRF-a’
set security policies from-zone LAN-a_Zone to-zone GRE_Zone policy vrf-a_policy then permit
set security policies from-zone LAN-b_Zone to-zone GRE_Zone policy vrf-b_policy match source-
address any
set security policies from-zone LAN-b_Zone to-zone GRE_Zone policy vrf-b_policy match
application any
destination-l3vpn-vrf-group VRF-b’
set security policies from-zone LAN-b_Zone to-zone GRE_Zone policy vrf-b_policy then permit
CLI User Guide.
To configure a policy to permit traffic from the IP network to the MPLS network using the destination
VRF:
user@host# set VRF-a’ instance-type vrf
user@host# set VRF-b’ instance-type vrf
user@host# set VRF-a’ route-distinguisher 10:200
user@host# set VRF-b’ route-distinguisher 20:200
247
user@host# set VRF-a’ vrf-target target:100:100
user@host# set VRF-b’ vrf-target target:200:100
user@host# set VRF-a’ vrf-table-label
user@host# set VRF-b’ vrf-table-label
5. Create a security policy to permit VRF-a’ traffic from the IP network.
[edit security policies from-zone LAN-a_Zone to-zone GRE_Zone]

user@host# set policy policy vrf-a_policy match application any
user@host# set policy vrf-a_policy match destination-l3vpn-vrf-group VRF-a’
user@host# set policy vrf-a_policy then permit
6. Create a security policy to permit VRF-b’ traffic from the IP network.
[edit security policies from-zone LAN-b_Zone to-zone GRE_Zone]

user@host# set policy vrf-b_policy match destination-l3vpn-vrf-group VRF-b’
248
Results
[edit]
from-zone LAN-a_Zone to-zone GRE_Zone {
match {
source-address any;
application any;
destination-l3vpn-vrf-group "VRF-a'";
}
then {
permit;
}
}
}
from-zone LAN-b_Zone to-zone GRE_Zone {
match {
source-address any;
application any;
destination-l3vpn-vrf-group "VRF-b'";
}
then {
permit;
}
}
}
[edit]
VRF-a’ {
instance-type vrf;
249
vrf-table-label;
}
VRF-b’ {
instance-type vrf;
vrf-table-label;
}
Verification
IN THIS SECTION
Purpose
Verify that the security policy permits VRF-based traffic from the IP network to the MPLS network.
Action

From zone: LAN-a_Zone, To zone: GRE_Zone
Source vrf: any
destination vrf: VRF-a'
Applications: any
Action: permit
From zone: LAN-b_Zone, To zone: GRE_Zone
250

Source vrf: any
destination vrf: VRF-b'
Applications: any
Action: permit
Example: Configuring a Security Policy to Permit VRF-Based Traffic from

an MPLS Network to an MPLS Network over GRE without NAT
IN THIS SECTION
Requirements | 250
Overview | 250
Configuration | 251
This example shows how to configure a security policy to permit traffic using the source VRF.
Requirements
• Configure network interfaces on the device. See the Interfaces User Guide for Security Devices.
Overview
Figure 12 on page 251, an SRX Series device is deployed in an SD-WAN architecture to control traffic
using the source VRF. You need to configure policies to control the traffic. You can permit traffic from an
MPLS network to another MPLS network by configuring policies.
251
We recommend that you configure both the source VRF and the destination VRF when the source and
destination are from the MPLS network.
Figure 12: Permitting VRF-Based Traffic from an MPLS Network to an MPLS Network over GRE
without NAT
Configuration
IN THIS SECTION
Verification | 255
Procedure
set routing-instances VRF-a instance-type vrf

set routing-instances VRF-a route-distinguisher 10:200
set routing-instances VRF-a vrf-target target:100:100
set routing-instances VRF-a vrf-table-label
set routing-instances VRF-b instance-type vrf
set routing-instances VRF-b route-distinguisher 20:200
set routing-instances VRF-b vrf-target target:200:100
set routing-instances VRF-b vrf-table-label
set routing-instances VRF-a’ instance-type vrf
set routing-instances VRF-a’ route-distinguisher 30:200
set routing-instances VRF-a’ vrf-target target:300:100
252
set routing-instances VRF-a’ vrf-table-label

set routing-instances VRF-b’ instance-type vrf
set routing-instances VRF-b’ route-distinguisher 40:200
set routing-instances VRF-b’ vrf-target target:400:100
set routing-instances VRF-b’ vrf-table-label
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-a_policy match source-
address any
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-a_policy match
application any
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-a_policy match source-
l3vpn-vrf-group VRF-a
destination-l3vpn-vrf-group VRF-a’
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-a_policy then permit
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-b_policy match source-
address any
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-b_policy match
application any
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-b_policy match source-
l3vpn-vrf-group VRF-b
destination-l3vpn-vrf-group VRF-b’
set security policies from-zone GRE-1_Zone to-zone GRE-2_Zone policy vrf-b_policy then permit
CLI User Guide.
To configure a policy to permit traffic from an MPLS network to an MPLS network using source VRF:
253

5. Create a security policy to permit VRF-a traffic from the MPLS network.
[edit security policies from-zone GRE-1_Zone to-zone GRE-2_Zone]

user@host# set policy vrf-a_policy match source-l3vpn-vrf-group VRF-a
254
6. Create a security policy to permit VRF-b traffic from the MPLS network.
[edit security policies from-zone GRE-1_Zone to-zone GRE-2_Zone]

user@host# set policy vrf-b_policy match source-l3vpn-vrf-group VRF-b
Results
[edit]
from-zone GRE-1_Zone to-zone GRE-2_Zone {
match {
source-address any;
application any;
source-l3vpn-vrf-group VRF-a;
destination-l3vpn-vrf-group "VRF-a'";
}
then {
permit;
}
}
match {
source-address any;
application any;
source-l3vpn-vrf-grou VRF-b;
destination-l3vpn-vrf-group "VRF-b'";
}
then {
255
permit;
}
}
}
[edit]
VRF-a {
instance-type vrf;
vrf-table-label;
}
VRF-b {
instance-type vrf;
vrf-table-label;
}
VRF-a’ {
instance-type vrf;
vrf-table-label;
}
VRF-b’ {
instance-type vrf;
vrf-table-label;
}
Verification
IN THIS SECTION

256
Purpose
Verify that the security policy permits VRF based traffic from the IP network to the MPLS network.
Action

From zone: GRE-1_Zone, To zone: GRE-2_Zone
Source vrf: VRF-a
destination vrf: VRF-a'
Applications: any
Action: permit
Source vrf: VRF-b
destination vrf: VRF-b'
Applications: any
Action: permit
Example: Configuring Security Policies Using VRF Routing Instances in an

MPLS Network
IN THIS SECTION
Requirements | 257
Overview | 257
MPLS Network to Private IP Network | 257

257
Global IP Network to an MPLS Network | 260
This example shows how to configure security policies using VRF routing instances.
Requirements
Overview
In this example, you create security policies using virtual routing and forwarding (VRF) instances to
isolate traffic traversing in the following networks:
• An MPLS to a private IP network
• A Global IP to an MPLS network
MPLS Network to Private IP Network
IN THIS SECTION
Procedure | 258
258
Procedure
user@host#set VRF-a instance-type vrf
user@host#set VRF-b instance-type vrf
5. Create a security policy to permit traffic from VRF-a destined for LAN A.
[edit security policies from-zone GRE_Zone to-zone LAN-a_Zone]

set policy vrf-a_policy match source-address any
set policy vrf-a_policy match destination-address any
set policy vrf-a_policy match application any
set policy vrf-a_policy match source-l3vpn-vrf-group VRF-a
set policy vrf-a_policy then permit
259
6. Create a security policy to permit traffic from VRF-b destined for LAN B.
[edit security policies from-zone GRE_Zone to-zone LAN-b_Zone]

set policy vrf-b_policy match source-address any
set policy vrf-b_policy match destination-address any
set policy vrf-b_policy match application any
set policy vrf-b_policy match source-l3vpn-vrf-group VRF-b
set policy vrf-b_policy then permit
Results
instructions in this example to correct the configuration.

from-zone GRE_Zone to-zone LAN-a_Zone {
match {
source-address any;
application any;
}
then {
permit;
}
}
}
from-zone GRE_Zone to-zone LAN-b_Zone {
match {
source-address any;
application any;
source-l3vpn-vrf-group VRF-b;
}
then {
permit;
260
}
}
}
[edit]
VRF-a {
instance-type vrf;
vrf-table-label;
}
VRF-b {
instance-type vrf;
vrf-table-label;
}
Global IP Network to an MPLS Network
IN THIS SECTION
Verification | 265
Procedure
261

5. Create the destination NAT pool.
[edit security nat destination]

user@host# set pool vrf-a_p routing-instance VRF-a
user@host# set pool vrf-a_p address 20.0.0.4/24
user@host# set pool vrf-b_p routing-instance VRF-b
user@host# set pool vrf-b_p address 30.0.0.4/24
262
6. Create a destination NAT rule set.

user@host# set rule-set rs from interface ge-0/0/0.0
user@host# set rule-set rs rule vrf-a_r match destination-address 40.0.0.4/24
user@host# set rule-set rs rule vrf-a_r then destination-nat pool vrf-a_p
7. Configure a rule that matches packets and translates the destination address to the address in the
pool.

user@host# set rule-set rs from interface ge-0/0/1.0
user@host# set rule-set rs rule vrf-b_r match destination-address 50.0.0.4/24
user@host# set rule-set rs rule vrf-b_r then destination-nat pool vrf-b_p
8. Configure a security policy that allows traffic from the untrust zone to the server in the trust zone.
[edit security policies from-zone internet to-zone trust]

user@host# set policy vrf-a_policy_policy match application any
Results
From configuration mode, confirm your configuration by entering the show security policies, show routing-
instances, and the show security nat commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.

from-zone internet to-zone trust {
263
match {
source-address any;
application any;
destination-l3vpn-vrf-group VRF-a;
}
then {
permit;
}
}
match {
source-address any;
application any;
destination-l3vpn-vrf-group VRF-b;
}
then {
permit;
}
}
}
[edit]
VRF-a {
instance-type vrf;
vrf-table-label;
}
VRF-b {
instance-type vrf;
vrf-table-label;
}
VRF-a’ {
instance-type vrf;
264
vrf-table-label;
}
VRF-b’ {
instance-type vrf;
vrf-table-label;
}
user@host# show security nat destination

pool vrf-a_p {
routing-instance {
VRF-a’;
}
address 20.0.0.4/24;
}
pool vrf-b_p {
routing-instance {
VRF-b’;
}
address 30.0.0.4/24;
}
rule-set rs {
from interface [ ge-0/0/0.0 ge-0/0/1.0 ];
rule vrf-a_r {
match {
destination-address 40.0.0.4/24;
}
then {
destination-nat {
pool {
vrf-a_p;
}
}
}
}
rule vrf-b_r {
match {
destination-address 50.0.0.4/24;
265
}
then {
destination-nat {
pool {
vrf-b_p;
}
}
}
}
}
Verification
IN THIS SECTION
Verifying the Destination NAT Rule | 265
Verifying Flow Session | 266
Verifying the Destination NAT Rule
Purpose
Display information about all the destination NAT rules.
Action
From operational mode, enter the show security nat destination rule all command.
user@host> show security nat destination rule all

Total destination-nat rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 6/0
Destination NAT rule: rule1 Rule-set: vrf-b_r
Rule-Id : 2
Rule position : 2
From routing instance : vrf-b_r
Destination addresses : 50.0.0.4 - 50.0.0.4
266
Action : vrf-b_p
Translation hits : 0
Successful sessions : 0
Failed sessions : 0
Number of sessions : 0
[...Output truncated...]
Meaning
The command displays the destination NAT rule. View the Translation hits field to check for traffic that
matches the destination rule.
Verifying Flow Session
Purpose
Display information about all the currently active security sessions on the device.
Action
From operational mode, enter the show security flow session command.
user@host>show security flow session

Flow Sessions on FPC0 PIC1:
Session ID: 10115977, Policy name: SG/4, State: Active, Timeout: 62, Valid
In: 203.0.113.11/1000 203.0.113.1/2000;udp, Conn Tag: 0x0, If: reth1.1, VRF: VRF-a, Pkts: 1,
Bytes: 86, CP Session ID: 10320276
Out: 203.0.113.1/2000 203.0.113.11/1000;udp, Conn Tag: 0x0, If: reth0.0, VRF: VRF-b, Pkts: 0,
Bytes: 0, CP Session ID: 10320276
Meaning
The command displays details about all the active sessions. View the VRF field to check the VRF routing
instance details in the flow.
267
Flow Management in SRX Series Devices Using VRF Routing Instance

Understanding ALG Support for VRF Routing Instance
NAT for VRF Routing Instance
Configuring Security Policies Using VRF Group
IN THIS SECTION
Overview | 267
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from MPLS Network to an IP
Network using Source VRF Group | 269
Example: Configuring a Security Policy to Permit or Deny VRF-Based Traffic from an IP Network to MPLS
Network using Destination VRF Group | 274
Managing Overlapping VPN using VRF group | 280
Overview
In SD-WAN network, when different VRF based traffic enter the device from same tunnel such as GRE
or GE, the device applies policy based on the given VRF instance. The device either permit or deny
traffic destined to a particular VRF instance to control the VRF based traffic.
Currently, there are 5 matching conditions for each policy:
• From zone
• To zone
• Source address
• Destination address
• Applications
268
Figure 13 on page 268 shows the match conditions in a policy.
Figure 13: Match Conditions
With the current policy matching conditions, you cannot permit VRF-B1 or VRF-B2 and deny VRF-A1 or
VRF-A2. To support this, additional matching conditions are added to the policy in the SD-WAN
network using VRF group.
When the flow receives the information of source and destination VRF groups, it forwards the
information to policy search API along with the policy key tuple information to meet the match
conditions.
Figure 14 on page 268 shows the VRF groups added as match condition in a policy.
Figure 14: Match Conditions with VRF group
NOTE: If the source and destination VRF group information is not specified in a policy, then
these groups matches any VRF group.
269

Traffic from MPLS Network to an IP Network using Source VRF Group
IN THIS SECTION
Requirements | 269
Overview | 269
Configuration | 270
VRF group.
Requirements
• Understand how to create a security zone. See"Example: Creating Security Zones" on page 9 .
Overview
270
source VRF group. Traffic from the GRE MPLS network is sent to site A and site B of the IP network. As
per the network requirement, site A traffic should be denied, and only site B traffic should be permitted.
Figure 15: Policy Control from MPLS network
• Deny traffic from vpn-A (from GRE MPLS)
• Permit traffic from vpn-B (from GRE MPLS)
Configuration
IN THIS SECTION
Verification | 273
271
Procedure
set security l3vpn vrf-group vpn-A vrf VRF-A1

set security l3vpn vrf-group vpn-B vrf VRF-B1
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-a_policy match source-
address any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-a_policy match destination-
address any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-a_policy match application
any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-a_policy match source-l3vpn-
vrf-group vpn-A
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-a_policy then deny
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-b_policy match source-
address any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-b_policy match destination-
address any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-b_policy match application
any
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-b_policy match source-l3vpn-
vrf-group vpn-B
set security policies from-zone GRE_Zone to-zone GRE_Zone policy vrf-b_policy then permit
CLI User Guide.
272
1. Create VRF group vpn-A with VRF instances A1 and A2
[edit security]
user@host# set l3vpn vrf-group vpn-A vrf VRF-A1
2. Create VRF group vpn-B with VRF instances B1 and B2
[edit security]
user@host# set l3vpn vrf-group vpn-B vrf VRF-B1
3. Create a security policy to deny vpn-A traffic.
[edit security policies from-zone GRE_Zone to-zone GRE_Zone]

user@host# set policy vrf-a_policy match source-l3vpn-vrf-group vpn-A
4. Create a security policy to permit vpn-B traffic.
[edit security policies from-zone GRE_Zone to-zone GRE_Zone]

user@host# set policy vrf-b_policy match source-l3vpn-vrf-group vpn-B
273
Results
[edit]
from-zone GRE_Zone to-zone GRE_Zone {
match {
source-address any;
application any;
source-l3vpn-vrf-group vpn-A;
}
then {
deny;
}
}
match {
source-address any;
application any;
source-l3vpn-vrf-group vpn-B;
}
then {
permit;
}
}
Verification
IN THIS SECTION

274
Purpose
Action

From zone: GRE_Zone-GE_Zone, To zone: GRE_Zone
Source L3VPN VRF Group: vpn-A
destination L3VPN vrf-group: any
Applications: any
Action: deny
Source L3VPN VRF Group: vpn-B
destination L3VPN vrf-group: any
Applications: any
Action: permit

Traffic from an IP Network to MPLS Network using Destination VRF
Group
IN THIS SECTION
Requirements | 275
275
Overview | 275
Configuration | 276
VRF group.
Requirements
Overview
destination VRF group. Traffic from IP network is sent to site A and site B of the GRE MPLS network. As
per the network requirement, site A traffic should be denied, and only site B traffic should be permitted.
Figure 16: Policy control to MPLS network

276
• Deny traffic to vpn-A (to GRE MPLS)
• Permit traffic to vpn-B (to GRE MPLS)
Configuration
IN THIS SECTION
Verification | 279
Procedure

set security policies from-zone LAN-a_Zone to-zone GRE_Zone policy vrf-a_policy match source-
address any
application any
destination-l3vpn-vrf-group vpn-A
set security policies from-zone LAN-a_Zone to-zone GRE_Zone policy vrf-a_policy then deny
set security policies from-zone LAN-b_Zone to-zone GRE_Zone policy vrf-b_policy match source-
address any
application any
277
destination-l3vpn-vrf-group vpn-B
set security policies from-zone LAN-b_Zone to-zone GRE_Zone policy vrf-b_policy then permit
CLI User Guide.
1. Create VRF group vpn-A with VRF instances A1 and A2
[edit security]
2. Create VRF group vpn-B with VRF instances B1 and B2
[edit security]
3. Create a security policy to deny vpn-A traffic.
[edit security policies from-zone LAN-a_Zone to-zone GRE_Zone]

user@host# set policy vrf-a_policy match destination-l3vpn-vrf-group vpn-A
4. Create a security policy to permit vpn-B traffic.
[edit security policies from-zone LAN-b_Zone e to-zone GRE_Zone]

user@host# set policy vrf-b_policy match destination-l3vpn-vrf-group vpn-B
278
Results
[edit]
from-zone LAN-a_Zone to-zone GRE_Zone {
match {
source-address any;
application any;
destination-l3vpn-vrf-group vpn-A;
}
then {
deny;
}
}
}
from-zone LAN-b_Zone to-zone GRE_Zone {
match {
source-address any;
application any;
destination-l3vpn-vrf-group vpn-B;
}
then {
permit;
}
}
}
279
Verification
IN THIS SECTION
Purpose
Action

From zone: LAN-a_Zone, To zone: GRE_Zone
Source L3VPN VRF Group: any
destination L3VPN vrf-group: vpn-A
Applications: any
Action: deny
From zone: LAN-b_Zone, To zone: GRE_Zone
Source L3VPN VRF Group: any
destination L3VPN vrf-group: vpn-B
Applications: any
Action: permit
280
Managing Overlapping VPN using VRF group
When there are two sessions in a L3VPN network, to avoid any conflicts between the two sessions VRF
group-ID is added to session key as an additional key to differentiate the sessions.
In Figure 17 on page 280 network1 and network3 are grouped together to VRF group-A in L3VPN
network, and network2 and network4 are grouped together to VRF group-B. The sessions use VRF
group-A and VRF group-B as differentiators.
Figure 17: Overlapping VPN using VRF groups
Table 30 on page 280
Table 30: L3VPN Session Information
L3VPN Network 1 and 3 session L3VPN Network 2 and 4 session
(Forward) (Reverse) (Forward) (Reverse)
5-tuple: x/y/sp/dp/p 5-tuple: y/x/dp/sp/p 5-tuple: x/y/sp/dp/p 5-tuple: y/x/dp/sp/p
Token: GRE1(zone_id Token: GRE1(zone_id Token: GRE1(zone_id Token: GRE1(zone_id

+VR_id) + VRF group-ID +VR_id) + VRF group-ID +VR_id) + VRF group-ID +VR_id) + VRF group-ID
(A) (B) (A’) (B’)
281
Flow Processing using Virtual Routing and Forwarding Group
Monitoring and Troubleshooting Security Policies
IN THIS SECTION
Understanding Security Alarms | 281
Example: Generating a Security Alarm in Response to Policy Violations | 282
Matching Security Policies | 285
Tracking Policy Hit Counts | 287
Verifying Shadow Policies | 290
High Availability (HA) Synchronization of Address Name Resolving Cache | 297
Monitoring provides a real-time presentation of meaningful data representing the state of access
activities on a network. This insight allows you to easily interpret and effect operational conditions.
Troubleshooting provides contextual guidance for resolving the access issues on networks. You can then
address user concerns and provide resolution in a timely manner.
Understanding Security Alarms
Alarms are triggered when packets are dropped because of a policy violation. A policy violation occurs
when a packet matches a reject or deny policy. A policy violation alarm is generated when the system
monitors any of the following audited events:
• Number of policy violations by a source network identifier within a specified period
• Number of policy violations to a destination network identifier within a specified period
• Number of policy violations to an application within a specified period

282
• Policy rule or group of rule violations within a specified period
There are four types of alarms corresponding to these four events. The alarms are based on source IP,
destination IP, application, and policy.
When a packet encounters a reject or deny policy, the policy violation counters for all enabled types of
alarm are increased. When any counter reaches the specified threshold within a specified period, an
alarm is generated. After a specified period, the policy violation counter is reset and reused to start
another counting cycle.
To view the alarm information, run the show security alarms command. The violation count and the alarm
do not persist across system reboots. After a reboot, the violation count resets to zero and the alarm is
cleared from the alarm queue.
After taking appropriate actions, you can clear the alarm. The alarm remains in the queue until you clear
it (or until you reboot the device). To clear the alarm, run the clear security alarms command. After you
clear the alarm, a subsequent series of flow policy violations can cause a new alarm to be raised.
SEE ALSO
Example: Setting an Audible Alert as Notification of a Security Alarm
Example: Generating a Security Alarm in Response to Policy Violations
IN THIS SECTION
Requirements | 282
Overview | 283
Configuration | 283
Verification | 285
This example shows how to configure the device to generate a system alarm when a policy violation
occurs. By default, no alarm is raised when a policy violation occurs.
Requirements
283
Overview
In this example, you configure an alarm to be raised when:
• The application size is 10240 units.
• The source IP violation exceeds 1000 within 20 seconds.
• The destination IP violations exceeds 1000 within 10 seconds.
• The policy match violation exceeds 100, with a size of 100 units.
Configuration
IN THIS SECTION
Procedure | 283
Procedure
commands into the CLI at the [edit] hierarchy level , and then enter commit from configuration mode.
set security alarms potential-violation policy application size 10240

set security alarms potential-violation policy source-ip threshold 1000 duration 20
set security alarms potential-violation policy destination-ip threshold 1000 duration 10
set security alarms potential-violation policy policy-match threshold 100 size 100
instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure policy violation alarms:

284
1. Enable security alarms.
[edit]
user@host# edit security alarms
2. Specify that an alarm should be raised when an application violation occurs.
[edit security alarms potential-violation policy]

user@host# set application size 10240
3. Specify that an alarm should be raised when a source IP violation occurs.

user@host# set source-ip threshold 1000 duration 20
4. Specify that an alarm should be raised when a destination IP violation occurs.

user@host# set destination-ip threshold 1000 duration 10
5. Specify that an alarm should be raised when a policy match violation occurs.

user@host# set policy-match threshold 100 size 100
Results
From configuration mode, confirm your configuration by entering the show security alarms command. If
policy {
source-ip {
threshold 1000;
duration 20;
}
destination-ip {
285
threshold 1000;
duration 10;
}
application {
size 10240;
}
policy-match {
threshold 100;
size 100;
}
}
Verification
To confirm that the configuration is working properly, from operational mode, enter the show security
alarms command.
Matching Security Policies
The show security match-policies command allows you to troubleshoot traffic problems using the match
criteria: source port, destination port, source IP address, destination IP address, and protocol. For
example, if your traffic is not passing because either an appropriate policy is not configured or the match
criteria is incorrect, the show security match-policies command allows you to work offline and identify
where the problem actually exists. It uses the search engine to identify the problem and thus enables
you to use the appropriate match policy for the traffic.
The result-count option specifies how many policies to display. The first enabled policy in the list is the
policy that is applied to all matching traffic. Other policies below it are “shadowed” by the first and are
never encountered by matching traffic.
NOTE: The show security match-policies command is applicable only to security policies; IDP
policies are not supported.
Example 1: show security match-policies
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1

destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
286
Policy: p1, action-type: permit, State: enabled, Index: 4

Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 203.0.113.1/25
a3: 10.10.10.1/32
d2: 203.0.113.129/25
d3: 192.0.2.1/24
Application: junos-ftp
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Example 2: Using the result-count Option
By default, the output list contains the policy that will be applied to traffic with the specified
characteristics. To list more than one policy that match the criteria, use the result-count option. The first
policy listed is always the policy that will be applied to matching traffic. If the result-count value is from 2
to 16, the output includes all policies that match the criteria up to the specified result-count. All policies
listed after the first are “shadowed” by the first policy and are never applied to matching traffic.
Use this option to test the positioning of a new policy or to troubleshoot a policy that is not applied as
expected for particular traffic.
In the following example, the traffic criteria matches two policies. The first policy listed, p1, contains the
action applied to the traffic. Policy p15 is shadowed by the first policy, and its action, therefore, will not
be applied to matching traffic.
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1
destination-ip 192.0.2.1 source-port 1004 destination-port 80 protocol tcp result-count 5
Sequence number: 1
From zone: zone-A, To zone: zone-B
Source addresses:
sa1: 10.10.0.0/16
da5: 192.0.2.0/24
Application: any
287
Policy: p15, action-type: deny, State: enabled, Index: 18

Sequence number: 15
Source addresses:
sa11: 10.10.10.1/32
da15: 192.0.2.5/24
Application: any
SEE ALSO

Tracking Policy Hit Counts
Use the show security policies hit-count command to display the utility rate of security policies according
to the number of hits they receive. You can use this feature to determine which policies are being used
on the device, and how frequently they are used. Depending on the command options that you choose,
the number of hits can be listed without an order or sorted in either ascending or descending order, and
they can be restricted to the number of hits that fall above or below a specific count or within a range.
Data is shown for all zones associated with the policies or named zones.
Checking Memory Usage on SRX Series Devices
You can isolate memory issues by comparing memory values before and after policy configurations.
Memory for flow entities such as policies, zones, or addresses on SRX1400, SRX1500, SRX3400,
SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, and SRX5800 devices (depending on the
Junos OS release in your installation) is dynamically allocated. However, certain practices can help
monitor the current memory usage on the device and optimize parameters to better size system
configuration, especially during policy implementation.
To check memory usage:

288
• Use the show chassis routing-engine command to check overall Routing Engine (RE) memory usage. The
following output from this command shows memory utilization at 39 percent:
user@host# show chassis routing-engine

Routing Engine status:
Slot 0:
Current state Master
Election priority Master (default)
DRAM 1024 MB
Memory utilization 39 percent
CPU utilization:
User 0 percent
Background 0 percent
Kernel 2 percent
Interrupt 0 percent
Idle 97 percent
Model RE-PPC-1200-A
Start time 2011-07-09 19:19:49 PDT
Uptime 37 days, 15 hours, 44 minutes, 13 seconds
Last reboot reason 0x3:power cycle/failure watchdog
Load averages: 1 minute 5 minute 15 minute
0.22 0.16 0.07
• Use the show system processes extensive command to acquire information on the processes running on
the Routing Engine.
Use the find nsd option in the show system processes extensive command to see direct usage on the
Network Security Daemon (NSD) with its total memory in use as 10 megabytes and CPU utilization
of 0 percent.
user@host# show system processes extensive | find nsd

1182 root 1 96 0 10976K 5676K select 2:08 0.00% nsd
1191 root 4 4 0 8724K 3764K select 1:57 0.00% slbd
1169 root 1 96 0 8096K 3520K select 1:51 0.00% jsrpd
1200 root 1 4 0 0K 16K peer_s 1:10 0.00% peer proxy
1144 root 1 96 0 9616K 3528K select 1:08 0.00% lacpd
1138 root 1 96 0 6488K 2932K select 1:02 0.00% ppmd
1130 root 1 96 0 7204K 2208K select 1:02 0.00% craftd
1163 root 1 96 0 16928K 5188K select 0:58 0.00% cosd
1196 root 1 4 0 0K 16K peer_s 0:54 0.00% peer proxy
289
47 root 1 -16 0 0K 16K sdflus 0:54 0.00% softdepflush

1151 root 1 96 0 15516K 9580K select 0:53 0.00% appidd
900 root 1 96 0 5984K 2876K select 0:41 0.00% eventd
• Check the configuration file size. Save your configuration file with a unique name before exiting the
CLI. Then, enter the ls -1 filename command from the shell prompt in the UNIX-level shell to check
the file size as shown in the following sample output:
user@host> start shell

% ls -l config
-rw-r--r-- 1 remote staff 12681 Feb 15 00:43 config
SEE ALSO

Monitoring Security Policy Statistics
IN THIS SECTION
Purpose | 289
Action | 289
Purpose
Monitor and record traffic that Junos OS permits or denies based on previously configured policies.
Action
To monitor traffic, enable the count and log options.
Count—Configurable in an individual policy. If count is enabled, statistics are collected for sessions that
enter the device for a given policy, and for the number of packets and bytes that pass through the
290
device in both directions for a given policy. For counts (only for packets and bytes), you can specify that
alarms be generated whenever the traffic exceeds specified thresholds. See count (Security Policies).
Log—Logging capability can be enabled with security policies during session initialization (session-init) or
session close (session-close) stage. See log (Security Policies).
• To view logs from denied connections, enable log on session-init.
• To log sessions after their conclusion/tear-down, enable log on session-close.
NOTE: Session log is enabled at real time in the flow code which impacts the user performance.
If both session-close and session-init are enabled, performance is further degraded as compared
to enabling session-init only.
For details about information collected for session logs, see Information Provided in Session Log Entries
for SRX Series Services Gateways.
Verifying Shadow Policies
IN THIS SECTION
Verifying All Shadow Policies | 290
Verifying a Policy Shadows One or More Policies | 291
Verifying a Policy Is Shadowed by One or More Policies | 292
Verifying All Shadow Policies
IN THIS SECTION
Purpose | 291
Action | 291
Meaning | 291
291
Purpose
Verify all the policies that shadows one or more policies.
Action
From the operational mode, enter the following commands:
• For logical systems, enter the show security shadow-policies logical-system lsys-name from-zone from-zone-
name to-zone to-zone-name command.
• For global policies, enter the show security shadow-policies logical-system lsys-name global command.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b

Policies Shadowed policies
P1 P3
P1 P4
P2 P5
Meaning
The output displays the list of all policies that shadows other policies. In this example, P1 policy
shadows P3 and P4 policies and P2 policy shadows P5 policy.
Verifying a Policy Shadows One or More Policies
IN THIS SECTION
Purpose | 291
Action | 292
Meaning | 292
Purpose
Verify if a given policy shadows one or more policies positioned after it.
292
Action
name to-zone to-zone-name policy policy-name command.
• For global policies, enter the show security shadow-policies logical-system lsys-name global policy policy-
name command.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1

P1 P3
P1 P4
Meaning
The output displays all the policies that are shadowed by the given policy. In this example, P1 policy
shadows P3 and P4 policies.
Verifying a Policy Is Shadowed by One or More Policies
IN THIS SECTION
Purpose | 292
Action | 292
Meaning | 293
Purpose
Verify if a given policy is shadowed by one or more positioned before it.
Action
name to-zone to-zone-name policy policy-name reverse command.
293
• For global policies, enter the show security shadow-policies logical-system lsys-name global policy policy-
name reverse command.
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
P1 P4
Meaning
The output displays the given policy shadowed by one or more policies. In this example, P4 policy is
shadowed by P1 policy.

Troubleshooting Security Policies
IN THIS SECTION
Synchronizing Policies Between Routing Engine and Packet Forwarding Engine | 293
Checking a Security Policy Commit Failure | 295
Verifying a Security Policy Commit | 295
Debugging Policy Lookup | 296
Synchronizing Policies Between Routing Engine and Packet Forwarding Engine
IN THIS SECTION
Problem | 294
294
Solution | 294
Problem
Description
Security policies are stored in the routing engine and the packet forwarding engine. Security policies are
pushed from the Routing Engine to the Packet Forwarding Engine when you commit configurations. If
the security policies on the Routing Engine are out of sync with the Packet Forwarding Engine, the
commit of a configuration fails. Core dump files may be generated if the commit is tried repeatedly. The
out of sync can be due to:
• A policy message from Routing Engine to the Packet Forwarding Engine is lost in transit.
• An error with the routing engine, such as a reused policy UID.
Environment
The policies in the Routing Engine and Packet Forwarding Engine must be in sync for the configuration
to be committed. However, under certain circumstances, policies in the Routing Engine and the Packet
Forwarding Engine might be out of sync, which causes the commit to fail.
Symptoms
When the policy configurations are modified and the policies are out of sync, the following error
message displays - error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request
security policies check/resync.
Solution
Use the show security policies checksum command to display the security policy checksum value and use
the request security policies resync command to synchronize the configuration of security policies in the
Routing Engine and Packet Forwarding Engine, if the security policies are out of sync.
SEE ALSO

295
Checking a Security Policy Commit Failure
IN THIS SECTION
Problem | 295
Solution | 295
Problem
Description
Most policy configuration failures occur during a commit or runtime.
Commit failures are reported directly on the CLI when you execute the CLI command commit-check in
configuration mode. These errors are configuration errors, and you cannot commit the configuration
without fixing these errors.
Solution
To fix these errors, do the following:
1. Review your configuration data.
2. Open the file /var/log/nsd_chk_only. This file is overwritten each time you perform a commit check
and contains detailed failure information.
Verifying a Security Policy Commit
IN THIS SECTION
Problem | 296
Solution | 296
296
Problem
Description
Upon performing a policy configuration commit, if you notice that the system behavior is incorrect, use
the following steps to troubleshoot this problem:
Solution
1. Operational show Commands—Execute the operational commands for security policies and verify
that the information shown in the output is consistent with what you expected. If not, the
configuration needs to be changed appropriately.
2. Traceoptions—Set the traceoptions command in your policy configuration. The flags under this
hierarchy can be selected as per user analysis of the show command output. If you cannot determine
what flag to use, the flag option all can be used to capture all trace logs.
user@host# set security policies traceoptions <flag all>
You can also configure an optional filename to capture the logs.
user@host# set security policies traceoptions <filename>
If you specified a filename in the trace options, you can look in the /var/log/<filename> for the log file to
ascertain if any errors were reported in the file. (If you did not specify a filename, the default filename is
eventd.) The error messages indicate the place of failure and the appropriate reason.
After configuring the trace options, you must recommit the configuration change that caused the
incorrect system behavior.
Debugging Policy Lookup
IN THIS SECTION
Problem | 297
Solution | 297
297
Problem
Description
When you have the correct configuration, but some traffic was incorrectly dropped or permitted, you
can enable the lookup flag in the security policies traceoptions. The lookup flag logs the lookup related
traces in the trace file.
Solution
user@host# set security policies traceoptions <flag lookup>
High Availability (HA) Synchronization of Address Name Resolving Cache
The Network security process (NSD) restarts when system reboots, HA failover happens, or if the
process crashes. During this time, if there are large number of domain name addresses configured in the
security polices, SRX Series devices attempt to send requests to DNS server to get all resolved IP
addresses. A high amount of system resources are consumed when a large number of DNS queries and
responses are exchanged. So, SRX Series devices are unable to obtain a response from the DNS server
and the address of a hostname in an address book entry might fail to resolve correctly. This can cause
traffic to drop as no security policy or session match is found. The new enhancement on SRX Series
devices addresses this problem by caching the DNS query results into a local DNS cache file and
periodically synchronizing the DNS cache file from HA primary node to HA backup node. The DNS
cache files stores IP addresses, domain name, and TTL values. After the HA failover, the previous backup
node becomes primary node. Since all DNS cache results are available on new primary node, security
policy processing continues and pass-through traffic is allowed as per the policy rules.
Starting in Junos OS Release 19.3R1, the policy DNS cache memory is synchronized into one local DNS
cache file on the HA active node and is copied to the HA backup node to suppress DNS queries or
responses during NSD restart.
The following steps are performed for the synchronization to take place:
1. The policy DNS cache memory is synchronized into one local policy DNS cache file located at
the /var/db/policy_dns_cache path every 30 seconds if the policy DNS cache memory content has
changed during this period.
2. The local DNS cache file is synchronized from the HA primary node to HA backup node immediately
after the local DNS cache file has been updated in Step 1.
The synchronization includes the following content:

298
• Domain name
• IPv4 address list and its TTL (time to live)
• IPv6 address list and its TTL
When NSD restarts, it reads and parses the local DNS cache file and imports all cache entries into
memory. The synchronization ensures that DNS queries are suppressed during an NSD restart. NSD
restarts on new primary node during HA failover as the resolved IP addresses for domain names already
exist in DNS cache memory when reading policies configurations. Therefore, new pass-through traffic is
allowed as per the security policy after HA failover because all resolved IP addresses for domain names
exist inside policies on new primary node’s Routing Engine and Packet Forwarding Engine.

6 CHAPTER
Configuration Statements
address (Security Address Book) | 304
address-book | 306
address-set | 308
alarms (Security) | 310
alarm-threshold | 312
alarm-without-drop | 314
application (Applications) | 315
application (Security Alarms) | 319
application (Security Policies) | 321
application-services (Security Policies) | 326
application-tracking (Security Zones) | 330
application-traffic-control (Application Services) | 331
attach | 333
audible (Security Alarms) | 335
authentication (Security Alarms) | 336
captive-portal (Services UAC Policy) | 338
count (Security Policies) | 340
default-policy | 341
deny (Security Policies) | 343

description (Applications) | 344
description (Security Address Book) | 346
description (Security Zone) | 347
destination-address (Security Policies) | 349
destination-address (Security Policies Flag) | 351
destination-address-excluded | 353
destination-ip (Security Alarms) | 354
dns-cache | 362
dns-proxy | 364
dynamic-address | 366
dynamic-dns | 372
exclude (Schedulers) | 374
feed-server | 376
firewall-authentication (Security Policies) | 379
forward-only (DNS) | 381
from-zone (Security Policies) | 383
from-zone (Security Policies Global) | 387
functional-zone | 389
global (Security Policies) | 391
host-inbound-traffic | 394
icmp-code (Applications) | 396
icmp-type (Applications) | 398
inactivity-timeout (Applications) | 399
interfaces (Security Zones) | 401
ipsec-group-vpn (Security Policies) | 404
ipsec-vpn (Security Policies) | 406
log (Security Policies) | 408
management (Security Zones) | 410
match (Security Policies) | 412
match (Security Policies Global) | 414

no-policy-cold-synchronization | 418
pair-policy | 420
pass-through | 421
permit (Security Policies) | 424
policies | 427
policy (Security Alarms) | 437
policy (Security Policies) | 439
policy-match | 443
policy-stats | 447
potential-violation | 448
protocol (Applications) | 458
protocols (Security Zones Host Inbound Traffic) | 460
protocols (Security Zones Interfaces) | 463
range-address | 465
redirect-wx (Application Services) | 467
reject (Security) | 468
report-skip | 470
rpc-program-number (Applications) | 474
scheduler (Security Policies) | 475
scheduler-name | 478
schedulers (Security Policies) | 479
screen (Security Zones) | 481
secure-neighbor-discovery | 482
security-intelligence (security policies) | 484
security-zone | 486
sequence-check-required | 489
services-offload (Security) | 490
session-close | 492
session-init | 493
session-scan | 495
simple-mail-client-service | 496
source-address (Security Policies) | 498
source-address-excluded | 500
source-identity | 501
source-ip (Security Alarms) | 504
source-port (Applications) | 506
ssl-proxy (Application Services) | 507
ssl-termination-profile | 509
start-date | 510
start-time (Schedulers) | 512
stop-date | 514
stop-time | 515
syn-check-required | 517
system-services (Security Zones Host Inbound Traffic) | 519
system-services (Security Zones Interfaces) | 522
tcp-options (Security Policies) | 525
tcp-rst | 528
term (Applications) | 529
then (Security Policies) | 531
to-zone (Security Policies) | 536
to-zone (Security Policies Global) | 539
traceoptions (dynamic-address) | 541
traceoptions (dynamic-application) | 543
traceoptions (Security Policies) | 546
traceoptions (Security User Identification) | 549
traceoptions (System Services DNS) | 551
tunnel (Security Policies) | 555
tunnel-inspection | 556
uac-policy (Application Services) | 558
unidirectional-session-refreshing | 560
user-firewall | 563
user-identification | 565
utm-policy | 567
uuid (Applications) | 570
vrrp | 571
web-authentication | 573
web-redirect | 575
zones | 577
304
address (Security Address Book)
IN THIS SECTION
Syntax | 304
Hierarchy Level | 304
Description | 305
Options | 305
Required Privilege Level | 305
Release Information | 305
Syntax
address address-name {
ip-prefix {
description text;
}
description text;
dns-name domain-name {
ipv4-only;
ipv6-only;
}
range-address lower-limit to upper-limit;
wildcard-address ipv4-address/wildcard-mask;
}
Hierarchy Level
[edit security address-book book-name]

305
Description
Add an entry containing an IP address or DNS hostname, or wildcard address to the address book. An
address book contains entries for addressable entities in security zones, policies, and NAT rules. Address
book entries can include any combination of IPv4 addresses, IPv6 addresses, and DNS names.
Options
• address address-name—Name of an address entry.
• description text—Descriptive text about an address entry.
• dns-address domain-name—DNS address name.
• ip-prefix—IP address with prefix.
• range-address lower-limit to upper-limit—Address range for an address book.
• wildcard-address ipv4-address/wildcard-mask—IPv4 wildcard address in the form of A.B.C.D/wildcard-mask.
NOTE: IPv6 wildcard address configuration is not supported in this release.
Required Privilege Level
security—To view this statement in the configuration.
security-control—To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 8.5. Support for IPv6 addresses added in Junos OS Release
10.2. Support for IPv6 addresses in active/active chassis cluster configurations (in addition to the
existing support of active/passive chassis cluster configurations) added in Junos OS Release 10.4.
Support for wildcard addresses added in Junos OS Release 11.1. Support for address range added in
Junos OS Release 12.1. The description option added in Junos OS Release 12.1.
306
address-book
IN THIS SECTION
Syntax | 306
Description | 307
Options | 307
Syntax
address-book (book-name | global) {

address (Security Address Book) address-name {
ip-prefix {
description text;
}
description text;
ipv4-only;
ipv6-only;
}
}
address-set address-set-name {
address address-name;
address-set address-set-name;
description text;
}
attach {
zone zone-name;
}
307
description (Security Address Book) text;

}
Hierarchy Level
[edit security]
[edit tenants tenant-name security]
Description
Define entries in the address book. Address book entries can include any combination of IPv4 addresses,
IPv6 addresses, DNS names, wildcard addresses, and address range. You define addresses and address
sets in an address book and then use them when configuring different features, such as security policies
and NAT.
NOTE: IPv6 wildcard address configuration is not supported in this release.
Options
• address-book book-name—Name of the address book.
• global—An address book that is available by default. You can add any combination of IPv4 addresses,
IPv6 addresses, wildcard addresses, DNS names, or address range to the global address book. You do
not need to attach the global address book to a security zone; entries in the global address book are
available to all security zones that are not attached to address books.
The remaining statements are explained separately. See CLI Explorer.

308
tenants—To view this statement in the configuration.
Release Information
Statement introduced in Junos OS Release 8.5. Statement introduced in Junos OS Release 18.3R1 for
tenant systems. Support for wildcard addresses added in Junos OS Release 11.1. Statement moved
under the security hierarchy in Junos OS Release 11.2. Support for address range added in Junos OS
Release 12.1. The description option added in Junos OS Release 12.1.

address-set
IN THIS SECTION
Syntax | 309
Description | 309
Options | 309

309
Syntax
description text;
}
Hierarchy Level
Description
Specify a collection of addresses, as defined in the address (Address Book) statement. Using address sets,
you can organize addresses in logical groups and use them to easily configure other features, such as
policies and NAT rules. Using this statement, you can also include a description for an address set.
You can also define address sets within address sets.
Options
address-set-name—Name of the address set.

310
Release Information
Statement introduced in Junos OS Release 8.5. Support for nested address sets introduced in Junos OS
alarms (Security)
IN THIS SECTION
Syntax | 310
Description | 312
Options | 312
Syntax
alarms {
audible {
continuous;
}
potential-violation {
authentication failures;
cryptographic-self-test;
decryption-failures {
threshold value;
}
encryption-failures {
threshold value;
}
idp;
ike-phase1-failures {
311
threshold value;
}
threshold value;
}
key-generation-self-test;
non-cryptographic-self-test;
policy {
application {
duration interval;
size count;
threshold value;
}
destination-ip {
duration interval;
size count;
threshold value;
}
policy match {
duration interval;
size count;
threshold value;
}
source-ip {
duration interval;
size count;
threshold value;
}
}
replay-attacks {
threshold value;
}
security-log-percent-full percentage;
}
}
Hierarchy Level
[edit security]
312
Description
Configures security alarms.
Options
Release Information
Statement introduced in Junos OS Release 11.2.
alarm-threshold
IN THIS SECTION
Syntax | 313
Description | 313
313
Options | 313
Syntax
alarm-threshold number;
Hierarchy Level
[edit security screen ids-option screen-name tcp syn-flood]
Description
Define the number of half-complete proxy connections per second at which theSRX300, SRX320,
SRX340, SRX345, SRX380, or SRX550M device makes entries in the event alarm log.
Options
number —Threshold value.
• Range: 1 through 500,000 per second
• Default: 1024 per second
NOTE: For SRX Series devices the applicable range is 1 through 1,000,000 per second.
314
Release Information
Statement modified in Junos OS Release 9.2.
alarm-without-drop
IN THIS SECTION
Syntax | 314
Description | 315
Syntax
alarm-without-drop;
315
Hierarchy Level
[edit security screen ids-option screen-name]
Description
Direct the SRX device to generate an alarm when detecting an attack but not block the attack. Use this
statement to allow an attack to enter a segment of your network that you have previously prepared to
receive it (for example, a honeynet, which is a decoy network with extensive monitoring capabilities).
Release Information
application (Applications)
IN THIS SECTION
Syntax | 316
316
Description | 317
Options | 317
Syntax
application application-name {
application-protocol (dns | ftp |gprs-gtp-c| gprs-gtp-u | gprs-gtp-v0 |gprs-sctp | http |
ignore | ike-esp-nat | mgcp-ca | mgcp-ua | ms-rpc | q931 | ras | realaudio | rsh | rtsp
| sccp | sip | sqlnet-v2 | sun-rpc | talk | tftp);
description text;
destination-port port-identifier;
do-not-translate-A-query-to-AAAA-query;
do-not-translate-AAAA-query-to-A-query;
ether-type hex-value;
icmp-code value;
icmp-type value;
icmp6-code value;
icmp6-type value;
inactivity-timeout (seconds | never);
protocol number;
rpc-program-number number;
source-port port-number;
term term-name {
alg application;
icmp-code value;
icmp-type value;
icmp6-code value;
icmp6-type value;
protocol number;
uuid hex-value;
317
}
uuid hex-value;
}
Hierarchy Level
[edit applications]
Description
Configure application properties at the [applications] hierarchy level.
Options
• application-protocol protocol-name—Specify the name of the application protocol.
• description text—Describe the application.
• destination-port port-identifier—Specify a TCP or UDP destination port number.
• do-not-translate-A-query-to-AAAA-query—Set the statement to control the translation of A query to AAAA

query.
• do-not-translate-AAAA-query-to-A-query—Set the statement to control the translation of AAAA query to A

query.
• ether-type value—Specify the Ethernet packet type value.
• icmp-code value—Specify the Internet Control Message Protocol (ICMP) code value.
Range: 0 through 255.
• icmp-type value—Specify the ICMP packet type value.
• icmp6-code value—Specify the ICMP6 code value.

318
• icmp6-type value—Specify the ICMP6 packet type value.
• inactivity-timeout (seconds | never)—Specify the amount of time the application is inactive before it
times out in seconds.
Range: 4 through 129,600 seconds.
Default: For TCP, 1800 seconds; for UDP, 60 seconds.
• protocol value—Specify the networking protocol name or number.
• rpc-program-number value—Specify the remote procedure call (RPC) or Distributed Computing

Equipment (DCE) value.
• source-port port-number—Specify a TCP or UDP source port number.
• term term-name—Specify the individual application protocol.
• alg application—Specify the name of the application protocol.
• destination-port port-identifier—Specify a TCP or UDP destination port number.
• icmp-code value—Specify the ICMP code value.
• icmp-type value—Specify the ICMP packet type value.
• icmp6-code value—Specify the ICMP6 code value.
• icmp6-type value—Specify the ICMP6 packet type value.
• inactivity-timeout (seconds | never)—Specify the amount of time the application is inactive before it
times out in seconds.
Range: 4 through 129,600 seconds.
• protocol number—Specify the networking protocol name or number.

319
• rpc-program-number number—Specify the RPC or DCE value.
• source-port port-number—Specify a TCP or UDP source port number.
• uuid hex-vale—Specify the universal unique identifier (UUID) for objects.
• uuid hex-value—Specify the UUID for objects.
Release Information
alg (Applications)
application (Security Alarms)
IN THIS SECTION
Syntax | 320
Description | 320
Options | 320
320
Syntax
application {
duration interval;
size count;
threshold value;
}
Hierarchy Level
Description
Configure alarms for a number of policy violations to an application within a specified time period.
Options
• duration interval—Indicate the duration of counters.
• Range: 1 through 3600 seconds.
• Default: 1 second.
• size count—Indicate the number of applications for which policy violation checks can be done
concurrently.
321
• Range: 1 through 10240.
• Default: 1024.
• threshold value—Indicate the maximum number of application matches required to raise an alarm.
• Default: 1000.
Release Information
application (Security Policies)
IN THIS SECTION
Syntax | 322
Description | 322
Options | 322

322
Syntax
application {
[application];
any;
}
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name match]
[edit security policies global policy policy-name match]
Description
Specify the IP or remote procedure call (RPC) application or set of applications to be used as match
criteria.
Starting in Junos OS Release 19.1R1, configuring the application statement at the [edit security policies
from-zone zone-name to-zone zone-name policy policy-name match] hierarchy level is optional if the dynamic-
application statement is configured at the same hierarchy level.
Options
application- Name of the predefined or custom application or application set used as match
name-or-set criteria.
323
any Any predefined or custom applications or application sets.
NOTE: A custom application that does not use a predefined destination port
for the application will not be included in the any option, and must be named
explicitly.
Release Information

application-protocol (Applications)
IN THIS SECTION
Syntax | 324
Description | 324
Default | 326
324
Syntax
application-protocol (bootp | dce-rpc | dce-rpc-portmap | dns | exec | ftp | ftp-data | gprs-gtp-

c | gprs-gtp-u | gprs-gtp-v0 | gprs-sctp | h323 | http | https | icmp | icmpv6 | ignore | iiop |
ike-esp-nat | imap | imaps | ip | login | mgcp-ca | mgcp-ua | ms-rpc | netbios | netshow | none
| pop3 | pop3s | pptp | q931 | ras | realaudio | rpc | rpc-portmap | rsh | rtsp | sccp | shell |
sip | smtp | smtps | snmp | sqlnet | sqlnet-v2 | ssh | sun-rpc | talk | telnet | tftp |
traceroute | twamp | winframe);
Hierarchy Level
[edit applications application],

[edit logical-systems name applications application],
[edit logical-systems name tenants name applications application],
[edit tenants name applications application]
Description
Identify the application protocol name. Application protocols are also called application layer gateways
(ALGs). Define an application layer gateway (ALG) for a particular application. The following ALGs are
supported:
protocol-name—Name of the protocol. The following protocols are supported:
1. bootp—Bootstrap protocol
2. dce-rpc—DCE RPC
3. dce-rpc-portmap—DCE RPC portmap

325
4. dns—Domain Name Service
5. exec—Remote Execution Protocol
6. ftp—File Transfer Protocol
7. h323—H.323
8. icmp—ICMP
9. iiop—Internet Inter-ORB Protocol
10. ike-esp-nat—IKE ALG
11. ip—IP
12. login—Login
13. netbios—NetBIOS
14. netshow—NetShow
15. pptp—Point-to-Point Tunneling Protocol
16. ras—Gatekeeper RAS for H323
17. realaudio—RealAudio
18. rpc—RPC
19. rpc-portmap—RPC portmap
20. rtsp—Real Time Streaming Protocol
21. shell—Shell
22. sip—Session Initiation Protocol
23. snmp—SNMP
24. sqlnet—SQLNet
25. talk–Talk Program
26. tftp–Trivial File Transfer Protocol
27. traceroute—Traceroute
28. winframe—WinFrame
326
Default
If application-protocol is not defined, then traffic enters the ALG process as long the status for this ALG is
enabled.
system—To view this statement in the configuration.
system-control—To add this statement to the configuration.
Release Information
Statement introduced before Junos OS Release 7.4.
login options introduced in Junos OS Release 7.4.
ip option introduced in Junos OS Release 8.2.
ike-esp-nat option introduced in Junos OS Release 17.1.
ras option introduced in Junos OS Release 17.1.
application-services (Security Policies)
IN THIS SECTION
Syntax | 327

327
Description | 328
Options | 328
Syntax
advanced-anti-malware-policy advanced-anti-malware-policy;
rule-set rule-set;
}
application-traffic-control {
rule-set rule-set;
}
gprs-gtp-profile gprs-gtp-profile;
gprs-sctp-profile gprs-sctp-profile;
idp idp;
packet-capture;
(redirect-wx redirect-wx | reverse-redirect-wx reverse-redirect-wx);
security-intelligence-policy security-intelligence-policy;
security-intelligence {
add-destination-identity-to-feed feed-name;
add-destination-ip-to-feed feed-name;
add-source-identity-to-feed feed-name;
add-source-ip-to-feed feed-name;
}
security-metadata-streaming-policy policy-name
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy utm-policy;
web-proxy {
328
}
}
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then permit]
Description
Enable application services within a security policy. You can enable service such as application firewall,
IDP, UTM, SSL proxy, and so on by specifying them in a security policy permit action, when the traffic
matches the policy rule.
Options
advanced-anti- Specify advanced-anti-malware policy name.

malware-policy
application-firewall Specify the rule sets configured as part of application firewall to be applied to the
permitted traffic.
application-traffic- Specify the rule sets configured as part of AppQoS, application-aware quality of
control service, to be applied to the permitted traffic.
gprs-gtp-profile Specify GPRS tunneling protocol profile name.
gprs-sctp-profile Specify GPRS stream control protocol profile name.
idp Apply Intrusion detection and prevention (IDP) as application services.
redirect-wx Specify the WX redirection needed for the packets that arrive from the LAN.
reverse-redirect-wx Specify the WX redirection needed for the reverse flow of the packets that arrive
from the WAN.
security- Specify security-intelligence policy name.

intelligence-policy
329
security- Specify the security intelligence feed post action. The following feeds are
intelligence supported:
• add-destination-identity-to-feed
• add-destination-ip-to-feed
• add-source-identity-to-feed
• add-source-ip-to-feed
security-metadata- Enable metadata streaming of the traffic permitted by the security policy.
streaming-policy
uac-policy Enable Unified Access Control (UAC) for the security policy. This statement is
required when you are configuring the SRX Series device to act as a Junos OS
Enforcer in a UAC deployment.
captive- Specify the preconfigured security policy for captive portal on the
portal Junos OS Enforcer to enable the captive portal feature. The captive
captive-
portal portal policy is configured as part of the UAC policy. By configuring
the captive portal feature, you can redirect traffic destined for
protected resources to the IC Series device or to the URL you
configure on the Junos OS Enforcer.
utm-policy utm- Specify UTM policy name. The UTM policy configured for antivirus, antispam,
policy content-filtering, traffic-options, and Web-filtering protocols is attached to the
security policy to be applied to the permitted traffic.
web-proxy profile- Specify secure Web proxy profile name. The secure Web proxy profile is
name configured with dynamic application and external proxy server details. This profile
is attached to the security policy and applied on the permitted traffic.

330
Release Information
Application Firewall Overview
application-tracking (Security Zones)
IN THIS SECTION
Syntax | 330
Description | 331
Syntax
Hierarchy Level
[edit security zones security-zone zone-name]

331
Description
Enable application tracking support for the zone.
Release Information
Example: Configuring Application Tracking
application-traffic-control (Application Services)
IN THIS SECTION
Syntax | 332
Description | 332
Options | 332

332
Syntax
rule-set rule-set-name;
}
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then permit
application-services]
[edit logical-systems logical-system-name security policies from-zone zone-name to-zone zone-
name policy policy-name then permit application-services]
[edit tenants tenant-name security policies from-zone zone-name to-zone zone-name policy policy-
name then permit application-services]
Description
Enables AppQoS, application-aware quality of service, as specified in the rules of the specified rule set.
Options
• rule-set rule-set-name—Name of the rule set that contains application-aware traffic control
specification rules.

333
Release Information
Support at the following hierarchy levels introduced in Junos OS Release 19.3R1: [edit logical-systems
logical-system-name security policies from-zone zone-name to-zone zone-name policy policy-name then permit
application-services], and [edit tenants tenant-name security policies from-zone zone-name to-zone zone-name
policy policy-name then permit application-services].
Example: Configuring Application Quality of Service

attach
IN THIS SECTION
Syntax | 333
Description | 334
Options | 334
Syntax
attach {
zone zone-name;
}
334
Hierarchy Level
Description
Attach a security zone to an address book. You do not need to attach a security zone to the global
address book. The global address book is available by default.
Options
zone zone-name—Name of a security zone to be attached to the address book.
Release Information

335
audible (Security Alarms)
IN THIS SECTION
Syntax | 335
Description | 335
Options | 336
Syntax
audible {
continuous;
}
Hierarchy Level
[edit security alarms]
Description
Configure alarm to beep when a new security alarm is enabled.

336
Options
continuous—Specify alarm to keep beeping until all security alarms are cleared.
Release Information
authentication (Security Alarms)
IN THIS SECTION
Syntax | 337
Description | 337
Default | 337
Options | 337

337
Syntax
Hierarchy Level
[edit security alarms potential-violation]
Description
Raise a security alarm when the device or switch detects a specified number of authentication failures
(bad password attempts) before an alarm is raised.
This value must be equal to or less than the tries-before-disconnect setting at the [edit system login retry-
options] hierarchy level; otherwise, the login session ends before the user reaches the alarmable
threshold.
Default
Multiple authentication failures do not cause an alarm to be raised.
Options
failures—Number of authentication failures that causes an alarm to be raised.

338
Release Information
captive-portal (Services UAC Policy)
IN THIS SECTION
Syntax | 338
Description | 339
Syntax
captive-portal captive-portal-policy-name;
339
Hierarchy Level
application-services uac-policy]
Description
Create the captive portal policy in the UAC security policy. You use the captive portal policy to configure
the captive portal feature on the Junos OS Enforcer. By configuring the captive portal feature, you can
redirect traffic destined for protected resources to the IC Series device or to the URL you configure on
the Junos OS Enforcer.
Release Information

340
count (Security Policies)
IN THIS SECTION
Syntax | 340
Description | 340
Syntax
count;
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then]
Description
Enable a count, in bytes or kilobytes, of all network traffic the policy allows to pass through the device in
both directions: the originating traffic from the client to the server (from the from-zone to the to-zone),
and the return traffic from the server to the originating client.

341
Release Information
Statement introduced in Junos OS Release 8.5. Statement updated in Junos OS Release 12.1X47-D10.

default-policy
IN THIS SECTION
Syntax | 341
Description | 342
Options | 342
Syntax
default-policy (deny-all | permit-all);

342
Hierarchy Level
Description
Configure the default security policy that defines the actions the device takes on a packet that does not
match any user-defined policy.
Options
deny-all—Deny all traffic. Packets are dropped. This is the default.
permit-all—Permit all traffic that does not match a policy.
Release Information

343
deny (Security Policies)
IN THIS SECTION
Syntax | 343
Description | 343
Syntax
deny;
Hierarchy Level
Description
Block the service at the firewall. The device drops the packets.

344
Release Information
description (Applications)
IN THIS SECTION
Syntax | 344
Description | 345
Options | 345
Syntax
description text;
Hierarchy Level
[edit applications application application-name],

[edit applications application-set application-set-name]
345
Description
Specify descriptive text for an application or an application set.
NOTE: The descriptive text should not include characters “<”, “>”, “&”, or “\n”.
Options
text—Descriptive text about an application or an application set.
• Range: 1 through 900 characters
NOTE: The upper limit of the description text range is related to character encoding, and is
therefore dynamic. However, if you configure the descriptive text length beyond 900 characters,
the configuration might fail to take effect.
Release Information

346
description (Security Address Book)
IN THIS SECTION
Syntax | 346
Description | 346
Options | 347
Syntax
description text;
Hierarchy Level
Description
Specify descriptive text for an address book.
NOTE: The descriptive text should not include characters “<”, “>”, “&”, or “\n”.
347
Options
text—Descriptive text about an address book.
Release Information

description (Security Zone)
IN THIS SECTION
Syntax | 348
348
Description | 348
Options | 348
Syntax
description text;
Hierarchy Level
[edit security zones functional-zone management]

Description
Specify descriptive text for a security zone.
NOTE: The descriptive text should not include characters as “<”, “>”, “&”, or “\n”.
Options
text—Descriptive text about a security zone.

349
Release Information
destination-address (Security Policies)
IN THIS SECTION
Syntax | 350
Description | 350
Options | 350

350
Syntax
destination-address {
[address];
any;
any-ipv4;
any-ipv6;
}
Hierarchy Level
Description
Define the matching criteria. You can specify one or more IP addresses, address sets, or wildcard
addresses. You can specify wildcards any, any-ipv4, or any-ipv6.
Options
address—IP address (any, any-ipv4, any-ipv6), IP address set, or address book entry, or wildcard address
(represented as A.B.C.D/wildcard-mask). You can configure multiple addresses or address prefixes
separated by spaces and enclosed in square brackets.

351
Release Information
Statement introduced in Junos OS Release 8.5. Support.
destination-address (Security Policies Flag)
IN THIS SECTION
Syntax | 351
Description | 352
Options | 352
Syntax
drop-translated;
drop-untranslated;
}
352
Hierarchy Level
Description
Specify whether the traffic permitted by the security policy is limited to packets where the destination
IP address has been translated by means of a destination NAT rule or to packets where the destination
IP address has not been translated.
On Juniper Networks security devices, destination NAT rules are processed before security policy
lookup. Therefore, it is possible for a security policy to permit traffic from a source S to a destination D
(where no destination NAT is performed) and also to permit traffic from the source S to the destination d
(where d has been translated to D).
Options
• drop-translated—Drop packets with translated destination IP addresses. Traffic permitted by the

security policy is limited to packets where the destination IP address has not been translated.
• drop-untranslated—Drop packets without translated destination IP addresses. Traffic permitted by the

security policy is limited to packets where the destination IP address has been translated by means of
a destination NAT rule.
Release Information

353
destination-address-excluded
IN THIS SECTION
Syntax | 353
Description | 353
Syntax
Hierarchy Level
Description
Exclude the destination address(es) from the policy.

354
Release Information
Statement introduced in Junos OS Release 12.1X45-D10.
destination-ip (Security Alarms)
IN THIS SECTION
Syntax | 354
Description | 355
Options | 355
Syntax
destination-ip {
duration interval;
size count;
355
threshold value;
}
Hierarchy Level
Description
Configure alarms for a number of policy violations to a destination network identifier within a specified
time period.
Options
• size count—Indicate the number of destination IP addresses for which policy violation checks can be
done concurrently.
• Default: 1024.
• threshold value—Indicate the maximum number of destination IP address matches required to raise an
alarm.
• Default: 1000.
356
Release Information
destination-port (Applications)
IN THIS SECTION
Syntax | 356
Description | 357
Options | 357
Syntax
357
Hierarchy Level
[edit applications application application-name],

[edit applications application application-name term term-name]
Description
Specify a TCP or UDP destination port number.
Options
port-identifier —Range of ports. You can use a numeric value or one of the text synonyms listed in Table
31 on page 357.
Table 31: Port Supported by Services Interfaces
Port Name Corresponding Port Number
afs 1483
bgp 179
biff 512
bootpc 68
bootps 67
cmd 514
cvspserver 2401
358
Table 31: Port Supported by Services Interfaces (Continued)
dhcp 67
domain 53
eklogin 2105
ekshell 2106
excc 512
finger 79
ftp 21
ftp-data 20
http 80
https 443
ident 113
imap 143
kerberos-sec 88
klogin 543
kpasswd 761
359
krb-prop 754
krbupdate 760
kshell 544
ldap 389
ldp 646
login 513
mobileip-agent 434
mobilip-mn 435
msdp 639
netbios-dgm 138
netbios-ns 137
netbios-ssn 139
nfsd 2049
nntp 119
ntalk 518
360
ntp 123
pop3 110
pptp 1723
printer 515
radacct 1813
radius 1812
rip 520
rkinit 2108
smtp 25
snmp 161
snmp-trap 162
snpp 444
socks 1080
ssh 22
sunrpc 111
361
syslog 514
tacacs 49
tacacs-ds 65
talk 517
telnet 23
tftp 69
timed 525
who 513
xdmcp 177
Release Information

362
dns-cache
IN THIS SECTION
Syntax | 362
Description | 363
Options | 363
Syntax
dns-cache {
error-response-delete-ip {
retry-interval seconds;
}
}
Hierarchy Level
[edit logical-systems logical-system-name security policies],

[edit logical-systems logical-system-name tenants tenant-system-name security policies],
[edit security policies],
[edit tenants tenant-system-name security policies]
363
Description
Define security policy DNS cache behaviors. The following behaviors can occur:
• Flushing of the DNS cache entry on error response.
• Keeping the DNS cache entry unchanged on all DNS servers time out.
• Updating the DNS cache entry when there is a positive response.
Options
error-response- Clear DNS cache entry IP on error DNS response

delete-ip
• Values:
retry-interval Interval between deleting IP and resending DNS requests
• Default: 300 seconds.
security
Release Information
Statement introduced in Junos OS Release 20.1R1.
show security dns-cache

clear security dns-cache
364
dns-proxy
IN THIS SECTION
Syntax | 364
Description | 365
Options | 365
Syntax
dns-proxy {
cache hostname inet ip-address;

default-domain domain-name {
forwarders ip-address;
}
interface interface-name;
propogate-setting (enable | disable);
view view-name {
domain domain-name {
forward-only;
forwarders ip-address;
}
match-clients subnet-address;
}
}
365
Hierarchy Level
[edit system services dns dns-proxy]
Description
Configure the device as a DNS proxy server by enabling DNS proxy on a logical interface. This option is
supported on SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices.
Options
Release Information
DNS Proxy Overview

Configuring the Device as a DNS Proxy
366
dynamic-address
IN THIS SECTION
Syntax | 366
Description | 367
Syntax
dynamic-address {
address-name name {
description description;
profile {
category name {
feed feed;
property name {
string name;
}
}
feed-name name;
}
session-scan;
}
feed-server name {
(hostname hostname | url url);
feed-name name {
hold-interval seconds;
367
path path;
update-interval seconds;
}
tls-profile tls-profile;
validate-certificate-attributes {
subject-or-subject-alternative-names;
}
}
session-scan {
}
traceoptions {
file< filename><files files><match match><size size><(world-readable | no-world-readable)>;
flag name;
level(all | error | info | notice | verbose | warning);

no-remote-trace;
}
}
Hierarchy Level
[edit security]
Description
Configure security dynamic address

368
Release Information
Statement introduced in Junos OS Release 12.1X46-D15 on SRX Series devices and on cSRX in Junos
OS Release 22.2R1.
dynamic-application (Security)
IN THIS SECTION
Syntax | 368
Description | 369
Options | 369
Syntax
dynamic-application {
profile profile name {
redirect-message {
type {
custom-text {
content content;
}
369
redirect-url {
content content;
}
}
}
}
traceoptions {
file {
filename;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
no-remote-trace;
}
}
Hierarchy Level
[edit security]
Description
Configure options for dynamic applications to define a redirect profile and traceoptions.
Options

370
Release Information

dynamic-application (Security Policies)
IN THIS SECTION
Syntax | 370
Description | 371
Options | 371
Syntax
dynamic-application;
371
Hierarchy Level
[edit security policies from-zone zone-name policy policy-name match]

Description
Specify the dynamic applications or dynamic application groups used as match criteria within a security
policy.
By adding dynamic applications to the match criteria, the data traffic is classified based on the Layer 7
application inspection results. Application Identification (AppID) identifies dynamic or real-time Layer 4
through Layer 7 applications. After a particular application is identified and the matching policy is found,
then the actions are applied according to the policy.
Options
dynamic- Specify dynamic applications or dynamic application groups.

application-
name | Examples for dynamic applications or dynamic application groups are as follows:
dynamic-
application- • junos:FTP (dynamic application)
group-name
• junos:web:shopping (dynamic application group)
any Configuring the dynamic application as any installs the policy with the application as a
wildcard (default). If an application cannot be specified, configure any as the default
application. Data traffic that match the parameters in a unified policy matches the
policy regardless of the application type.
none Configuring the dynamic application as none ignores classification results from AppID
and does not use the dynamic application in security policy lookups. Within the list of
potential match policies, if there is any policy configured with dynamic application as
none, this policy is matched as the final policy and is terminal. If any Layer 7 services are
configured in this policy, deep packet inspection for the traffic is performed.
372
When upgrading the Junos OS release from previous releases (where dynamic
applications were not supported), all existing traditional policies are considered as
policies with the dynamic application configured as none.
junos:all-new- Configure the application group of all newly added application signatures in the latest
apps signature package. When you download the application signature package on your
security device, the entire predefined application group is downloaded.</para>
If dynamic application is not configured within a security policy, the policy is considered to be a
traditional security policy. This policy is similar to a policy with the dynamic application configured as
none.
Release Information

dynamic-dns
IN THIS SECTION
Syntax | 373
373
Description | 373
Options | 374
Syntax
dynamic-dns {
client hostname {
agent agent-name;
interface interface-name;
password server-password;
server server-name;
username user-name;
}
}
Hierarchy Level
[edit system services]
Description
Configure the device as a dynamic DNS server that maintains the list of the changed addresses and their
associated domain names registered with it. The device updates these DDNS servers with this
information periodically or whenever there is a change in IP addresses.
374
Options
• client —Specifies the hostname of the registered client.
• agent—Specifies the name of the dynamic DNS agent.
• interface —Specifies the interface whose IP address is mapped to the registered domain name.
• password—Specifies the password.
• server—Specifies the name of the dynamic DNS server that allows dynamic DNS clients to update the
IP address changes associated with the registered hostname.
• username—Specifies the dynamic DNS username.
Release Information
DNS Overview
exclude (Schedulers)
IN THIS SECTION
Syntax | 375
375
Description | 375
Syntax
exclude;
Hierarchy Level
[edit schedulers scheduler scheduler-name daily],

[edit schedulers scheduler scheduler-name friday],
[edit schedulers scheduler scheduler-name monday],
[edit schedulers scheduler scheduler-name saturday],
[edit schedulers scheduler scheduler-name sunday],
[edit schedulers scheduler scheduler-name tuesday],
[edit schedulers scheduler scheduler-name thursday],
[edit schedulers scheduler scheduler-name wednesday]
Description
Exclude a specified day from the schedule.
Use the exclude statement to exclude a day from a daily schedule created with the daily statement. You
cannot use the exclude statement for a particular day unless it is in conjunction with the daily statement
in a schedule.
376
Release Information
feed-server
IN THIS SECTION
Syntax | 376
Description | 377
Options | 377
Syntax
feed-server name {
(hostname hostname | url url);
377
feed-name name {
path path;
}
tls-profile tls-profile;
validate-certificate-attributes {
subject-or-subject-alternative-names;
}
}
Hierarchy Level
[edit security dynamic-address]
Description
Security dynamic address feed-server
Options
name Security dynamic address feed-server name
hostname Hostname or IP address of feed-server
url URL,example:example.url.com;10.1.1.1/<folder-or-file-path>;Browser can verify its

validity
378
description Text description of feed-server
hold-interval Time to keep IP entry when update failed (seconds)
• Default: 86400
• Range: 0 through 4294967295
tls-profile TLS profile
update-interval Interval to retrieve update (seconds)
• Default: 300
validate- Validate some certificate attributes

certificate-
attributes • subject-or-subject-alternative-names—One of them must match feed server
host name
Release Information
OS Release 22.2R1.
379
firewall-authentication (Security Policies)
IN THIS SECTION
Syntax | 379
Description | 380
Options | 380
Syntax
firewall-authentication {
pass-through {
access-profile profile-name;
client-match user-or-group-name;
ssl-termination-profile profile-name;
web-redirect;
web-redirect-to-https;
auth-only-browser
auth-user-agent
}
push-to-identity-management
user-firewall {
domain domain-name
web-redirect;
auth-only-browser
}
web-authentication {
380
}
}
Hierarchy Level
Description
Configure firewall authentication methods.
Options
Release Information
Support added for the user-firewall option in Junos OS Release 12.1X45-D10.
Support for the ssl-termination-profile and web-redirect-to-https options added on SRX5600 and SRX5800
Services Gateways starting from Junos OS Release 12.1X44-D10, on SRX5400 devices starting from
12.1X46-D10, and on vSRX, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, and SRX1500
Services Gateways starting from Junos OS Release 15.1X49-D40.
381
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, support for the web-redirect
and web-redirect-to-https options under user-firewall added on SRX300, SRX320, SRX340, SRX345,
SRX380, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and
vSRX Services Gateways.
Starting with Junos OS Release 15.1X49-D90 and Junos OS Release 17.3R1, support for the auth-only-
browser option was added under pass-through and user-firewall and the auth-user-agent option was added
under pass-through auth-only-browser on SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M,
SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX Services
Gateways.
Starting with Junos OS Release 15.1X49-D90 and Junos OS Release 17.3R1, support for the auth-only-
browser option was added under pass-through and user-firewall and the auth-user-agent option was added
under pass-through auth-only-browser on SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M,
SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX Services
Gateways. Starting with Junos OS Release 15.1X49-D100 and Junos OS Release 17.3R1, support was
added for push-to-identity-management.
forward-only (DNS)
IN THIS SECTION
Syntax | 382
Description | 382

382
Syntax
forward-only;
Hierarchy Level
[edit system services dns dns-proxy view view-name domain domain-name]
Description
Specify that the server to forward only DNS queries. This configuration prevents the device from
acquiring public IP addresses, in case the IP address specified in forwarders option is not reachable, by
terminating the DNS query.
Release Information
DNS Overview
383
from-zone (Security Policies)
IN THIS SECTION
Syntax | 383
Description | 386
Options | 386
Syntax
from-zone zone-name to-zone zone-name {

policy policy-name {
match {
application {
[junos-defaults | application];
any;
junos-smtps;
junos-imaps;
junos-pop3s;
}
}
dynamic-application {
[dynamic-application-name |dynamic-application-group-name];
any;
none;
}
[address];
any;
any-ipv4;
any-ipv6;
384
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unauthenticated-user;
unknown-user;
}
source-end-user-profile {
profile-name;
}
}
scheduler-name scheduler-name;
then {
count {
alarm {
per-minute-threshold number;
per-second-threshold number;
}
}
deny;
log {
session-close;
session-init;
}
permit {
}
}
gprs-gtp-profile profile-name;
gprs-sctp-profile profile-name;
idp;
redirect-wx | reverse-redirect-wx;
385
ssl-proxy {
}
uac-policy {
}
utm-policy policy-name;
}
drop-translated;
drop-untranslated;
}
pass-through {
web-redirect;
}
user-firewall {
domain domain-name
}
}
}
services-offload;
tcp-options {
initial-tcp-mss mss-value;
reverse-tcp-mss mss-value;
sequence-check-required;
syn-check-required;
}
tunnel {
ipsec-group-vpn group-vpn;
ipsec-vpn vpn-name;
pair-policy pair-policy;
}
}
386
deny | reject;
deny | reject [profile name];
}
}
}
Hierarchy Level
Description
Specify a source zone and destination zone to be associated with the security policy.
Options
• from-zone zone-name—Name of the source zone.
• to-zone zone-name—Name of the destination zone.

387
Release Information
Statement introduced in Junos OS Release 8.5. Support for the services-offload option added in Junos OS
Release 11.4. Support for the source-identity option added in Junos OS Release 12.1. Support for the
description option added in Junos OS Release 12.1. Support for the ssl-termination-profile and web-
redirect-to-https options added in Junos OS Release 12.1X44-D10. Support for the user-firewall option
added in Junos OS Release 12.1X45-D10. Support for the initial-tcp-mss and reverse-tcp-mss options
added in Junos OS Release 12.3X48-D20. Support for the dynamic-application and deny options added in
Junos OS Release 18.2R1.

from-zone (Security Policies Global)
IN THIS SECTION
Syntax | 387
Description | 388
Syntax
from-zone {
[zone-name];
388
any;
}
Hierarchy Level
Description
Identify a single source zone or multiple source zones to be used as a match criteria for a policy. You
must configure specific zones or default to any zone, but you cannot have both in a global policy.
Release Information

389
functional-zone
IN THIS SECTION
Syntax | 389
Description | 390
Options | 390
Syntax
functional-zone {
management {
description text;
protocols protocol-name {
except;
}
system-services service-name {
except;
}
}
interfaces interface-name {
except;
}
except;
}
}
}
screen screen-name;
390
}
}
Hierarchy Level
Description
Configure a functional zone.
Options
Release Information
Statement introduced in Junos OS Release 8.5. The description option added in Junos OS Release 12.1.

391
global (Security Policies)
IN THIS SECTION
Syntax | 391
Description | 393
Options | 394
Syntax
global {
match {
application {
[application];
any;
}
[address];
any;
any-ipv4;
any-ipv6;
}
from-zone {
[zone-name];
any;
}
source-address {
[address];
any;
any-ipv4;
392
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unknown-user;
}
to-zone {
[zone-name];
any;
}
}
then {
count {
alarm {
}
}
deny;
log {
session-close;
session-init;
}
permit {
}
}
idp;
ssl-proxy {
}
uac-policy {
393
}
}
drop-translated;
drop-untranslated;
}
pass-through {
web-redirect;
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
}
reject;
}
}
}
Hierarchy Level
Description
Configure a global policy.

394
Options
Release Information
Statement introduced in Junos OS Release 8.5. Statement updated with from-zone and to-zone policy
match options in Junos OS Release 12.1X47-D10.
host-inbound-traffic
IN THIS SECTION
Syntax | 395
Description | 395
Options | 395

395
Syntax
except;
}
except;
}
}
Hierarchy Level
[edit security zones functional-zone management],

[edit security zones functional-zone management interfaces interface-name],
[edit security zones security-zone zone-name],
[edit security zones security-zone zone-name interfaces interface-name]
Description
Control the type of traffic that can reach the device from interfaces bound to the zone.
Options

396
Release Information

icmp-code (Applications)
IN THIS SECTION
Syntax | 396
Description | 397
Options | 397
Syntax
icmp-code value;
397
Hierarchy Level
[edit applications application application-name ]

Description
Specify the Internet Control Message Protocol (ICMP) code value.
Options
value — Specify the Internet Control Message Protocol (ICMP) code value such as host-unreachable or host-
unreachable-for-tos.
Release Information

398
icmp-type (Applications)
IN THIS SECTION
Syntax | 398
Description | 398
Options | 399
Syntax
icmp-type value;
Hierarchy Level

Description
Specify the ICMP packet type value.

399
Options
value—ICMP type value, such as echo or echo-reply.
Release Information
inactivity-timeout (Applications)
IN THIS SECTION
Syntax | 400
Description | 400
Options | 400

400
Syntax
inactivity-timeout (seconds | never) ;
Hierarchy Level

Description
Inactivity timeout period, in seconds.
Options
seconds—Specify the amount of time the application is inactive before it times out in seconds.
Range: 4 through 86400 seconds.
Release Information

401
interfaces (Security Zones)
IN THIS SECTION
Syntax | 401
Description | 402
Options | 402
Syntax
except;
}
except;
}
}
}
402
Hierarchy Level

Description
Specify the set of interfaces that are part of the zone.
Options
interface-name —Name of the interface.
Release Information

403
initial-tcp-mss
IN THIS SECTION
Syntax | 403
Description | 403
Syntax
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name

policy policy-name then permit tcp-options]
Description
Configure the TCP maximum segment size (MSS) for packets that arrive at the ingress interface (initial
direction), match a specific policy, and for which a session is created. The value you configure overrides
the TCP MSS value in the incoming packet when the value in the packet is higher than the one you
specify.
The initial-tcp-mss value per policy takes precedence over a global tcp-mss value (all-tcp, ipsec-vpn, gre-in,
gre-out), if one is configured. However, when the syn-flood-protection-mode syn-proxy statement at the [edit
404
security flow] hierarchy level is used to enable SYN proxy defenses against SYN attacks, the TCP MSS
value is not overriden.
Because each policy has two directions, you can configure a value for both directions or for just one
direction. To configure a TCP MSS value for the reverse session, use the reverse-tcp-mss option.
Release Information
tcp-mss (Security Flow)
syn-flood-protection-mode
ipsec-group-vpn (Security Policies)
IN THIS SECTION
Syntax | 405
Description | 405
Options | 405

405
Syntax
Hierarchy Level
tunnel]
Description
Specify group VPN tunnel for the traffic configured by the scope policy on a group member.
Options
group-vpn —Name of the group VPN tunnel configured on the group member.

406
Release Information

Group VPNv2 Overview
ipsec-vpn (Security Policies)
IN THIS SECTION
Syntax | 406
Description | 407
Options | 407
Syntax
ipsec-vpn vpn-name;
407
Hierarchy Level
tunnel]
Description
Define IPsec name for VPN.
Options
vpn-name —Name of the IPsec.
Release Information

408
log (Security Policies)
IN THIS SECTION
Syntax | 408
Description | 408
Options | 409
Syntax
log (session-close | session-init);
Hierarchy Level
Description
Log traffic information for a specific policy. Traffic information is logged when a session begins (session-
init) or closes (session-close).
NOTE: You must configure security policy for the session using the set security policies from-zone
zone-name to-zone zone-name policy policy-name then log session-close command to list all the
409
applications and nested applications in Application Tracking on J-Web using the on-box reporting
feature.
Options
session-close Start logging traffic when the session ends.
session-init Start logging traffic when the session begins.
Release Information

Understanding On-Box Logging and Reporting
Example: Configuring Application Tracking
410
management (Security Zones)
IN THIS SECTION
Syntax | 410
Description | 411
Options | 411
Syntax
management {
description text;
except;
}
except;
}
}
except;
}
except;
}
}
}
411
screen screen-name;
}
Hierarchy Level
[edit security zones functional-zone]
Description
Specify the host for out-of-band management interfaces. You can set firewall options in this zone to
protect the management interface from different types of attacks. Because this zone cannot be specified
in policies, traffic entering from this zone can only be traffic originating from the device itself and cannot
originate from any other zone.
Options
Release Information
Statement introduced in Junos OS Release 8.5.The description option added in Junos OS Release 12.1.
412

match (Security Policies)
IN THIS SECTION
Syntax | 412
Description | 413
Options | 413
Syntax
match {
application {
[application];
any;
}
[address];
any;
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
413
}
source-identity {
[role-name];
any;
authenticated-user;
unknown-user;
}
}
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name]
Description
Configure security policy match criteria.
Options

414
Release Information
Statement introduced in Junos OS Release 8.5. Statement updated with the source-identity option in
Junos OS Release 12.1.
match (Security Policies Global)
IN THIS SECTION
Syntax | 414
Description | 415
Options | 416
Syntax
match {
application {
[application];
any;
}
[address];
any;
any-ipv4;
any-ipv6;
415
}
destination-identity-feed feed-name
from-zone {
[zone-name];
any;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unknown-user;
}
source-identity-feed feed-name;
to-zone {
[zone-name];
any;
}
}
Hierarchy Level
[edit security policies global policy policy-name]
Description
Configure security global policy match criteria.

416
NOTE: We recommend that, for security reasons and to avoid spoofing traffic, when you create a
multizone policy you use identical matching criteria (source address, destination address,
application) and an identical action. For more information see "Global Policy Overview" on page
184.
Options
Release Information
Statement modified in Junos OS Release 8.5. Statement updated with source-identity option in Junos OS
Release 12.1. Statement updated with to-zone and from-zone options in Junos OS Release 12.1X47-D10.
Statement updated with source-identity-feed and destination-identity-feed options in Junos OS Release

21.1R1.

417
unified-policy max-lookups
IN THIS SECTION
Syntax | 417
Description | 417
Default | 418
Syntax
unified-policy max-lookups max-lookups-number;
Hierarchy Level
[edit logical-systems name security policies],

[edit logical-systems name tenants name security policies],
[edit tenants tenant-name security policies]
Description
Configure maximum number of policy lookups, when micro-applications reach the transaction final
state, during the dynamic application classification process.
Application classification with micro-applications does not reach the final match state because the
micro-application keeps changing for the session. When the micro-application changes from one
418
transaction to another, a policy lookup is attempted unlimited number of times. The final match state for
the application is required for the policy lookup and for processing the policy. You can limit the number
of transactions for the micro application by configuring the unified-policy max-lookups statement.
Setting the value of unified-policy max-lookups as 0 indicates unlimited number of policy lookups.
Range: 0 through 25
Default
The default value for unified-policy max-lookups is 2.
flow-tap
Release Information
no-policy-cold-synchronization
IN THIS SECTION
Syntax | 419

419
Description | 419
Syntax
no-policy-cold-synchronization
Hierarchy Level
[edit security idp sensor-configuration high-availability]
Description
Disable policy cold synchronization functionality. This prevents the SRX Series devices from waiting for
the IPS policy to be loaded on all service PICs, and there by forfeits IPS service protection during the
ISSU (In-service software upgrade) operation/window.
Release Information

420
pair-policy
IN THIS SECTION
Syntax | 420
Description | 420
Syntax
pair-policy pair-policy ;
Hierarchy Level
tunnel]
Description
Link the policy that you are configuring with another policy that references the same VPN tunnel so that
both policies share one proxy ID and one security association (SA). Policy pairing is useful when you
want to allow bidirectional traffic over a policy-based VPN that is using source or destination address
421
translation with a dynamic IP address pool or destination address translation with a mapped IP (MIP) or
dynamic IP (DIP) address pool.
Without policy pairing, the device derives a different proxy ID from the outbound and inbound policies.
Two proxy IDs causes a problem for the remote peer with a single proxy ID for the VPN tunnel.
Pairing two policies solves the proxy ID problem for the remote peer and conserves SA resources. The
single proxy ID is derived from the policy you configured last.
Release Information
pass-through
IN THIS SECTION
Syntax | 422
Description | 422
Options | 422

422
Syntax
pass-through {
web-redirect;
}
Hierarchy Level
firewall-authentication]
Description
Configure pass-through firewall user authentication. The user needs to use an FTP, Telnet, or HTTP
client to access the IP address of the protected resource in another zone. Subsequent traffic from the
user or host is allowed or denied based on the result of this authentication. Once authenticated, the
firewall proxies the connection.
Options
• access-profile profile-name —(Optional) Specify the name of the access profile.

423
• client-match user-or-group —(Optional) Specify the name of the users or user groups in a profile who
are allowed access by this policy. If you do not specify any users or user groups, any user who is
successfully authenticated is allowed access.
• ssl-termination-profile profile-name —(Optional) Specify the SSL termination profile used for SSL
offloading.
• web-redirect—(Optional) Enable redirecting an HTTP request to the device and redirecting the client
system to a webpage for authentication. Including this statement allows users an easier
authentication process because they need to know only the name or IP address of the resource they
are trying to access.
• web-redirect-to-https—(Optional) Redirect unauthenticated HTTP requests to the internal HTTPS Web

server of the device.
NOTE: If web-redirect-to-https is set, then you must specify the SSL termination profile used for
SSL offloading.
Release Information
Statement introduced in Junos OS Release 8.5. Support for ssl-termination-profile and web-redirect-to-https
options added in Junos OS Release 12.1X44-D10.

424
permit (Security Policies)
IN THIS SECTION
Syntax | 424
Description | 426
Options | 426
Syntax
permit {
advanced-connection-tracking;
application-services (Security Policies) {
}
}
idp;
ssl-proxy {
}
uac-policy {
}
}
425
drop-translated;
drop-untranslated;
}
pass-through {
web-redirect;
}
user-firewall {
domain domain-name
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
tunnel {
ipsec-vpn vpn-name;
}
}
Hierarchy Level
426
Description
Specify the policy action to perform when packets match the defined criteria.
Options
Release Information
Statement introduced in Junos OS Release 8.5. Support for the tcp-options added in Junos OS Release
10.4. Support for the services-offload option added in Junos OS Release 11.4. Support for the ssl-
termination-profile and web-redirect-to-https options added in Junos OS Release 12.1X44-D10. Support for
the user-firewall option added in Junos OS Release 12.1X45-D10. Support for the advanced-connection-
tracking option is added in Junos OS Release 20.2R1.
You can configure the advanced-connection-tracking option under [edit security policies from-zone zone-name
to-zone zone-name policy policy-name then permit] to mandate that traffic matching given policy do a lookup
in the to-zone’s connection track mapping table using the new session’s key information. If there is no
match, a new connection is not created.
427
policies
IN THIS SECTION
Syntax | 427
Description | 435
Options | 435
Syntax
policies {
default-policy (deny-all | permit-all);
from-zone from-zone-name {
to-zone;
policy name {
match (Security Policies Global) {
source-address (Security Policies);
destination-address (Security Policies);
application (Security Policies);
source-identity;
source-end-user-profile <source-end-user-profile-name>;
dynamic-application (Security Policies);
url-category;
from-zone (Security Policies Global);
to-zone (Security Policies Global);
source-l3vpn-vrf-group [ source-l3vpn-vrf-group ... ];
destination-l3vpn-vrf-group [ destination-l3vpn-vrf-group ... ];
}
428
then {
deny;
permit {
(redirect-wx | reverse-redirect-wx);
rule-set rule-set;
}
icap-redirect icap-redirect;
idp;
idp-policy idp-policy;
ssl-proxy {
}
uac-policy {
}
web-proxy {
}
}
destination-address (Security IDP Policy) {
(drop-translated | drop-untranslated);
}
pass-through {
access-profile access-profile;
auth-only-browser;
auth-user-agent name;
client-match [ client-match ... ];
ssl-termination-profile ssl-termination-profile;
web-redirect;
}
user-firewall {
auth-only-browser;
429
domain domain;
web-redirect;
}
}
push-to-identity-management;
}
services-offload;
tcp-options {
initial-tcp-mss initial-tcp-mss;
reverse-tcp-mss reverse-tcp-mss;
syn-check-required;
window-scale;
}
tunnel {
ipsec-vpn ipsec-vpn;
}
}
reject {
profile profile;
ssl-proxy {
}
}
count {
}
log {
session-close;
session-init;
}
}
}
}
global {
policy name {
430

source-identity;
url-category;
}
then {
deny;
permit {
rule-set rule-set;
}
idp;
ssl-proxy {
}
uac-policy {
}
web-proxy {
}
}
}
431
pass-through {
auth-only-browser;
web-redirect;
}
user-firewall {
auth-only-browser;
domain domain;
web-redirect;
}
}
}
services-offload;
tcp-options {
syn-check-required;
window-scale;
}
tunnel {
}
}
reject {
profile profile;
ssl-proxy {
}
}
432
count {
}
log {
session-close;
session-init;
}
}
}
}
policy-rematch <extensive>;
policy-stats {
system-wide (disable | enable);
}
pre-id-default-policy {
then {
log {
session-close;
session-init;
}
session-timeout {
icmp seconds;
icmp6 seconds;
ospf seconds;
others seconds;
tcp seconds;
udp seconds;
}
}
}
stateful-firewall-rule name {
match-direction (input | input-output | output);
policy name {
source-identity;
url-category;
433

}
then {
deny;
permit {
rule-set rule-set;
}
idp;
ssl-proxy {
}
uac-policy {
}
web-proxy {
}
}
}
pass-through {
auth-only-browser;
web-redirect;
434
}
user-firewall {
auth-only-browser;
domain domain;
web-redirect;
}
}
}
services-offload;
tcp-options {
syn-check-required;
window-scale;
}
tunnel {
}
}
reject {
profile profile;
ssl-proxy {
}
}
count {
}
log {
session-close;
session-init;
}
}
}
435
}
stateful-firewall-rule-set name {
stateful-firewall-rule name;
}
traceoptions (Security Policies) {
file <filename> <files files> <match match> <size size> <(world-readable | no-world-
readable)>;
flag name;
no-remote-trace;
}
unified-policy {
max-lookups max-lookups;
}
}
Hierarchy Level
[edit security]
Description
Configure a network security policies with IPv6 addresses only if flow support for IPv6 traffic is enabled
on the device.
Options
default-policy Configure a default action when no user-defined policy match.
• Values:
• deny-all—Deny all traffic if no policy match
• permit-all—Permit all traffic if no policy match
policy-rematch Re-evaluate the policy when changed.

436
• Values:
• extensive—Perform policy extensive rematch
Release Information
Support for the services-offload option added in Junos OS Release 11.4.
Support for the source-identitiy option added in Junos OS Release 12.1.
Support for the description option added in Junos OS Release 12.1.
Support for the ssl-termination-profile and web-redirect-to-https options are added starting from Junos OS
Release 12.1X44-D10 and Junos OS Release 15.1X49-D40.
Support for the user-firewall option added in Junos OS Release 12.1X45-D10.
Support for the domain option, and for the from-zone and to-zone global policy match options, added in
Junos OS Release 12.1X47-D10.
Support for the initial-tcp-mss and reverse-tcp-mss options added in Junos OS Release 12.3X48-D20.
Support for the extensive option for policy-rematch added in Junos OS Release 15.1X49-D20.
Starting in Junos OS Release 18.2R1, an IDP policy is available within unified security policy. The IDP
policy access is simplified and made available under the unified policy as one of the policy. When an IDP
policy is available within a unified security policy, configuring source or destination address, source and
destination-except, from and to zone, or application is not required, because the match happens in the
security policy itself.
Starting in Junos OS Release 18.3R1, when an SRX Series device is configured with a unified policies,
you can configure multiple IDP policies and set one of those policies as the default IDP policy. If multiple
IDP policies are configured for a session and when policy conflict occurs, the device applies the default
IDP policy for that session and thus resolves any policy conflicts.
437
NOTE: If you have configured two or more IDP policies in a unified security policy, then you
must configure the default IDP policy.
policy (Security Alarms)
IN THIS SECTION
Syntax | 437
Description | 438
Options | 438
Syntax
policy {
application {
duration interval;
size count;
threshold value;
}
destination-ip {
duration interval;
size count;
threshold value;
438
}
policy match {
duration interval;
size count;
threshold value;
}
source-ip {
duration interval;
size count;
threshold value;
}
}
Hierarchy Level
[edit security alarms potential-violation]
Description
Configure alarms for policy violation, based on source IP, destination IP, application, and policy rule.
Options

439
Release Information
policy (Security Policies)
IN THIS SECTION
Syntax | 439
Description | 442
Options | 442
Syntax
match {
application {
[application];
any;
junos-twamp;
}
[address];
any;
440
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unknown-user;
}
}
then {
count {
alarm {
}
}
deny;
log {
session-close;
session-init;
}
permit {
}
}
idp;
ssl-proxy {
441
}
uac-policy {
}
}
drop-translated;
drop-untranslated;
}
pass-through {
web-redirect;
}
user-firewall {
domain domain-name
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
tunnel {
ipsec-vpn vpn-name;
}
}
reject;
}
}
442
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name]
Description
Define a security policy.
Options
policy-name Name of the security policy.
description Descriptive text about the security policy.
Range: 1 through 900 characters
The descriptive text should not include characters “<”, “>”, “&”, or “\n”.
The upper limit of the description text range is related to character encoding, and is
therefore dynamic. However, if you configure the descriptive text length beyond 900
characters, the configuration might fail to take effect.
Release Information
Statement introduced in Junos OS Release 8.5. The services-offload option added in Junos OS Release
11.4. Statement updated with the source-identity option and the description option added in Junos OS
443
Release 12.1. Support for the user-firewall option added in Junos OS Release 12.1X45-D10. Support for
the initial-tcp-mss and reverse-tcp-mss options added in Junos OS Release 12.3X48-D20.
The junos-twamp application is introduced in Junos OS Release 18.2R1.
Configuring SSL Forward Proxy

policy-match
IN THIS SECTION
Syntax | 443
Description | 444
Options | 444
Syntax
policy match {
duration interval;
size count;
threshold value;
}
444
Hierarchy Level
Description
Configure alarms for a policy rule or a group of rule violations within a specified time period.
Options
• size count—Indicate the number of policies for which policy violation checks can be done
concurrently.
• Default: 1024.
• threshold value—Indicate the number of policies for which policy violation checks can be done
concurrently.
• Default: 1000.

445
Release Information
policy-rematch
IN THIS SECTION
Syntax | 445
Description | 446
Options | 446
Syntax
policy-rematch <extensive>;
Hierarchy Level

446
Description
Enable the device to reevaluate an active session when its associated security policy is modified. The
session remains open if it still matches the policy that allowed the session initially.
The session is closed if its associated policy is renamed, deactivated, or deleted. However, you can use
the extensive option to reevaluate an active session when its associated security policy is renamed,
deactivated, or deleted.
The policy rematch feature is disabled by default.
Options
extensive When a policy is modified or deleted, extensive option checks if any suitable policy permit
to keep these sessions alive. This check is done through a fully new policy lookup for the
session to see if any policy can still permit it.
NOTE: The extensive option does not apply to ALG data sessions or to policies that
specify a source-identity, application-services, destination-address (drop-
untranslated or drop-translated), firewall-authentication, or a tunnel.
Release Information
Statement introduced in Junos OS Release 8.5. Support for the extensive option added in Junos OS
Release 15.1X49-D20.
447

policy-stats
IN THIS SECTION
Syntax | 447
Description | 448
Options | 448
Syntax
policy-stats {
system-wide (disable | enable) ;
}
Hierarchy Level

448
Description
Configure systemwide policies statistics. The systemwide policies statistics are disabled by default.
Options
disable Disable systemwide policy statistics.
enable Enable systemwide policy statistics.
Release Information
potential-violation
IN THIS SECTION
Syntax | 449
449
Description | 450
Options | 450
Syntax
potential-violation {
cryptographic-self-test;
decryption-failures {
threshold value;
}
encryption-failures {
threshold value;
}
idp;
threshold value;
}
threshold value;
}
key-generation-self-test;
non-cryptographic-self-test;
policy {
application {
duration interval;
size count;
threshold value;
}
destination-ip {
duration interval;
size count;
threshold value;
}
450
policy match {
duration interval;
size count;
threshold value;
}
source-ip {
duration interval;
size count;
threshold value;
}
}
replay-attacks {
threshold value;
}
security-log-percent-full percentage;
}
Hierarchy Level
[edit security alarms]
Description
Configure alarms for potential violation.
Options
authentication Raise a security alarm when the device or switch detects a specified number of
authentication failures (bad password attempts) before an alarm is raised.
cryptographic-self- Raise a security alarm when the device or switch detects a cryptographic self-
test test failure. Cryptographic self-tests are a set of preoperational tests that are
performed after the device or switch is powered on. The self-tests run without
451
operator intervention. No alarm is raised upon failure of a cryptographic self-

test.
decryption-failures Raise a security alarm after exceeding a specified number of decryption failures.
encryption-failures Raise a security alarm after exceeding a specified number of encryption failures.
ike-phase1-failures Raise a security alarm after exceeding a specified number of Internet Key
Exchange (IKE) Phase 1 failures.
ike-phase2-failures Raise a security alarm after exceeding a specified number of Internet Key
Exchange (IKE) phase 2 failures.
key-generation-self- Raise a security alarm when the device or switch detects a key generation self-
test test failure. Key generation is the process of generating keys for cryptography. A
key is used to encrypt and decrypt data. The self-tests run without operator
intervention. No alarm is raised upon failure of a key generation self-test.
non-cryptographic- Raise a security alarm when the device or switch detects a noncryptographic
self-test self-test failure. The self-tests run without operator intervention. No alarm is
raised upon failure of a noncryptographic self-test.
non-cryptographic- Raise a security alarm when the device or switch detects a noncryptographic
self-test self-test failure. The self-tests run without operator intervention. No alarm is
raised upon failure of a noncryptographic self-test.
policy Configure alarms for policy violation, based on source IP, destination IP,
application, and policy rule.
replay-attacks Raise a security alarm when the device detects a replay attack.
security-log- Raise a security alarm when security log exceeds a specified percent of total
percent-full capacity.

452
Release Information
pre-id-default-policy
IN THIS SECTION
Syntax | 452
Description | 453
Options | 453
Syntax
pre-id-default-policy {
then {
log {
session-init;
session-close;
}
session-timeout {
icmp seconds;
icmp6 seconds;
ospf seconds;
others seconds;
tcp seconds;
udp seconds;
}
453
}
}
Hierarchy Level
Description
During the initial policy lookup phase, which occurs prior to a dynamic application being identified, if
there are multiple policies present in the potential policy list, the SRX Series device applies the default
security policy until a more explicit match has occurred. Configures default policy actions that occur
prior to dynamic application identification (AppID).
CAUTION: Configuring session-init logging for the pre-id-default-policy can generate a

large amount of logs. Each session that enters the SRX that initially matches the pre-id-
default-policy will generate an event. We recommend only using this option for
troubleshooting purposes.
Options
then Specifies the policy action that has to be taken when the packet matches the criteria.
log Specifies the log details at session close time and session initialization time.
• Values:
• session-init—Log at the beginning of a session
• session-close—Log at the closure of a session

454
NOTE: In recent versions of Junos OS, the factory-default configuration of an

SRX includes the session-close knob. If not already present, we recommend that
customers implement session-close logging within their pre-id-default-policy. This
will ensure security logs are generated by the SRX if a flow is unable to leave the
pre-id-default-policy. These events are generally a result of JDPI being unable to
properly classify traffic, although they may also indicate potential attempts at
evading the APPID engine.
session- When you update a session, the session timeout is configured, which specifies the session
timeout timeout details in seconds.
• Values: icmp—Timeout value for ICMP sessions (seconds)
• Range: 4 through 86,400
• Values: icmp6—Timeout value for ICMP6 sessions (seconds)
• Values: ospf—Timeout value for OSPF sessions (seconds)
• Values: others—Timeout value for other sessions (seconds)
• Values: tcp—Timeout value for TCP sessions (seconds)
• Values: udp—Timeout value for UDP sessions (seconds)

455
Release Information
Understanding Advanced Policy-Based Routing
profile(dynamic-application)
IN THIS SECTION
Syntax | 455
Description | 456
Options | 456
Syntax
profile name {
redirect-message {
type {
custom-text {
content content;
}
redirect-url {
content content;
}
}
456
}
}
Hierarchy Level
[edit security dynamic-application]
Description
Define a profile to provide an explanation for the policy action or to redirect the client request to an
informative webpage when a policy blocks HTTP or HTTPS traffic with a deny or reject action in a
security policy.
Although drop and reject actions can be logged, the users might not be notified when either action is
taken. To provide a reason for the action or to redirect the users to an informative webpage, use the
redirect-message option at the [edit security dynamic-application profile name] hierarchy level to display a
custom message.
Customize the redirect action by adding your text message on the splash screen or specify the URL to
which the user is redirected. When the redirect message option is specified, a splash screen and message
informs the client that the traffic has been blocked.
Starting in Junos OS Release 18.2R1, a redirect profile can be configured in a unified policy.
Options
name Name of the profile.
• Values:
redirect- Defines the profile of the notification sent to clients when HTTP or HTTPS
message traffic is blocked by a reject or deny action from an application firewall.
type The message type displayed after a reject or deny action.

457
custom- Text message in HTML added to the default text. If custom-text is specified,
text the splash screen displays both the default block message and the custom-
defined block message.
The user is redirected when a reject or deny action is taken during one of the
following HTTP methods: GET, POST, OPTIONS, HEAD, PUT, DELETE, TRACE,
CONNECT, PROPFIND, PROPPATCH, LOCK, UNLOCK, COPY, MOVE,
MKCOL, BCOPY, BDELETE, BCOPY, BMOVE, BPROPFIND, BPROPPATCH,
POLL, SEARCH, SUBSCRIBE, and UNSUBSCRIBE. If the reject or deny action
occurs during a different HTTP method, the traffic is silently dropped.
content Custom text added to the splash screen. Custom text is inserted below the
default message. Add the characters \n to insert a line break in the displayed
text.
redirect-url Custom URL redirection.
content The URL of the webpage to which the client is directed. When traffic is
rejected or denied, the client is redirected to the specified webpage for further
action. The URL can be hosted on either the SRX Series device or an external
server.
Enter the redirect URL in quotation marks for an HTTP or HTTPS site, as
shown in the following example:
“https://custom-redirect-url”
Release Information

458

protocol (Applications)
IN THIS SECTION
Syntax | 458
Description | 459
Options | 459
Syntax
protocol number;
Hierarchy Level

459
Description
Specify the networking protocol name or number.
Options
protocol-name— Networking protocol name. The following text values are supported. For a complete list of
possible numeric values, see RFC 1700, Assigned Numbers (for the Internet Protocol Suite).
• ah—IP Security Authentication Header
• egp—Exterior gateway protocol
• esp—IPsec Encapsulating Security Payload
• gre—Generic routing encapsulation
• icmp—Internet Control Message Protocol
• igmp—Internet Group Management Protocol
• ipip—IP over IP
• node—Clear each session that uses the specified IP protocol on a specific node.
• ospf—Open Shortest Path First
• pim—Protocol Independent Multicast
• rsvp—Resource Reservation Protocol
• sctp—Stream Control Transmission Protocol
• tcp—Transmission Control Protocol
• udp—User Datagram Protocol
NOTE: Internet Protocol version 6 (IPv6) is not supported as a network protocol in application
definitions.
460
Release Information
protocols (Security Zones Host Inbound Traffic)
IN THIS SECTION
Syntax | 461
Description | 461
Options | 461

461
Syntax
protocols {
(protocol-name | all <protocol-name except>);
}
Hierarchy Level
[edit security zones security-zone zone-name host-inbound-traffic]
Description
Specify the types of protocol traffic that can reach the device for all interfaces in a zone. You can do this
in one of several ways:
• You can enable traffic from each protocol individually.
• You can enable traffic from all protocols.
• You can enable traffic from all but some protocols.
Options
protocol- Protocol for which traffic is allowed. The following protocols are supported:
name
• all—Enable traffic from all possible protocols available. Use the except option to
disallow specific protocols.
• bfd—Enable incoming Bidirectional Forwarding Detection (BFD) protocol traffic.
• bgp—Enable incoming BGP traffic.
• dvmrp—Enable incoming Distance Vector Multicast Routing Protocol (DVMRP) traffic.

462
• igmp—Enable incoming Internet Group Management Protocol (IGMP) traffic.
• ldp—Enable incoming Label Distribution Protocol (LDP) traffic (UDP and TCP port 646).
• msdp—Enable incoming Multicast Source Discovery Protocol (MSDP) traffic.
• nhrp—Enable incoming Next Hop Resolution Protocol (NHRP) traffic.
• ospf—Enable incoming OSPF traffic.
• ospf3—Enable incoming OSPF version 3 traffic.
• pgm—Enable incoming Pragmatic General Multicast (PGM) protocol traffic (IP protocol
number 113).
• pim—Enable incoming Protocol Independent Multicast (PIM) traffic.
• rip—Enable incoming RIP traffic.
• ripng—Enable incoming RIP next generation traffic.
• router-discovery—Enable incoming router discovery traffic.
• rsvp—Enable incoming Resource Reservation Protocol (RSVP) traffic (IP protocol number
46).
• sap— Enable incoming Session Announcement Protocol (SAP) traffic. SAP always listens
on 224.2.127.254:9875. New addresses and ports can be added dynamically. This
information must be propagated to the Packet Forwarding Engine (PFE).
• vrrp—Enable incoming Virtual Router Redundancy Protocol (VRRP) traffic.
except (Optional) Disable specific incoming protocol traffic, but only when the all option has been
defined . For example, to enable all but BGP and VRRP protocol traffic:
set security zones security-zone trust host-inbound-traffic protocols all

set security zones security-zone trust host-inbound-traffic protocols bgp except
set security zones security-zone trust host-inbound-traffic protocols vrrp except

463
Release Information

protocols (Security Zones Interfaces)
IN THIS SECTION
Syntax | 463
Description | 464
Options | 464
Syntax
except;
}
464
Hierarchy Level
[edit security zones security-zone zone-name interfaces interface-name host-inbound-traffic]
Description
Specify the types of routing protocol traffic that can reach the device on a per-interface basis.
Options
• protocol-name —Protocol for which traffic is allowed. The following protocols are supported:
• all—Enable traffic from all possible protocols available.
• bfd—Enable incoming Bidirectional Forwarding Detection (BFD) Protocol traffic.
• bgp—Enable incoming BGP traffic.
• dvmrp—Enable incoming Distance Vector Multicast Routing Protocol (DVMRP) traffic.
• igmp—Enable incoming Internet Group Management Protocol (IGMP) traffic.
• ldp—Enable incoming Label Distribution Protocol (LDP) traffic (UDP and TCP port 646).
• msdp—Enable incoming Multicast Source Discovery Protocol (MSDP) traffic.
• nhrp—Enable incoming Next Hop Resolution Protocol (NHRP) traffic.
• ospf—Enable incoming OSPF traffic.
• ospf3—Enable incoming OSPF version 3 traffic.
• pgm—Enable incoming Pragmatic General Multicast (PGM) protocol traffic (IP protocol number
113).
• pim—Enable incoming Protocol Independent Multicast (PIM) traffic.
• rip—Enable incoming RIP traffic.
• ripng—Enable incoming RIP next generation traffic.

465
• router-discovery—Enable incoming router discovery traffic.
• rsvp—Enable incoming Resource Resolution Protocol (RSVP) traffic (IP protocol number 46).
• sap— Enable incoming Session Announcement Protocol (SAP) traffic. SAP always listens on
224.2.127.254:9875.
• vrrp—Enable incoming Virtual Router Redundancy Protocol (VRRP) traffic.
except—(Optional) except can only be used if all has been defined.
Release Information

range-address
IN THIS SECTION
Syntax | 466
Description | 466
466
Options | 466
Syntax
Hierarchy Level
[edit security address-book address address-name]
Description
Configure the address range for an address book.
Options
• lower-limit—Lower limit of an address range.
• upper-limit—Upper limit of an address range.

467
Release Information

redirect-wx (Application Services)
IN THIS SECTION
Syntax | 467
Description | 468
Syntax
redirect-wx;
Hierarchy Level
468
Description
ForSRX300, SRX320, SRX340, SRX345, SRX380, or SRX550M devices, define the acceleration zone
security policy for WX redirection of packets to the WXC Integrated Service Module (ISM 200) for WAN
acceleration. During the redirection process, the direction of the WX packet and its type determine
further processing of the packet.
Specify the WX redirection needed for the packets that arrive from the LAN. Use the reverse-redirect-wx
statement to specify the WX redirection needed for the reverse flow of the packets that arrive from the
WAN.
Release Information
reject (Security)
IN THIS SECTION
Syntax | 469
Description | 469
469
Options | 470
Syntax
reject {
profile redirect-profile-name;
ssl-proxy {
profile-name ssl-proxy-profile-name;
}
}
Hierarchy Level
Description
Block the service at the firewall. The device drops the packet and sends a TCP reset (RST) segment to
the source host for TCP traffic and an ICMP “destination unreachable, port unreachable” message (type
3, code 3) for UDP traffic. For types of traffic other than TCP and UDP, the device drops the packet
without notifying the source host, which is also what occurs when the action is deny.
You can configure reject action with one of the following options for the dynamic-applications:
• profile - You can chose to provide a notification to the clients or redirect client request to an
informative Web page when a policy blocks HTTP or HTTPS traffic with a deny or reject action. To
apply a profile, you must define the redirect profile for the dynamic applications.
• ssl-proxy - You can apply a redirect SSL proxy profile when a policy blocks HTTPS traffic with a reject
action. When you apply am SSL proxy profile, SSL proxy decrypts the traffic and application
470
identification functionality identifies the application. Next, you can take action to redirect or drop the
traffic as per the configuration.
Options
profile Profile for redirect HTTP/HTTPS traffic.
SSL-proxy SSL proxy profile for decrypt HTTPS traffic.
Release Information
Statement introduced in Junos OS Release 8.5. Starting in Junos OS Release 19.2, options profile and
ssl-proxy are added.
report-skip
IN THIS SECTION
Syntax | 471

471
Description | 471
Syntax
report-skip
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name],

[edit security policies global policy policy-name],
[edit logical-systems logical-system-name security policies from-zone zone-name to-zone zone-name
policy policy-name],
[edit logical-systems logical-system-name security policies global policy policy-name],
[edit tenants tenant-name security policies from-zone zone-name policy policy-name],
[edit tenants tenant-name security policies global policy policy-name],
Description
You can configure this command to skip policy reports for a policy.
Adding the policy to the policy allowlist excludes the policy from any policy analysis and excluded it
from appearing in any future report.

472
Release Information
reverse-tcp-mss
IN THIS SECTION
Syntax | 472
Description | 473
Syntax
Hierarchy Level

473
Description
Configure the TCP maximum segment size (MSS) for packets that match a specific policy and travel in
the reverse direction of a session. The value you configure replaces the TCP MSS value when the value
in the packet is higher than the one you specify.
The reverse-tcp-mss value per policy takes precedence over a global tcp-mss value (all-tcp, ipsec-vpn, gre-in,
gre-out), if one is configured. However, when the syn-flood-protection-mode syn-proxy statement at the [edit
security flow] hierarchy level is used to enable SYN proxy defenses against SYN attacks, the TCP MSS
value is not overridden.
Because each policy has two directions, you can configure a value for both directions or for just one
direction. To configure the TCP MSS value for the initial session, use the initial-tcp-mss option.
Release Information
tcp-mss (Security Flow)
syn-flood-protection-mode
474
rpc-program-number (Applications)
IN THIS SECTION
Syntax | 474
Description | 474
Options | 475
Syntax
Hierarchy Level

Description
Specify the remote procedure call (RPC) or Distributed Computing Environment (DCE) value.
475
Options
number—RPC or DCE program value.
Release Information
scheduler (Security Policies)
IN THIS SECTION
Syntax | 476
Description | 477
Options | 477

476
Syntax
scheduler scheduler-name {
daily {
(all-day | exclude | start-time hh:mm stop-time hh:mm);
}
description text;
friday {
}
monday {
}
saturday {
}
start-date date-time stop-date date-time;
sunday {
}
thursday {
}
tuesday {
}
wednesday {
}
}
Hierarchy Level
[edit schedulers]
[edit tenants <tenant-name> schedulers]
477
Description
Create or modify a scheduler that defines when security policies are in effect.
You configure a scheduler to start at a specific date and time or start on a recurrent basis.
Options
scheduler-name —Name of the scheduler. The scheduler name must consist of 1 to 63 characters that can
be letters, numbers, dashes, and underscores and can begin with a number or letter.
Release Information
Statement introduced in Junos OS Release 8.5. The description option added in Junos OS Release 12.1.
The scheduler option added under the set tenants tenant-name schedulers hierarchy in Junos OS Release
18.3R1.

478
scheduler-name
IN THIS SECTION
Syntax | 478
Description | 478
Options | 479
Syntax
Hierarchy Level
Description
Specify the schedule (as defined by the scheduler scheduler-name statement) for which the policy is in
effect.
479
Options
scheduler-name —Name of the scheduler.
Release Information
schedulers (Security Policies)
IN THIS SECTION
Syntax | 480
Description | 480
Options | 480

480
Syntax
schedulers { ... }
Hierarchy Level
[edit]
Description
Configure schedules for security policies that allow you to control network traffic flow and enforce
network security.
Options
security— To view this statement in the configuration.
security-control— To add this statement to the configuration.
Release Information
Statement introduced in Junos OS Release 8.5. The schedulers option added under the tenants hierarchy in
Junos OS Release 18.3R1.
481
screen (Security Zones)
IN THIS SECTION
Syntax | 481
Description | 481
Options | 482
Syntax
screen screen-name;
Hierarchy Level

Description
Specify a security screen for a security zone.

482
Options
screen-name —Name of the screen.
Release Information
Attack Detection and Prevention Overview

Example: Configuring Multiple Screening Options
secure-neighbor-discovery
IN THIS SECTION
Syntax | 483
Description | 483
Options | 483

483
Syntax
secure-neighbor-discovery {
command binary-file-path;
disable;
failover (alternate-media | other-routing-engine);
}
Hierarchy Level
[edit system processes]
Description
Provide support for protecting Secure Neighbor Discovery Protocol (SEND) messages.
Options
• command binary-file-path—Path to the binary process.
• disable—Disable the Secure Neighbor Discovery (SEND) protocol process.
• failover—Configure the device to reboot if the software process fails four times within 30 seconds,
and specify the software to use during the reboot.
• alternate-media—Configure the device to switch to backup media that contains a version of the
system if a software process fails repeatedly.
• other-routing-engine—Instruct the secondary Routing Engine to take the primary role if a software
process fails. If this statement is configured for a process, and that process fails four times within
30 seconds, then the device reboots from the secondary Routing Engine.
484
Release Information
security-intelligence (security policies)
IN THIS SECTION
Syntax | 484
Description | 485
Options | 485
Syntax
security-intelligence {
add-destination-identity-to-feed feed-name;
add-destination-ip-to-feed feed-name;
add-source-ip-to-feed feed-name;
add-source-identity-to-feed feed-name;
}
485
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then deny
application-services ]
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then reject
Description
Configure the security-intelligence command to add source address, destination address, source identity,
and destination identity to the security intelligence (SecIntel) profiles to generate security feeds in a
security policy. After the feeds are generated, you can configure other security policies to use the feeds
as a dynamic-address to match designated traffic and perform policy actions.
Options
add-destination-identity-to-feed feed-name; Add destination user identity to the security feed.
add-destination-ip-to-feed Add the destination IP address to the security feed.
add-source-identity-to-feed feed-name; Add source user identity to the security feed.
add-source-ip-to-feed Add the source IP address to the security feed.
The feed-name must be predefined and installed by SecIntel with the feed type and a specific ID.

486
Release Information
The add-source-identity-to-feed and destination-identity-to-feed options are introduced in Junos OS Release

21.1R1.
security-zone
IN THIS SECTION
Syntax | 486
Description | 488
Options | 488
Syntax
security-zone zone-name {
address-book {
ip-prefix {
description text;
}
description text;
ipv4-only;
ipv6-only;
}
487
}
description text;
}
}
advance-policy-based-routing;
description text;
enable-reverse-reroute;
except;
}
except;
}
}
except;
}
except;
}
}
}
screen screen-name;
tcp-rst;
unidirectional-session-refreshing;
}
Hierarchy Level

488
Description
Define a security zone, which allows you to divide the network into different segments and apply
different security options to each segment.
Options
zone-name —Name of the security zone.
Release Information
Statement introduced in Junos OS Release 8.5. Support for wildcard addresses added in Junos OS
Release 11.1. The description option added in Junos OS Release 12.1. The unidirectional-seesion-refreshing
option added in Junos OS Release 20.4R1.

Example: Configuring Application Firewall Rule Sets Within a Security Policy
489
sequence-check-required
IN THIS SECTION
Syntax | 489
Description | 489
Syntax
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then permit tcp-
options]
Description
Enable sequence check per policy. The sequence-check-required value overrides the global value no-
sequence-check.

490
Release Information

services-offload (Security)
IN THIS SECTION
Syntax | 490
Description | 491
Syntax
services-offload;
491
Hierarchy Level
Description
Enable services offloading within a security policy for SRX4600, SRX5400, SRX5600, and SRX5800
devices.
Release Information

492
session-close
IN THIS SECTION
Syntax | 492
Description | 492
Syntax
session-close;
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then log]
Description
Enable traffic to which the policy applies to be logged at the end of a session.
Session-ager is a process that runs at regular intervals and cleans up inactive sessions. The timestamp of
the session-close log is the time that session-ager closes the session.
493
Release Information

session-init
IN THIS SECTION
Syntax | 493
Description | 494
Syntax
session-init;
494
Hierarchy Level
[edit security policies from-zone zone-name to-zone zone-name policy policy-name then log]
Description
Enable traffic to which the policy applies to be logged at the beginning of a session.
Release Information

495
session-scan
IN THIS SECTION
Syntax | 495
Description | 495
Options | 496
Syntax
session-scan {
}
Hierarchy Level
Description
Trigger session scan for all the dynamic addresses

496
Options
hold-interval Time interval before the session scan request (seconds)
• Default: 10
Release Information
OS Release 22.2R1.
simple-mail-client-service
IN THIS SECTION
Syntax | 497
Description | 497
Options | 497

497
Syntax
simple-mail-client-service {
disable;
}
Hierarchy Level
Description
Specify the SMTP client process.
Options
• disable—Disable the SMTP client process.

498
Release Information
source-address (Security Policies)
IN THIS SECTION
Syntax | 498
Description | 499
Options | 499
Syntax
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
499
Hierarchy Level
Description
Define the matching criteria. You can specify one or more IP addresses, address sets, or wildcard
addresses. You can specify wildcards any, any-ipv4, or any-ipv6.
Options
address—IP addresses, address sets, or wildcard addresses (represented as A.B.C.D/wildcard-mask). You

can configure multiple addresses or address prefixes separated by spaces and enclosed in square
brackets.
Release Information
Statement introduced in Junos OS Release 8.5. Support.

500

source-address-excluded
IN THIS SECTION
Syntax | 500
Description | 500
Syntax
Hierarchy Level
Description
Exclude the source address(es) from the policy.

501
Release Information
source-identity
IN THIS SECTION
Syntax | 501
Description | 502
Options | 502
Syntax
source-identity {
[user-or-role-name];
any;
502
authenticated-user;
unknown-user;
}
Hierarchy Level
[edit security advance-policy-based-routing from-zone zone-name policy policy-name match]
Description
Identifies users and roles to be used as match criteria for a policy. If a value other than any is specified as
match criteria for a policy within a zone pair, the traffic is matched to table entries to retrieve associated
user and roles before policy lookup occurs. Users and roles are retrieved from the local authentication
table or from a UIT pushed to the SRX Series device from an access control service when a user is
authenticated.
Options
The following entries specify the source identities that match a policy:
user-or-role-name A list of specific users and roles.

503
NOTE: SRX Series devices truncate imported roles to 39 characters.

You need to ensure that all of your roles are 39 characters or less.
any Any user or role, as well as the keywords authenticated-user, unauthenticated-

user, and unknown-user.
authenticated-user All users and roles that have been authenticated.
unauthenticated- Any user or role that does not have an IP-address mapped to authentication
user sources and the authentication source is up and running.
unknown-user Any user or role that does not have an IP address mapped to authentication
sources, because the authentication source is disconnected from the SRX Series
device. In this case, users are unable to be authenticated due to an
authentication server disconnection, such as a power outage.
Unknown-user must be configured for non-domain users to be able to

authenticate and log in.
Release Information
Statement is supported in [edit security advance-policy-based-routing from-zone zone-name policy
policy-name match] hierarchy in Junos OS Release 19.1R1.

504
source-ip (Security Alarms)
IN THIS SECTION
Syntax | 504
Description | 505
Options | 505
Syntax
source-ip {
duration interval;
size count;
threshold value;
}
Hierarchy Level

505
Description
Configure alarms for a number of policy violations by a source network identifier within a specified time
period.
Options
• size count—Indicate the number of source IP addresses for which policy violation checks can be done
concurrently.
• Default: 1024.
• threshold value—Indicate the maximum number of source IP address matches required to raise an
alarm.
• Default: 1000.
Release Information

506
source-port (Applications)
IN THIS SECTION
Syntax | 506
Description | 506
Options | 507
Syntax
Hierarchy Level

Description
Specify the source port identifier.

507
Options
port-number—Identifier for the port. You can use a numeric value or one of the text synonyms listed in
"destination-port (Applications)" on page 356.
Release Information
ssl-proxy (Application Services)
IN THIS SECTION
Syntax | 508
Description | 508
Options | 508

508
Syntax
ssl-proxy {
profile-name profile-name
}
Hierarchy Level
Description
Enable SSL proxy and identify the name of the SSL proxy profile to be used. This option is supported on
SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800
devices.
Options
profile-name SSL proxy profile.

509
Release Information
Configuring SSL Forward Proxy
ssl-termination-profile
IN THIS SECTION
Syntax | 509
Description | 510
Options | 510
Syntax
Hierarchy Level
firewall-authentication pass-through]
510
Description
Specify the SSL termination profile used for SSL offloading.
Options
profile-name Specify the name of the SSL termination profile used to the SSL offload.
Release Information
start-date
IN THIS SECTION
Syntax | 511
Description | 511
511
Options | 511
Syntax
start-date date-time;
Hierarchy Level
[edit schedulers scheduler scheduler-name]
Description
Specify the time, day, month, and year that the schedule starts.
Specifying the year is optional. If no year is specified, the schedule applies to the current year and all
subsequent years. If the year is specified in either the start-date or stop-date statement, that year is used
for both statements.
Options
date-time —Use the format [ yyyy -] mm - dd . hh . mm to specify the year, month, day, hour, and minutes.

512
Release Information
start-time (Schedulers)
IN THIS SECTION
Syntax | 512
Description | 513
Options | 513
Syntax
start-time hh:mm;
513
Hierarchy Level

Description
Specify the time that a schedule starts for a specified day.
If you specify a starting time for a daily schedule with the daily statement and also include the friday,
monday, saturday, sunday, tuesday, thursday, and wednesday statements in the schedule, the starting time
specified for a specific day (for example, Friday using the friday statement) overrides the starting time
set with the daily statement.
Options
time —Use the 24-hour format (hh:mm:ss ) to specify the hours, minutes, and seconds.
Release Information

514
stop-date
IN THIS SECTION
Syntax | 514
Description | 514
Options | 515
Syntax
stop-date date-time;
Hierarchy Level
[edit schedulers scheduler scheduler-name]
Description
Specify the time, day, month, and year that the schedule ends.
515
Specifying the year is optional. If no year is specified, the schedule applies to the current year and all
subsequent years. If the year is specified in either the start-date or stop-date statement, that year is used
for both statements.
Options
date-time —Use the format [ yyyy -] mm - dd . hh . mm to specify the year, month, day, hour, and minutes.
Release Information
stop-time
IN THIS SECTION
Syntax | 516
Description | 516
Options | 517
516
Syntax
stop-time hh:mm;
Hierarchy Level

Description
Specify the time that a schedule stops for a specified day.
If you specify a stop time for a daily schedule with the daily statement and also include the the friday,
monday, saturday, sunday, tuesday, thursday, and wednesday statements in the schedule, the stop time specified
for a specific day (for example, Friday using the friday statement) overrides the stop time set with the
daily statement.
517
Options
time —Use the 24-hour format (hh:mm:ss ) to specify the hours, minutes, and seconds.
Release Information
Statement introduced in Junos OS Release.
syn-check-required
IN THIS SECTION
Syntax | 518
Description | 518

518
Syntax
syn-check-required;
Hierarchy Level

Description
Enable sync check per policy. The syn-check-required value overrides the global value no-syn-check.
Release Information
Attack Detection and Prevention Overview

Example: Configuring Multiple Screening Options
519
system-services (Security Zones Host Inbound

Traffic)
IN THIS SECTION
Syntax | 519
Description | 519
Options | 520
Syntax
system-services {
(service-name | all <service-name except>);
}
Hierarchy Level
[edit security zones security-zone zone-name host-inbound-traffic]
Description
Specify the types of incoming system service traffic that can reach the device for all interfaces in a zone.
You can do this in one of several ways:
• You can enable traffic from each system service individually.

520
• You can enable traffic from all system services.
• You can enable traffic from all but some system services.
Options
• service-name —System-service for which traffic is allowed. The following system services are
supported:
• all—Enable traffic from the defined system services available on the Routing Engine (RE). Use the
except option to disallow specific system services. Enabling all the system services does not
override any interface specific configuration under a particular zone.
• any-service—Enable all system services on entire port range including the system services that are
not defined.
• bootp—Enable traffic destined to BOOTP and DHCP relay agents.
• dhcp—Enable incoming DHCP requests.
• dhcpv6—Enable incoming DHCP requests for IPv6.
• dns—Enable incoming DNS services.
• finger—Enable incoming finger traffic.
• ftp—Enable incoming FTP traffic.
• http—Enable incoming J-Web or clear-text Web authentication traffic.
• https—Enable incoming J-Web or Web authentication traffic over Secure Sockets Layer (SSL).
• ident-reset—Enable the access that has been blocked by an unacknowledged identification

request.
• ike—Enable Internet Key Exchange traffic.
• lsping—Enable label switched path ping service.
• netconf—Enable incoming NETCONF service.
• ntp—Enable incoming Network Time Protocol (NTP) traffic.
• ping—Allow the device to respond to ICMP echo requests.
• r2cp—Enable incoming Radio Router Control Protocol traffic.

521
• reverse-ssh—Reverse SSH traffic.
• reverse-telnet—Reverse Telnet traffic.
• rlogin—Enable incoming rlogin (remote login) traffic.
• rpm—Enable incoming Real-time performance monitoring (RPM) traffic.
• rsh—Enable incoming Remote Shell (rsh) traffic.
• snmp—Enable incoming SNMP traffic (UDP port 161).
• snmp-trap—Enable incoming SNMP traps (UDP port 162).
• ssh—Enable incoming SSH traffic.
• telnet—Enable incoming Telnet traffic.
• tftp—Enable TFTP services.
• traceroute—Enable incoming traceroute traffic (UDP port 33434).
• xnm-clear-text—Enable incoming Junos XML protocol traffic for all specified interfaces.
• xnm-ssl— Enable incoming Junos XML protocol-over-SSL traffic for all specified interfaces.
• except—(Optional) Enable specific incoming system service traffic but only when the all option has
been defined . For example, to enable all but FTP and HTTP system service traffic:
set security zones security-zone trust host-inbound-traffic system-services all

set security zones security-zone trust host-inbound-traffic system-services ftp except
set security zones security-zone trust host-inbound-traffic system-services http except
Release Information

522

system-services (Security Zones Interfaces)
IN THIS SECTION
Syntax | 522
Description | 523
Options | 523
Syntax
except;
}
Hierarchy Level
[edit security zones security-zone zone-name interfaces interface-name host-inbound-traffic]

523
Description
Specify the types of traffic that can reach the device on a particular interface.
Options
• service-name —Service for which traffic is allowed. The following services are supported:
• all—Enable all possible system services available on the Routing Engine (RE).
• any-service—Enable services on entire port range.
• bootp—Enable traffic destined to BOOTP and DHCP relay agents.
• dhcp—Enable incoming DHCP requests.
• dhcpv6—Enable incoming DHCP requests for IPv6.
• dns—Enable incoming DNS services.
• finger—Enable incoming finger traffic.
• ftp—Enable incoming FTP traffic.
• http—Enable incoming J-Web or clear-text Web authentication traffic.
• https—Enable incoming J-Web or Web authentication traffic over Secure Sockets Layer (SSL).
• ident-reset—Enable the access that has been blocked by an unacknowledged identification

request.
• ike—Enable Internet Key Exchange traffic.
• netconf SSH—Enable incoming NetScreen Security Manager (NSM) traffic over SSH.
• ntp—Enable incoming Network Time Protocol (NTP) traffic.
• ping—Allow the device to respond to ICMP echo requests.
• r2cp—Enable incoming Radio Router Control Protocol traffic.
• reverse-ssh—Reverse SSH traffic.
• reverse-telnet—Reverse Telnet traffic.
• rlogin—Enable incoming rlogin (remote login) traffic.

524
• rpm—Enable incoming real-time performance monitoring (RPM) traffic.
• rsh—Enable incoming Remote Shell (rsh) traffic.
• snmp—Enable incoming SNMP traffic (UDP port 161).
• snmp-trap—Enable incoming SNMP traps (UDP port 162).
• ssh—Enable incoming SSH traffic.
• telnet—Enable incoming Telnet traffic.
• tftp—Enable TFTP services.
• traceroute—Enable incoming traceroute traffic (UDP port 33434).
• xnm-clear-text—Enable incoming Junos XML protocol traffic for all specified interfaces.
• xnm-ssl— Enable incoming Junos XML protocol-over-SSL traffic for all specified interfaces.
• except—(Optional) except can only be used if all has been defined.
Release Information

525
tcp-options (Security Policies)
IN THIS SECTION
Syntax | 525
Description | 526
Options | 526
Syntax
tcp-options {
syn-check-required;
window-scale;
}
Hierarchy Level
[edit logical-systems logical-system-name security policies from-zone],

[edit logical-systems logical-system-name security policies global policy name then],
[edit logical-systems logical-system-name security policies stateful-firewall-rule name policy
name then],
[edit logical-systems logical-system-name tenants name security policies from-zone],
[edit logical-systems logical-system-name tenants name security policies global
policy name then],
[edit logical-systems logical-system-name tenants name security policies stateful-firewall-rule
526
name policy name then],

[edit security policies global policy name then],
[edit security policies stateful-firewall-rule name policy name then],
[edit tenants tenant-name security policies from-zone],
[edit tenants tenant-name security policies global policy name then],
[edit tenants tenant-name security policies stateful-firewall-rule name policy name then]
Description
Specify the TCP options for each policy. You can configure sync and sequence checks for each policy
based on your requirements, and, because each policy has two directions, you can configure a TCP MSS
value for both directions or for just one direction. To configure per-policy TCP options, you must turn off
the respective global options. Otherwise, the commit check will fail.
Options
initial-tcp-mss Configure the TCP maximum segment size (MSS) for packets that arrive at the ingress
interface (initial direction), match a specific policy, and for which a session is created.
The value you configure overrides the TCP MSS value in the incoming packet when the
value in the packet is higher than the one you specify.
The initial-tcp-mss value per policy takes precedence over a global tcp-mss value (all-tcp,
ipsec-vpn, gre-in, gre-out), if one is configured. However, when the syn-flood-protection-mode
syn-proxy statement at the [edit security flow] hierarchy level is used to enable SYN
proxy defenses against SYN attacks, the TCP MSS value is not overriden.
Because each policy has two directions, you can configure a value for both directions
or for just one direction. To configure a TCP MSS value for the reverse session, use the
reverse-tcp-mss option.
reverse-tcp- Configure the TCP maximum segment size (MSS) for packets that match a specific
mss policy and travel in the reverse direction of a session. The value you configure replaces
the TCP MSS value when the value in the packet is higher than the one you specify.
527
The reverse-tcp-mss value per policy takes precedence over a global tcp-mss value (all-tcp,
ipsec-vpn, gre-in, gre-out), if one is configured. However, when the syn-flood-protection-mode
syn-proxy statement at the [edit security flow] hierarchy level is used to enable SYN
proxy defenses against SYN attacks, the TCP MSS value is not overridden.
Because each policy has two directions, you can configure a value for both directions
or for just one direction. To configure the TCP MSS value for the initial session, use the
initial-tcp-mss option.
sequence- Enable sequence check per policy. The sequence-check-required value overrides the
check- global value no-sequence-check.
required
syn-check- Enable sync check per policy. The syn-check-required value overrides the global value
required no-syn-check.
window-scale Enable window-scale per policy.
Release Information
The tcp-options, sequence-check-required, and syn-check-required statements are introduced in Junos OS

Release 10.4.
The initial-tcp-mss and reverse-tcp-mss statements are introduced in Junos OS Release 12.3X48-D20.
The window-scale statement is introduced in Junos OS Release 15.1X49-D70.

528
tcp-rst
IN THIS SECTION
Syntax | 528
Description | 528
Default | 529
Syntax
tcp-rst;
Hierarchy Level
Description
Enable the device to send a TCP segment with the RST (reset) flag set to 1 (one) in response to a TCP
segment with any flag other than SYN set and that does not belong to an existing session.
529
During flow first path process, a TCP RST packet is sent to the traffic originator if the TCP packet trying
to create the flow session is not a SYN packet.
Default
By default, tcp-rst is disabled.
Release Information
term (Applications)
IN THIS SECTION
Syntax | 530
Description | 530
Options | 531
530
Syntax
term term-name {
alg application;
icmp-code value;
icmp-type value;
icmp6-code value;
icmp6-type value;
protocol number;
uuid hex-value;
}
Hierarchy Level
[edit applications application application-name]
Description
Define individual application protocols.

531
Options
Release Information
then (Security Policies)
IN THIS SECTION
threshold-logging-interval | 534
Syntax
then {
count {
alarm {
532
}
}
deny;
log {
session-close;
session-init;
}
permit {
}
}
idp;
ssl-proxy {
}
uac-policy {
}
}
drop-translated;
drop-untranslated;
}
pass-through {
web-redirect;
}
user-firewall {
533
domain domain-name
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
tunnel {
ipsec-vpn vpn-name;
}
}
reject;
}
Hierarchy Level
Description
Specify the policy action to be performed when packets match the defined criteria.
Options

534
Release Information
Statement introduced in Junos OS Release 8.5. Support for the services-offload option added in Junos OS
Release 11.4. Support for the ssl-termination-profile and web-redirect-to-https options added in Junos OS
Release 12.1X44-D10. Support for the user-firewall option added in Junos OS Release 12.1X45-D10.
Support for the initial-tcp-mss and reverse-tcp-mss options added in Junos OS Release 12.3X48-D20.
threshold-logging-interval
IN THIS SECTION
Syntax | 534
Description | 535
Options | 535
Syntax
threshold-logging-interval <minutes>
535
Hierarchy Level
[edit tenants tenant name security idp sensor-configuration packet-log]

[edit logical system logical system name security idp sensor-configuration packet-log]
Description
The minimum time interval in minutes between log messages for maximum sessions or memory reached.
Options
minutes-Interval to generate syslog messages when configured packet-log total memory or max-sessions
is reached.
• Range 1 to 60
• Default 15
Release Information
Statement introduced in Junos OS Release 21.3
No Link Title

536
to-zone (Security Policies)
IN THIS SECTION
Syntax | 536
Description | 538
Options | 539
Syntax
to-zone zone-name {
match {
application {
[application];
any;
}
[address];
any;
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
537
any;
authenticated-user;
unknown-user;
}
}
then {
count {
alarm {
}
}
deny;
log {
session-close;
session-init;
}
permit {
}
}
idp;
ssl-proxy {
}
uac-policy {
}
}
drop-translated;
drop-untranslated;
}
538
pass-through {
web-redirect;
}
}
}
services-offload;
tcp-options {
syn-check-required;
}
tunnel {
ipsec-vpn vpn-name;
}
}
reject;
}
}
}
Hierarchy Level
[edit security policies from-zone zone-name]
Description
Specify a destination zone to be associated with the security policy.

539
Options
• zone-name—Name of the destination zone object.
• junos-host—Default security zone for self-traffic of the device.
Release Information
Statement introduced in Junos OS Release 8.5. Support for the services-offload and junos-host options
added in Junos OS Release 11.4. Support for the source-identity option added in Junos OS Release 12.1.
Support for the ssl-termination-profile and web-redirect-to-https options added in Junos OS Release
12.1X44-D10.

to-zone (Security Policies Global)
IN THIS SECTION
Syntax | 540
540
Description | 540
Syntax
to-zone {
[zone-name];
any;
}
Hierarchy Level
Description
Identify a single destination zone or multiple destination zones to be used as a match criteria for a
policy. You must configure specific zones or default to any zone, but you cannot have both in a global
policy.

541
Release Information

traceoptions (dynamic-address)
IN THIS SECTION
Syntax | 541
Description | 542
Options | 542
Syntax
traceoptions {
file< filename><files files><match match><size size><(world-readable | no-world-readable)>;
flag name;
level(all | error | info | notice | verbose | warning);

no-remote-trace;
}
542
Hierarchy Level
Description
Security dynamic address tracing options
Options
level Level of debugging output
• all—Match all levels
• error—Match error conditions
• info—Match informational messages
• notice—Match conditions that should be handled specially
• verbose—Match verbose messages
• warning—Match warning messages
no-remote-trace Disable remote tracing
trace—To view this statement in the configuration.
trace-control—To add this statement to the configuration.

543
Release Information
OS Release 22.2R1.
traceoptions (dynamic-application)
IN THIS SECTION
Syntax | 543
Description | 544
Options | 544
Syntax
traceoptions {
file {
filename;
files number;
}
flag flag;
no-remote-trace;
}
544
Hierarchy Level
[edit security dynamic-application]

Description
Configure dynamic application tracing options.
NOTE: NOTE: Traceoptions does not differentiate between a logical system and tenant system,
and can be configured under the root logical system.
Options
file Trace file information
• Values:
filename Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the
directory /var/log. By default, the name of the file is the name of the
process being traced.
files number Maximum number of trace files. When a trace file named trace-file
reaches its maximum size, it is renamed as trace-file.0, then trace-file.1,
and so on, until the maximum number of trace files is reached. The
oldest archived file is overwritten.
If you specify a maximum number of files, you also must specify a

maximum file size with the size option and a filename.
• Default: 3 files
545
match Refine the output to include lines that contain the regular expression.
regular-
expression
size Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or
maximum-file- gigabytes (GB). When a trace file named trace-file reaches this size, it is
size renamed trace-file.0. When the trace-file again reaches its maximum
size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-
file.0. This renaming scheme continues until the maximum number of
trace files is reached. Then the oldest trace file is overwritten.
• Range: 10 KB through 1 GB
• Default: 128 KB
world- By default, the log files can be accessed only by the user who
readable|no- configures the tracing operation. The world-readable option enables any
world- user to read the file. To explicitly set the default behavior, use the no-
readable world-readable option.
flag Configure tracing parameters
• Values:
all Trace with all flags enabled.
configuration Trace configuration events.
compilation Trace compilation events.
ipc Trace process intercommunication events.
lookup Trace lookup events.
no- Set remote tracing as disabled.

remote-
trace

546
Release Information

traceoptions (Security Policies)
IN THIS SECTION
Syntax | 546
Description | 547
Options | 547
Syntax
traceoptions {
file {
filename;
files number;
}
flag flag;
547
no-remote-trace;
}
Hierarchy Level
Description
Configure policy tracing options.
Options
• file—Configure the trace file options.
• filename—Name of the file to receive the output of the tracing operation. Enclose the name within
quotation marks. All files are placed in the directory /var/log. By default, the name of the file is the
name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file reaches its
maximum size, it is renamed to trace-file.0, then trace-file.1, and so on, until the maximum
number of trace files is reached. The oldest archived file is overwritten.
If you specify a maximum number of files, you also must specify a maximum file size with the size
option and a filename.
Range: 2 through 1000 files
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular expression.
• size maximum-file-size—Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or
gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0.
When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-
file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace
files is reached. Then the oldest trace file is overwritten.
548
If you specify a maximum file size, you also must specify a maximum number of trace files with
the files option and a filename.
Syntax: x K to specify KB, x m to specify MB, or x g to specify GB
Range: 10 KB through 1 GB
Default: 128 KB
• world-readable | no-world-readable—By default, log files can be accessed only by the user who
configures the tracing operation. The world-readable option enables any user to read the file. To
explicitly set the default behavior, use the no-world-readable option.
• flag—Trace operation to perform. To specify more than one trace operation, include multiple flag
statements.
• all—Trace with all flags enabled
• configuration—Trace configuration events
• compilation—Trace policy compilation events
• ipc—Trace process inter communication events
• lookup—Trace policy lookup events
• routing-socket—Trace routing socket events
• rules—Trace policy rules-related events
• no-remote-trace—Set remote tracing as disabled.
Release Information

549
traceoptions (Security User Identification)
IN THIS SECTION
Syntax | 549
Description | 550
Options | 550
Syntax
traceoptions {
file {
filename;
files number;
}
flag flag;
no-remote-trace;
}
550
Hierarchy Level
[edit security user-identification]
Description
Configure flow tracing options.
Options
• file—Configure the trace file options.
• filename—Name of the file to receive the output of the tracing operation. Enclose the name
within quotation marks. All files are placed in the directory /var/log. By default, the name of the
file is the name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file its maximum
size, it is renamed to trace-file.0, then trace-file.1, and so on, until the maximum number of trace
files is reached. The oldest archived file is overwritten.
If you specify a maximum number of files, you also must specify a maximum file size with the size
option and a filename.
Range: 2 through 1000 files
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular expression.
• size maximum-file-size—Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or
gigabytes (GB). When a trace file named trace-file reaches this size, it is renamed trace-file.0.
When the trace-file again reaches its maximum size, trace-file.0 is renamed trace-file.1 and trace-
file is renamed trace-file.0. This renaming scheme continues until the maximum number of trace
files is reached. Then the oldest trace file is overwritten.
If you specify a maximum file size, you also must specify a maximum number of trace files with
the files option and a filename.
Syntax: x K to specify KB, x m to specify MB, or x g to specify GB

551
Range: 10 KB through 1 GB
Default: 128 KB
• world-readable | no-world-readable—By default, log files can be accessed only by the user who
configures the tracing operation. The world-readable option enables any user to read the file. To
explicitly set the default behavior, use the no-world-readable option.
• flag—Trace operation to perform.
• all—Trace with all flags enabled
• no-remote-trace—Set remote tracing as disabled.
Release Information
traceoptions (System Services DNS)
IN THIS SECTION
Syntax | 552

552
Description | 552
Options | 552
Syntax
traceoptions {
category {
category-type;
}
file;
}
Hierarchy Level
[edit system services dns]
Description
Defines tracing options for DNS services.
Options
category—Specifies the logging category. See Table 32 on page 553 for the different logging categories
and their descriptions.
file—Trace file information.

553
Table 32: Category Names
Category Name Description
client Processing of client requests
config Configuration file parsing and processing
database Messages relating to the databases
default Categories for which there is no specific configuration
delegation-only Delegation only
dispatch Dispatching of incoming packets to the server
dnssec DNSSEC and TSIG protocol processing
edns-disabled Log query using plain DNS
general General information
lame-servers Lame servers
network Network options
notify NOTIFY protocol
queries DNS query resolver
resolver DNS resolution security
security Approval and denial of requests

554
Table 32: Category Names (Continued)
Category Name Description
unmatched Unable to determine the class for messages named
update Dynamic updates
update-security Approval and denial of update requests
xfer-in Zone transfers that the server is receiving xfer-out
xfer-out Zone transfers that the server is sending
Release Information
DNS Overview
555
tunnel (Security Policies)
IN THIS SECTION
Syntax | 555
Description | 555
Options | 556
Syntax
tunnel {
ipsec-vpn vpn-name;
}
Hierarchy Level
Description
Encapsulate outgoing IP packets and decapsulate incoming IP packets.

556
Options
Release Information
Statement introduced in Junos OS Release 8.5. The ipsec-group-vpn option added in Junos OS Release
10.2.

tunnel-inspection
IN THIS SECTION
Syntax | 557
Description | 557
Options | 558

557
Syntax
tunnel-inspection {
inspection-profile profile-name {
vxlan vxlan-name {
policy-set pset-name;
vni vni-name;
}
}
traceoptions {
file <filename> <files files> <match match> <size size> <(world-readable | no-world-
readable)>;
flag name;
no-remote-trace;
}
vni vni-name {
vni-id vni-id;
vni-range <vni-range-low to vni-range-high>;
}
}
Hierarchy Level
[edit security]
Description
Configure security inspection on VXLAN tunnels. Configure an outer policy for the outer header and an
inner policy for the inner header.
558
Configure a tunnel inspection profile to connect the outer policy and inner policy. The tunnel inspection
profile is attached to the outer policy and it points to a group of inner policies (policy set). When the
packet matchs the outer policy, the SRX device decapsulates the packet to get the inner header. Using
inner packet content along with the attached tunnel inspection profile of outer policy, the second policy
lookup gets the desired inner policy applies the security services to inner packet.
Options
inspection-profile Configure a tunnel inspection profile to connect the outer policy and inner policy.
vni Configure VXLAN Network Identifier for tunnel inspection.
security
Release Information
uac-policy (Application Services)
IN THIS SECTION
Syntax | 559
Description | 559
Options | 559
559
Syntax
uac-policy {
}
Hierarchy Level
Description
Enable Unified Access Control (UAC) for the security policy. This statement is required when you are
configuring the SRX Series device to act as a Junos OS Enforcer in a UAC deployment. When deployed
as a Junos OS Enforcer, the SRX Series device enforces the policies that are defined on the UAC’s IC
Series UAC Appliance .
Options

560
Release Information

unidirectional-session-refreshing
IN THIS SECTION
Syntax | 560
Description | 561
Syntax
unidirectional-session-refreshing;
561
Hierarchy Level
[edit security zones security-zone],
Description
Use unidirectional session refreshing on a zone to enable two options for a session. Refresh a session by
any packet from any directions. This is a default behavior. Refresh a session by only the packets in the
initial direction.
security
Release Information
security-zone | 486
unified-policy-explicit-match
IN THIS SECTION
Syntax | 562
562
Description | 562
Syntax
unified-policy-explicit-match;
Hierarchy Level
Description
Enable explicit match in a unified policy.
• In a unified policy, when you enable explicit match, the session is dropped if a dependent application
does not have any matching policy.
• In a unified policy, when explicit match is not configured, then implicit match is applied. That is, if the
dependent application does not have a matching policy, then the security policy that is configured for
the base application is applied.
By default, the unified policies enforce implicit rules on dependent applications.
security— To view this statement in the configuration.
security-control— To add this statement to the configuration.

563
Release Information

user-firewall
IN THIS SECTION
Syntax | 563
Description | 564
Options | 564
Syntax
user-firewall {
domain domain-name
}
564
Hierarchy Level
Description
Configure user role firewall authentication, and map the source IP address to the username and its
associated roles (groups). The mapped data is written to the firewall authentication table for later
retrieval by the user role firewall. The user role firewall uses the username and role information to
determine whether to permit or deny a user's session or traffic.
Options
access-profile profile- Specify the name of the access profile to be used for authentication.
name
domain domain-name Specify the name of the domain where firewall authentication occurs in the
event that the Windows Management Instrumentation client (WMIC) is not
available to get IP-to-user mapping for the integrated user firewall feature. The
maximum length is 65 bytes.
ssl-termination-profile For HTTPS traffic, specify the name of the SSL termination profile used for SSL
profile-name offloading.

565
Release Information
Statement introduced in Junos OS Release 12.1X45-D10. Support for the domain keyword added in
Junos OS Release 12.1X47-D10.
Overview of Integrated User Firewall

Using Firewall Authentication as an Alternative to WMIC
user-identification
IN THIS SECTION
Syntax | 565
Description | 566
Options | 566
Syntax
user-identification {
authentication-source {
firewall-authentication (disable | priority priority);
local-authentication-table (disable | priority priority);
unified-access-control (disable | priority priority);
}
566
traceoptions {
file {
filename;
files number;
}
flag flag;
no-remote-trace;
}
}
Hierarchy Level
[edit security]
Description
Identifies one or more tables to be used as the source for user role information.
Options

567
Release Information

utm-policy
IN THIS SECTION
Syntax | 567
Description | 569
Options | 569
Syntax
utm-policy policy-name {
anti-spam {
smtp-profile profile-name;
}
anti-virus {
ftp {
download-profile profile-name;
upload-profile profile-name;
}
568
http-profile profile-name;
imap-profile profile-name;
pop3-profile profile-name;
}
content-filtering {
ftp {
download-profile profile-name;
upload-profile profile-name;
}
imap-profile profile-name;
pop3-profile profile-name;
rule-set rule-set-name {
rule rule-name {
match {
application any; /*http, pop3, impa, smtp, ftp */
direction any; /* upload or download */
file-type exe; /*predetect magic supported file types*/
}
then {
action {
no-action; /* No action */
/* block Block and drop connection */
/* close-client Close client */
/* close-server Close server */
/* close-client-and-server Close client and server */
}
notification {
seclog; /* event logging */
endpoint { /* endpoint notification options */
type protocol-only;
notify-mail-sender;
custom-message "CF Blocks content";
}
}
traffic-options {
sessions-per-client {
limit value;
over-limit (block | log-and-permit);
}
}
569
web-filtering {
}
}
Hierarchy Level
[edit security utm default-configuration]

[edit security utm]
Description
Configure a UTM policy for antivirus, antispam, content-filtering, traffic-options, and Web-filtering
protocols and attach this policy to a security profile to implement it.
Options
policy-name—Specify name of the UTM policy.
Release Information

570
The [edit security utm default-configuration] hierarchy level is introduced in Junos OS Release 18.2R1.

uuid (Applications)
IN THIS SECTION
Syntax | 570
Description | 571
Options | 571
Syntax
uuid hex-value;
Hierarchy Level

571
Description
Specify the Universal Unique Identifier (UUID) for objects. DCE RPC services are mainly used by
Microsoft applications. The ALG uses well-known TCP port 135 for port mapping services and uses the
Universal Unique Identifier (UUID) instead of the program number to identify protocols. The main
application-based DCE RPC is the Microsoft Exchange Protocol.
Support for stateful firewall and NAT services requires that you configure the DCE RPC port map ALG
on TCP port 135. The DCE RPC ALG uses the TCP protocol with application-specific UUIDs.
Options
uuid hex-value —Specify the universal unique identifier (UUID) for objects.
Release Information
vrrp
IN THIS SECTION
Syntax | 572
Description | 572
572
Options | 572
Syntax
vrrp {
disable;
failover (alternate-media | other-routing-engine);
}
Hierarchy Level
Description
Specify the Virtual Router Redundancy Protocol (VRRP) process.
Options
• disable—Disable the VRRP process.
• failover—Configure the device to reboot if the software process fails four times within 30 seconds,
and specify the software to use during the reboot.
573
• alternate-media—Configure the device to switch to backup media that contains a version of the
system if a software process fails repeatedly.
• other-routing-engine—Instruct the secondary Routing Engine to take the primary role if a software
process fails. If this statement is configured for a process, and that process fails four times within
30 seconds, then the device reboots from the secondary Routing Engine.
NOTE: On SRX300 and SRX320 devices, you cannot configure the same VRRP group ID on
different interfaces of a single device
Release Information
web-authentication
IN THIS SECTION
Syntax | 574
Description | 574
Options | 574

574
Syntax
}
Hierarchy Level
Description
Specify that the policy allows access to users who have previously been authenticated by Web
authentication. Web authentication must be enabled on one of the addresses on the interface to which
the HTTP or HTTPS request is redirected.
Options
client-match user-or-group —(Optional) Username or user group name.

575
Release Information
HTTPS for Web authentication is supported on SRX5400, SRX5600, and SRX5800 devices starting from
Junos OS Release 12.1X44-D10 and on vSRX, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M,
and SRX1500 Services Gateways starting from Junos OS Release 15.1X49-D40.
web-redirect
IN THIS SECTION
Syntax | 575
Description | 576
Syntax
web-redirect;
576
Hierarchy Level
firewall-authentication pass-through user-firewall]
Description
Optionally, redirect HTTP requests to the device’s internal webserver by sending a redirect HTTP
response to the client system to reconnect to the webserver for user authentication. The interface on
which the client’s request arrived is the interface to which the request is redirected.
Release Information
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, support for user-firewall
added on SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200,
SRX5400, SRX5600, and SRX5800 devices and vSRX Services Gateways.

577
zones
IN THIS SECTION
Syntax | 577
Description | 579
Options | 579
Syntax
zones {
functional-zone {
management {
description text;
except;
}
except;
}
}
except;
}
except;
}
}
}
578
screen screen-name;
}
}
security-zone zone-name {
address-book {
ip-prefix {
description text;
}
description text;
ipv4-only;
ipv6-only;
}
}
description text;
}
}
advance-policy-based-routing;
description text;
except;
}
except;
}
}
except;
}
except;
}
}
579
}
screen screen-name;
tcp-rst;
}
}
Hierarchy Level
[edit security]
Description
A zone is a collection of interfaces for security purposes. All interfaces in a zone are equivalent from a
security point of view. Configure the following zones:
• Functional zone—Special-purpose zone, such as a management zone that can host dedicated
management interfaces.
• Security zone—Most common type of zone that is used as a building block in policies.
Options

580
Release Information
Statement introduced in Junos OS Release 8.5. Support for wildcard addresses added in Junos OS

7 CHAPTER
Operational Commands
clear security alarms | 583
show security firewall-authentication users address | 609
show security firewall-authentication users auth-type | 614
show security flow session application | 617
show security match-policies | 623
show security policies information | 665
show security policies unknown-source-identity | 674
show security policies zone-context | 676

show security shadow-policies | 684
show security user-identification local-authentication-table | 687
show security zones type | 706

583
clear security alarms
IN THIS SECTION
Syntax | 583
Description | 583
Options | 584
Output Fields | 585
Sample Output | 585
Syntax

<all>
<alarm-id id-number>
<alarm-type [ types ]>
<newer-than YYYY-MM-DD.HH:MM:SS>
<older-than YYYY-MM-DD.HH:MM:SS>
<process process>
<severity severity>
Description
Clear (acknowledge) the alarms that are active on the device.

584
Options
all (Optional) Clear all active alarms.
alarm-id id-number (Optional) Clear the specified alarm.
alarm-type [ types ] (Optional) Clear the specified alarm type or a set of types.
You can specify one or more of the following alarm types:
• authentication
• cryptographic-self-test
• decryption-failures
• encryption-failures
• ike-phase1-failures
• key-generation-self-test
• non-cryptographic-self-test
• policy
• replay-attacks
newer-than YYYY-MM- (Optional) Clear active alarms that were raised after the specified date and
DD.HH:MM:SS time.
older-than YYYY-MM- (Optional) Clear active alarms that were raised before the specified date and
DD.HH:MM:SS time.
process process (Optional) Clear active alarms that were raised by the specified system
process.
severity severity (Optional) Clear active alarms of the specified severity.
You can specify the following severity levels:
• alert
• crit
585
• debug
• emerg
• err
• info
• notice
• warning
Output Fields
This command produces no output, except a statement about the number of security alarms cleared.
Sample Output
clear security alarms all
[3 SECURITY ALARMS] user@router> clear security alarms all
3 security alarms cleared
clear security alarms alarm-id <alarm-id>
[3 SECURITY ALARMS] user@router> clear security alarms alarm-id 1
1 security alarm cleared

586
clear security alarms alarm-type authentication
[3 SECURITY ALARMS] user@router> clear security alarms alarm-type authentication
clear security alarms newer-than <time>
[3 SECURITY ALARMS] user@router> clear security alarms newer-than 2010-01-19.13:41:59
1 security alarm cleared
show security alarms older-than <time>
[3 SECURITY ALARMS] user@router> clear security alarms older-than 2010-01-19.13:41:59
show security alarms process <process>
[3 SECURITY ALARMS] user@router> clear security alarms process sshd
show security alarms severity <severity>
[3 SECURITY ALARMS] user@router> clear security alarms severity notice
Release Information
Command introduced in Junos OS Release 11.2.

587

clear security policies hit-count
IN THIS SECTION
Syntax | 587
Description | 587
Options | 588
Additional Information | 588
Output Fields | 588
Syntax
clear security policies hit-count

<from-zone zone-name>
<to-zone zone-name>
Description
Clear the hit-count values for security policies.

588
Options
• from-zone zone-name—(Optional) Clear the number of hits for security policies associated with the
named source zone.
• to-zone zone-name—(Optional) Clear the number of hits for security policies associated with the named
destination zone.
Additional Information
clear
Output Fields
This command produces no output.
Release Information
Command introduced in Junos Release 12.1.

589
clear security policies statistics
IN THIS SECTION
Syntax | 589
Description | 589
Output Fields | 589
Syntax
clear security policies statistics
Description
Clear systemwide policies statistics and security policies statistics configured on the device.
clear
Output Fields
This command produces no output.

590
Release Information
Command introduced in Junos OS Release 8.5. Support.

clear system services dns dns-proxy
IN THIS SECTION
Syntax | 590
Description | 590
Options | 591
Output Fields | 591
Syntax
clear system services dns dns-proxy
Description
Clear DNS proxy cache information. This option is supported on the SRX300, SRX320, SRX340,
SRX345, SRX380, and SRX550M devices.
591
Options
• cache—Clear DNS proxy cache information.
• statistics—Clear DNS proxy statistics.
• none—Clear all DNS proxy cache information.
• hostname—(Optional) Clear DNS proxy cache information from the specified host.
clear
Output Fields
When you enter this command no output is produced.
Release Information
Command introduced in Junos OS Release 12.1X44-D10.

592
request security policies check
IN THIS SECTION
Syntax | 592
Description | 592
Options | 593
Sample Output | 594
Syntax

<from-zone zone name>
<global>
<logical-system (logical-system name | all)>
<pfe>
<root-logical-system>
<to-zone zone-name>
<tenant tenant-name>
Description
Displays the security policy sync status between the Routing Engine and the Packet Forwarding Engine.
Use the command to display a list of all security polices which are in-sync or out-of-sync on the device.
the request security policies resync command to synchronize the configuration of security policies in the
Routing Engine and Packet Forwarding Engine.
593
Options
<from-zone zone-name Displays security policies sync status from this zone.
global Displays global policies sync status.
logical-system (logical- Displays security policies sync status for the security policies configured on a
system name | all) logical system or on all logical systems.
pfe Displays security policies sync status for the security policies on the Packet
Forwarding Engine.
root-logical-system Displays security policies sync status for the security policies configured on
the root logical system. This is the default outcome.
to-zone zone-name Displays security policies sync status to this zone.
tenant tenant-name Displays security policies sync status for the security policies configured on a
tenant.
message displays - error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)>. Please request
maintenance
594
Sample Output
user@host> request security policies check

Start sending policies ...
Success
Total sent 1 policy.
Policy Checking Result:

PFE master in-sync
request security policies check logical-system LSYS1
user@host> request security policies check logical-system LSYS1

Success

PFE fpc0.pic3 in-sync
request security policies check logical-system all
user@host> request security policies check logical-system all

Success
Total sent 2 policies.

595
request security policies check from-zone trust to-zone untrust
user@host> request security policies check from-zone trust to-zone untrust

Success

PFE fpc4.pic1 out-of-sync
Release Information
Command introduced in Junos OS Release 18.4R1.

request security policies resync
IN THIS SECTION
Syntax | 596
Description | 596
Options | 596
Sample Output | 597

596
Syntax

<from-zone zone name>
<global>
<pfe>
<to-zone zone-name>
Description
Synchronize the configuration of security policies in the Routing Engine and Packet Forwarding Engine.
This command recovers the security policies in the Packet Forwarding Engine. If policy inconsistencies
between the Routing Engine and Packet Forwarding Engine are determined, the security policies resync.
Options
<from-zone zone-name Recover the policies from this zone.
global Recover global policies.
logical-system (logical-system Recover the policies on all logical systems or on a particular logical
name | all) system.
pfe Recover the policies on the Packet Forwarding Engine.
root-logical-system Recover the policies on the root logical system. This is the default
option.
to-zone zone-name Recover the policies to this zone.
tenant tenant-name Recover the policies of a tenant.

597
message displays - error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)>. Please request
the request security policies check to display the security policy sync status.
maintenance
Sample Output
user@host> request security policies resync

Success
request security policies resync logical-system all
user@host> request security policies resync logical-system all

598
Success
Release Information

request security user-identification local-

authorization-table add
IN THIS SECTION
Syntax | 599
Description | 599
Options | 599
Output Fields | 600
Sample Output | 600

599
Syntax
request security user-identification local-authorization-table add user user-name ip-address ip-

address roles [role-name]
Description
This command adds user and role information to the local authentication table. The table is used to
retrieve user and role information for traffic from the specified IP address to enforce a user role firewall.
To add an entry, specify the user name, IP address, and up to 40 roles to be associated with this user.
Subsequent commands for the same user and IP address aggregates any new roles to the existing list.
An authentication entry can contain up to 200 roles.
NOTE: To change the user name of an entry or to remove or change entries in a role list, you
must delete the existing entry and create a new one.
An IP address can be associated with only one user. If a second request is made to add a different user
using the same IP address, the second authentication entry overwrites the existing entry.
Options
user user-name—Specify the name of the user to be added to the table.
ip-address ip-address—Specify the IP address of the user. Either IPv4 or IPv6 addresses are supported.
roles [role-name]—(Optional) Specify the role or list of roles to be associated with the specified user. If
the specified user and IP address already exist, any roles specified in the command are added to the
existing role list.
maintenance
600
Output Fields
When you enter this command, either an entry is added to the local authentication table, or the roles of
an existing entry are aggregated with additional roles.
Sample Output
request security user-identification local-authentication-table add
user@host> request security user-identification local-authentication-table add user user1 ip-

address 192.0.2.1 roles role1
address 203.0.113.2 roles [role2 role3]
address 203.0.113.2 roles role1
Total entries: 2
192.0.2.1 user1 role1
203.0.113.2 user2 role2, role3, role1
Release Information
Command introduced in Junos OS Release 12.1. Command updated in Junos OS Release 12.1X44-D10.

601
request security user-identification local-

authentication-table delete
IN THIS SECTION
Syntax | 601
Description | 601
Options | 601
Output Fields | 602
Sample Output | 602
Syntax
request security user-identification local-authentication-table delete ip-address | user-name
Description
This command removes an entry from the local authentication table. You can identify the entry by IP
address or user-name. To change the user name of an entry or to remove or change entries in a role list,
you must delete the existing entry and create a new one.
Options
ip-address—The IP address of the entry to be deleted.
user-name—The user name of the entry to be deleted. To change the user name of an entry, you must
delete the old entry and create a new one.
602
maintenance
Output Fields
The specified show command verifies the table content before and after an entry has been deleted from
the local authentication table.
Sample Output
command-name

Total entries: 2
Username: user1
Roles: role1
Ip-address: 203.0.113.2
Username: user2
Roles: role2, role3, role1
user@host> request security user-identification local-authentication-table delete

203.0.113.2
Total entries: 1
Username: user1
Roles: role1
603
Release Information

show security alarms
IN THIS SECTION
Syntax | 603
Description | 604
Options | 604
Output Fields | 605
Sample Output | 606
Syntax

<detail>
<alarm-id id-number>
<alarm-type [ types ]>
<newer-than YYYY-MM-DD.HH:MM:SS>
<older-than YYYY-MM-DD.HH:MM:SS>
<process process>
<severity severity>
604
Description
Display the alarms that are active on the device. Run this command when the CLI prompt indicates that
a security alarm has been raised, as shown here:
[1 SECURITY ALARM] user@host#
Options
none Display all active alarms.
detail (Optional) Display detailed output.
alarm-id id-number (Optional) Display the specified alarm.
alarm-type [ types ] (Optional) Display the specified alarm type or a set of types.
You can specify one or more of the following alarm types:
• authentication
• cryptographic-self-test
• decryption-failures
• encryption-failures
• key-generation-self-test
• non-cryptographic-self-test
• policy
• replay-attacks
newer-than YYYY-MM- (Optional) Display active alarms that were raised after the specified date and
DD.HH:MM:SS time.
605
older-than YYYY-MM- (Optional) Display active alarms that were raised before the specified date
DD.HH:MM:SS and time.
process process (Optional) Display active alarms that were raised by the specified system
process.
severity severity (Optional) Display active alarms of the specified severity.
You can specify the following severity levels:
• alert
• crit
• debug
• emerg
• err
• info
• notice
• warning
Output Fields
Table 33 on page 606 lists the output fields for the show security alarms command. Output fields are
listed in the approximate order in which they appear. Field names might be abbreviated (as shown in
parentheses) when no level of output is specified or when the detail keyword is used.
606
Table 33: show security alarms
Field Name Field Description Level of Output
ID Identification number of the alarm. All levels
Alarm time Date and time the alarm was raised.. All levels
Message Information about the alarm, including the alarm type, username, IP All levels
address, and port number.
Process System process (For example, login or sshd) and process identification detail
number associated with the alarm.
Severity Severity level of the alarm. detail
Sample Output
[3 SECURITY ALARMS] user@router> show security alarms
ID Alarm time Message

1 2010-01-19 13:41:36 PST SSHD_LOGIN_FAILED_LIMIT: Specified number of login failures (1)
for user 'user' reached from '203.0.113.2’
show security alarms detail
[3 SECURITY ALARMS] user@router> show security alarms detail
Alarm ID : 1
607
Alarm Type : authentication

Time : 2010-01-19 13:41:36 PST
Message : SSHD_LOGIN_FAILED_LIMIT: Specified number of login failures (1) for user 'user'
reached from '203.0.113.2’
Process : sshd (pid 1414)
Severity : notice
Alarm ID : 2
Time : 2010-01-19 13:41:52 PST
Severity : notice
Alarm ID : 3
Time : 2010-01-19 13:42:13 PST
Severity : notice
show security alarms alarm-id
[3 SECURITY ALARMS] user@router> show security alarms alarm-id 1

show security alarms alarm-type authentication
[3 SECURITY ALARMS] user@router> show security alarms alarm-type authentication

608

show security alarms newer-than <time>
[3 SECURITY ALARMS] user@router> show security alarms newer-than 2010-01-19.13:41:59

show security alarms older-than <time>
[3 SECURITY ALARMS] user@router> show security alarms older-than 2010-01-19.13:41:59

show security alarms process <process>
[3 SECURITY ALARMS] user@router> show security alarms process sshd

show security alarms severity <severity>
[3 SECURITY ALARMS] user@router> show security alarms severity notice

609

Release Information

Example: Generating a Security Alarm in Response to Policy Violations
show security firewall-authentication users address
IN THIS SECTION
Syntax | 610
Description | 610
Options | 610
Output Fields | 611
Sample Output | 612
Sample Output | 612

610
Syntax
show security firewall-authentication users address ip-

address
<node ( node-id | all | local | primary)>
Description
Display information about the users at the specified IP address that are currently authenticated.
Options
• address ip-address—IP address of the authentication source.
• none—Display all the firewall authentication information for users at this IP address.
• node—(Optional) For chassis cluster configurations, display user firewall authentication entries on a
specific node.
• node-id —Identification number of the node. It can be 0 or 1.
• all—Display information about all nodes.
• local—Display information about the local node.
• primary—Display information about the primary node.
view
611
Output Fields
Table 34 on page 611 lists the output fields for the show security firewall-authentication users address
command. Output fields are listed in the approximate order in which they appear.
Table 34: show security firewall-authentication users address Output Fields
Field Name Field Description
Username User ID.
Source IP IP address of the authentication source.
Authentication state Status of authentication (success or failure).
Authentication method Path chosen for authentication.
Access time remaining Duration for which the connection exists.
Lsys The logical system where the traffic was received.
Source zone User traffic received from the zone.
Destination zone User traffic destined to the zone.
Policy index Identification number of the policy.
Policy name Name of the policy.
Access profile Name of profile used for authentication.
Interface Name Name of the interface.
Bytes sent by this user Number of bytes sent by the user.

612
Table 34: show security firewall-authentication users address Output Fields (Continued)
Bytes received by this user Number of bytes received by the user.
Client-groups Name of the client group.
Sample Output
show security firewall-authentication users address 192.0.2.9
user@host>show security firewall-authentication users address 192.0.2.9

Username: hello
Source IP: 192.0.2.9
Authentication state: Success
Authentication method: Pass-through using Telnet
Access time remaining: 0
Source zone: z2
Destination zone: z1
Policy index: 5
Access profile: profile1
Interface Name: ge-0/0/2.0
Bytes sent by this user: 0
Bytes received by this user: 0
Client-groups: my-group1-example, my-group2-example
Sample Output
show security firewall-authentication users address 192.0.2.9 node local
user@host> show security firewall-authentication users address 192.0.2.9 node local

node0:
--------------------------------------------------------------------------
613
Username: local1
Source IP: 192.0.2.9
Authentication method: Pass-through using Telnet
Age: 2
Source zone: z1
Destination zone: z2
Policy name: POL1
Access profile: p1
Interface Name: reth1.0
Bytes sent by this user: 614
Bytes received by this user: 1880
show security firewall-authentication users address 198.51.100.29
user@host> show security firewall-authentication users address 198.51.100.29

Username: hello
Source IP: 198.51.100.29/24
Authentication method: User-firewall
Age: 0
Lsys: root-logical-system
Source zone: N/A
Destination zone: N/A
Access profile: test
Release Information
Command introduced in Junos OS Release 8.5. The node options added in Junos OS Release 9.0.

614
show security firewall-authentication users auth-

type
IN THIS SECTION
Syntax | 614
Description | 614
Options | 614
Output Fields | 615
Sample Output | 616
Syntax
show security firewall-authentication users auth-type [user-firewall | pass-through | web-

authentication]
Description
Display statistics about the users authenticated by the selected method.
Options
• user-firewall—Lists all users authenticated for user firewall.
• pass-through—Lists all users authenticated by the pass-through method.
• web-authentication—Lists all users authenticated by the user authentication method.

615
view
Output Fields
Table 35 on page 615 lists the output fields for the show security firewall-authentication users auth-type
Table 35: show security firewall-authentication users auth-type Output Fields
Total users in table Total number of users authenticated by this method.
Id The ID assigned to the entry.
Source IP The source IP address of the traffic.
Src zone The source zone of the traffic.
Dst zone The destination zone of the traffic.
Profile The profile used to authenticate the used.
Age The length of time since authentication.
Status The status of the authentication.
User The username associated with the traffic.

616
Sample Output
show security firewall-authentication users auth-type user-firewall
user@host> show security firewall-authentication users auth-type user-firewall

User-firewall authentication data:
Total users in table: 2
Id Source Ip Src zone Dst zone Profile Age Status User
1 10.208.16.1 N/A N/A test 0 Success jasonliu
2 10.208.16.6 N/A N/A test6 0 Failed jason
show security firewall-authentication users auth-type pass-through
user@host> show security firewall-authentication users auth-type pass-through

Pass-through firewall authentication data:
1 10.208.16.2 zone1 zone2 test2 0 Success jasonliu2
show security firewall-authentication users auth-type pass-through
user@host> show security firewall-authentication users auth-type web-authentication

Web firewall authentication data:
1 10.208.16.3 N/A N/A test3 0 Success jasonliu3
Release Information
Command introduced in Junos OS Release 12.1X45-D10

617
show security flow session application
IN THIS SECTION
Syntax | 617
Description | 617
Options | 617
Output Fields | 618
Sample Output | 620
Syntax
show security flow session application

application-name [brief | extensive | summary]
Description
This command displays information about each session of the specified application type.
Options
• application-name—Type of application about which to display sessions information. Possible values are:
• dns–Domain Name System
• ftp–File Transfer Protocol
• ignore–Ignore application type

618
• mgcp-ca–Media Gateway Control Protocol with Call Agent
• mgcp-ua–MGCP with User Agent
• pptp–Point-to-Point Tunneling Protocol
• q931–ISDN connection control protocol
• ras–Remote Access Server
• realaudio–RealAudio
• rsh–UNIX remote shell services
• rtsp–Real-Time Streaming Protocol
• sccp–Skinny Client Control Protocol
• sip–Session Initiation Protocol
• sqlnet-v2–Oracle SQLNET
• talk–TALK program
• tftp–Trivial File Transfer Protocol
• brief | extensive | summary–Display the specified level of output.
view
Output Fields
Table 36 on page 619 lists the output fields for the show security flow session application command.
Output fields are listed in the approximate order in which they appear.
619
Table 36: show security flow session application Output Fields
Session ID Number that identifies the session. You can use this ID to get additional
information about the session.
Policy name Policy that permitted the traffic.
Timeout Idle timeout after which the session expires.
In Incoming flow (source and destination IP addresses, application protocol,

interface, session token, route, gateway, tunnel, port sequence, FIN sequence,
FIN state, packets and bytes).
Out Reverse flow (source and destination IP addresses, application protocol,

interface, session token, route, gateway, tunnel, port sequence, FIN sequence,
FIN state, packets and bytes).
Total sessions Total number of sessions.
Status Session status.
Flag Internal flag depicting the state of the session, used for debugging purposes.
Policy name Name and ID of the policy that the first packet of the session matched.
Source NAT pool The name of the source pool where NAT is used.
Application Name of the application.
Maximum timeout Maximum session timeout.
Current timeout Remaining time for the session unless traffic exists in the session.
620
Table 36: show security flow session application Output Fields (Continued)
Session State Session state.
Start time Time when the session was created, offset from the system start time.
Unicast-sessions Number of unicast sessions.
Multicast-sessions Number of multicast sessions.
Failed-sessions Number of failed sessions.
Sessions-in-use Number of sessions in use.
• Valid sessions
• Pending sessions
• Invalidated sessions
• Sessions in other states
Maximum-sessions Number of maximum sessions.
Sample Output
show security flow session application telnet
root> show security flow session application telnet

Total sessions: 0

Total sessions: 0
621
Session ID: 210067547, Policy name: default-policy/2, Timeout: 1796, Valid

In: 203.0.113.2/32781 --> 192.0.2.5/23;tcp, If: ge-0/0/2.0, Pkts: 10, Bytes: 610
Out: 192.0.2.5/23 --> 203.0.113.2/32781;tcp, If: ge-0/0/1.0, Pkts: 9, Bytes: 602
Total sessions: 1
show security flow session application telnet brief
root> show security flow session application telnet brief

Total sessions: 0

Total sessions: 0
Session ID: 210067547, Policy name: default-policy/2, Timeout: 1796, Valid

In: 203.0.113.2/32781 --> 192.0.2.5/23;tcp, If: ge-0/0/2.0, Pkts: 10, Bytes: 610
Out: 192.0.2.5/23 --> 203.0.113.2/32781;tcp, If: ge-0/0/1.0, Pkts: 9, Bytes: 602
Total sessions: 1
show security flow session application telnet extensive
root> show security flow session application telnet extensive

Total sessions: 0

Total sessions: 0
Session ID: 210067547, Status: Normal

Flag: 0x40
Policy name: default-policy/2
Source NAT pool: Null, Application: junos-telnet/10
Maximum timeout: 1800, Current timeout: 1788
622
Session State: Valid

Start time: 670184, Duration: 33
In: 203.0.113.2/32781 --> 192.0.2.5/23;tcp,
Interface: ge-0/0/2.0,
Session token: 0x180, Flag: 0x0x21
Route: 0x60010, Gateway: 203.0.113.100, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 10, Bytes: 610
Out: 192.0.2.5/23 --> 203.0.113.2/32781;tcp,
Interface: ge-0/0/1.0,
Session token: 0x1c0, Flag: 0x0x20
Route: 0x70010, Gateway: 192.0.2.100, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 9, Bytes: 602
Total sessions: 1
show security flow session application telnet summary
root> show security flow session application telnet summary

Valid sessions: 0
Pending sessions: 0
Invalidated sessions: 0
Sessions in other states: 0
Total sessions: 0
Valid sessions: 0
Pending sessions: 0
Total sessions: 0
Valid sessions: 1
Pending sessions: 0
623
Total sessions: 1
Release Information
Filter and view options added in Junos OS Release 10.2.
clear security flow session application
show security match-policies
IN THIS SECTION
Syntax | 623
Description | 624
Options | 624
Output Fields | 626
Sample Output | 629
Syntax
show security match-policies

destination-ip <ip-address>
624
destination-port < port-number>

from-zone <zone-name>
global
logical-system <logical-system-name>
protocol <protocol-name | protocol-number>
result-count <number>
root-logical-system
source-end-user-profile <device-identity-profile-name>
source-identity <role-name>
source-ip <ip-address>
source-port <port-number>
tenant <tenant-name>
to-zone <zone-name>
url category<url-category>
Description
The show security match-policies command allows you to troubleshoot traffic problems using the match
criteria: source port, destination port, source IP address, destination IP address, and protocol. For
example, if your traffic is not passing because either an appropriate policy is not configured or the match
criteria is incorrect, then the show security match-policies command allows you to work offline and identify
where the problem actually exists. It uses the search engine to identify the problem and thus enables
you to use the appropriate match policy for the traffic.
The result-count option specifies how many policies to display. The first enabled policy in the list is the
policy that is applied to all matching traffic. Other policies below it are “shadowed” by the first and are
never encountered by matching traffic.
NOTE: The show security match-policies command is applicable only to security policies; IDP
policies are not supported.
Options
• destination-ip destination-ip—Displays the destination IP address of the traffic.
• destination-port destination-port–Displays the destination port number of the traffic. Range is 1

through 65,535.
625
• from-zone zone-name—Displays the name or ID of the source zone of the traffic.
• global—Displays information about global policies.
• logical-system—Displays the logical system name.
• protocol protocol-name | protocol-number–Displays the protocol name or numeric value of the traffic.
• ah or 51
• egp or 8
• esp or 50
• gre or 47
• icmp or 1
• igmp or 2
• igp or 9
• ipip or 94
• ipv6 or 41
• ospf or 89
• pgm or 113
• pim or 103
• rdp or 27
• rsvp or 46
• sctp or 132
• tcp or 6
• udp or 17
• vrrp or 112
• result-count number—(Optional) Displays the number of policy matches. Valid range is from 1 through
16. The default value is 1.
• root-logical-system—Displays root logical system as default.

626
• source-end-user-profile device-identity-profile-name—(Optional) Displays the device identity profile

that specifies characteristics that can apply to one or more devices.
• source-identity role-name—(Optional) Displays the source identity of the traffic determined by the user
role.
• source-ip source-ip—Displays the source IP address of the traffic.
• source-port source-port—Displays the source port number of the traffic. Range is 1 through 65,535.
• tenant—Displays the name of the tenant system.
• to-zone zone-name—Displays the name or ID of the destination zone of the traffic.
view
Output Fields
Table 37 on page 626 lists the output fields for the show security match-policies command. Output fields
are listed in the approximate order in which they appear.
Table 37: show security match-policies Output Fields
Policy Name of the applicable policy.

627
Table 37: show security match-policies Output Fields (Continued)
Action or Action-type The action to be taken for traffic that matches the policy’s match criteria.
Actions include the following:
• permit
• firewall-authentication
• tunnel ipsec-vpn vpn-name
• pair-policy pair-policy-name
• deny
• reject
State Status of the policy:
• enabled: The policy can be used in the policy lookup process, which
determines access rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and
therefore it is not available for access control.
Index An internal number associated with the policy.
Sequence number Number of the policy within a given context. For example, three policies that
are applicable in a from-zoneA-to-zoneB context might be ordered with
sequence numbers 1, 2, and 3. Also, in a from-zoneC-to-zoneD context, four
policies might have sequence numbers 1, 2, 3, and 4.
From zone Name of the source zone.
To zone Name of the destination zone.
Source addresses The names and corresponding IP addresses of the source addresses for a
policy. Address sets are resolved to their individual address name-IP address
pairs.
628
Table 37: show security match-policies Output Fields (Continued)
Destination addresses The names and corresponding IP addresses of the destination addresses (or
address sets) for a policy as entered in the destination zone’s address book. A
packet’s destination address must match one of these addresses for the policy
to apply to it.
Application Name of a preconfigured or custom application, or any if no application is

specified.
IP protocol Numeric value for the IP protocol used by the application, such as 6 for TCP or
1 for ICMP.
ALG If an ALG is associated with the session, the name of the ALG. Otherwise, 0.
Inactivity timeout Elapsed time without activity after which the application is terminated.
Source-port range Range of matching source ports defined in the policy.
Destination-port range Range of matching destination ports defined in the policy.
Source identities One or more user roles defined in the matching policy.
global Display information about global policies.
device-identity-profile-name Device identity profile that specifies characteristics that can apply to one or
more devices.
629
Sample Output
Example 1: show security match-policies
user@host> show security match-policies from-zone z1 to-zone z2 source-ip 10.10.10.1 destination-

ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
Sequence number: 1
From zone: z1, To zone: z2
Source addresses:
a2: 198.51.100.0/24
a3: 10.10.10.1/32
d2: 203.0.113.0/24
d3: 192.0.2.1/32
Example 2: show security match policies ... result-count
user@host> show security match-policies from-zone zone-A to-zone zone-B source-ip 10.10.10.1
destination-ip 192.0.2.5 source_port 1004 destination_port 80 protocol tcp result_count 5
Sequence number: 1
Source addresses:
sa1: 10.10.0.0/16
da5: 192.0.2.0/24
Application: any
Policy: p15, action-type: deny, State: enabled, Index: 18

Sequence number: 15
Source addresses:
630
sa11: 10.10.10.1/32
da15: 192.0.2.5/32
Application: any
Example 3: show security match policies ... source-identity
user@host> show security match-policies from-zone untrust to-zone trust source-ip 10.10.10.1
destination-ip 192.0.2.1 destination_port 21 protocol 6 source-port 1234 source-identity role1
Sequence number: 1
Source addresses:
a1: 10.0.0.0/8
d1: 192.0.2.0/24
Source identities: role1
Example 4: show security match policies ... global
user@host> show security match-policies global source-ip 10.10.10.1 destination-ip 192.0.2.5

source_port 1004 destination_port 80 protocol tcp result_count 5
Policy: gp1, action-type: permit, State: enabled, Index: 6, Scope Policy: 0
Policy Type: Configured, global
Sequence number: 1
From zones:
Any
To zones:
Any
Source addresses:
631
Application: any
show security match-policies tenant TN1 from-zone trust to-zone untrust source-ip
10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp
user@host> show security match-policies tenant TN1 from-zone trust to-zone untrust source-ip
10.10.10.1 destination-ip 192.0.2.1 source-port 1 destination-port 21 protocol tcp

Sequence number: 1
Source addresses:
a2: 198.51.100.0/24
a3: 10.10.10.1/32
d2: 203.0.113.0/24
d3: 192.0.2.1/32
show security match-policies from-zone client to-zone svr source-ip 10.1.1.1 source-port 88
destination-ip 10.2.2.2 destination-port 80 protocol tcp url-category Enhanced_Games
user@host> show security match-policies from-zone client to-zone svr source-ip 10.1.1.1 source-
port 88 destination-ip 10.2.2.2 destination-port 80 protocol tcp url-category Enhanced_Games

0
632
Sequence number: 1
From zone: client, To zone: server
Source vrf group:
any
Destination vrf group:
any
Source addresses:
Application: any
Destination ports: [0-0]
Url-category:
Enhanced_Sex: 234881056
Enhanced_Games: 234881037
Intrusion Detection and Prevention: disabled
Unified Access Control: disabled
Unified Threat Management: enabled
Release Information
Command updated in Junos OS Release 10.4.
Command updated in Junos OS Release 12.1.
Command updated to include optional from-zone and to-zone global match options in Junos OS Release
12.1X47-D10.
The tenant option is introduced in Junos OS Release 18.3R1.
The url category option is introduced in Junos OS Release 20.2R1.

633

show security policies
IN THIS SECTION
Syntax | 633
Description | 634
Options | 634
Output Fields | 635
Sample Output | 641
Syntax

<all-logical-systems-tenants>
<checksum>
<count>
<detail>
<global>
<hit-count>
<information>
<logical-system logical-system-name>
<policy-name policy-name>
634
<service-set>
<start>
<to-zone zone-name>
<unknown-source-identity>
<zone-context>
Description
Displays a summary of all security policies configured on the device. If a particular policy is specified,
display information specific to that policy. The existing show commands for displaying the policies
configured with multiple tenant support are enhanced. A security policy controls the traffic flow from
one zone to another zone. The security policies allow you to deny, permit, reject (deny and send a TCP
RST or ICMP port unreachable message to the source host), encrypt and decrypt, authenticate,
prioritize, schedule, filter, and monitor the traffic attempting to cross from one security zone to another.
Options
• all-logical-systems-tenants—Displays all multitenancy systems.
• checksum—Displays the policy information checksum.
• count—Displays the number of policies to show. Range is 1 through 65,535.
• detail—(Optional) Displays a detailed view of all of the policies configured on the device.
• from-zone—Displays the policy information matching the given source zone.
• global—(Optional) Displays the policy information about global policies.
• hit-count—Displays the policies hit count.
• information—Displays the policy information.
• policy-name—(Optional) Displays the policy information matching the given policy name.
• service-set—Displays the name of the service set.

635
• start—Displays the policies from a given position. Range is 1 through 65,535.
• to-zone—Displays the policy information matching the given destination zone.
• unknown-source-identity—Displays the unknown-source-identity of a policy.
• zone-context—Displays the count of policies in each context (from-zone and to-zone).
view
Output Fields
Table 38 on page 635 lists the output fields for the show security policies command. Output fields are
listed in the approximate order in which they appear.
Table 38: show security policies Output Fields
From zone Name of the source zone.
To zone Name of the destination zone.
Policy-name Name of the applicable policy.
Description Description of the applicable policy.

636
Table 38: show security policies Output Fields (Continued)
State Status of the policy:
• enabled: The policy can be used in the policy lookup process, which
determines access rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and
therefore it is not available for access control.
Index Internal number associated with the policy.
Sequence number Number of the policy within a given context. For example, three policies that
are applicable in a from-zoneA-to-zoneB context might be ordered with
sequence numbers 1, 2, 3. Also, in a from-zoneC-to-zoneD context, four
policies might have sequence numbers 1, 2, 3, 4.
Source addresses For standard display mode, the names of the source addresses for a policy.
Address sets are resolved to their individual names.
For detail display mode, the names and corresponding IP addresses of the
source addresses for a policy. Address sets are resolved to their individual
address name-IP address pairs.
Destination addresses Name of the destination address (or address set) as it was entered in the
destination zone’s address book. A packet’s destination address must match
this value for the policy to apply to it.
source-end-user-profile Name of the device identity profile (referred to as end-user-profile in the CLI)
that contains attributes, or characteristics of a device. Specification of the
device identity profile in the source-end-user-profile field is part of the device
identity feature. If a device matches the attributes specified in the profile and
other security policy parameters, then the security policy’s action is applied to
traffic issuing from the device.
Source addresses (excluded) Name of the source address excluded from the policy.
637
Destination addresses Name of the destination address excluded from the policy.
(excluded)
Source identities One or more user roles specified for a policy.
Applications Name of a preconfigured or custom application whose type the packet

matches, as specified at configuration time.
• IP protocol: The Internet protocol used by the application—for example,

TCP, UDP, ICMP.
• ALG: If an ALG is explicitly associated with the policy, the name of the ALG
is displayed. If application-protocol ignore is configured, ignore is
displayed. Otherwise, 0 is displayed.
However, even if this command shows ALG: 0, ALGs might be triggered for
packets destined to well-known ports on which ALGs are listening, unless
ALGs are explicitly disabled or when application-protocol ignore is not
configured for custom applications.
• Inactivity timeout: Elapsed time without activity after which the

application is terminated.
• Source port range: The low-high source port range for the session
application.
Source identity feeds Name of a source identity (user name) added as match criteria
Destination identity feeds Name of a destination identity (user name) added as match criteria
Dynamic Applications Application identification-based Layer 7 dynamic applications.

638
Destination Address Translation Status of the destination address translation traffic:
• drop translated—Drop the packets with translated destination addresses.
• drop untranslated—Drop the packets without translated destination

addresses.
Application Firewall An application firewall includes the following:
• Rule-set—Name of the rule set.
• Rule—Name of the rule.
• Dynamic applications—Name of the applications.
• Dynamic application groups—Name of the application groups.
• Action—The action taken with respect to a packet that matches the

application firewall rule set. Actions include the following:
• permit
• deny
• Default rule—The default rule applied when the identified application is

not specified in any rules of the rule set.
639
Action or Action-type • The action taken for a packet that matches the policy’s tuples. Actions
include the following:
• permit
• feed
• firewall-authentication
• tunnel ipsec-vpn vpn-name
• pair-policy pair-policy-name
• source-nat pool pool-name
• pool-set pool-set-name
• interface
• destination-nat name
• deny
• reject
• services-offload
Session log Session log entry that indicates whether the at-create and at-close flags were
set at configuration time to log session information.
Scheduler name Name of a preconfigured scheduler whose schedule determines when the
policy is active and can be used as a possible match for traffic.
640
Policy statistics • Input bytes—The total number of bytes presented for processing by the
device.
• Initial direction—The number of bytes presented for processing by

the device from the initial direction.
• Reply direction—The number of bytes presented for processing by the

device from the reply direction.
• Output bytes—The total number of bytes actually processed by the device.
• Initial direction—The number of bytes from the initial direction

actually processed by the device.
• Reply direction—The number of bytes from the reply direction actually

processed by the device.
• Input packets—The total number of packets presented for processing by

the device.
• Initial direction—The number of packets presented for processing by

the device from the initial direction.
• Reply direction—The number of packets presented for processing by

the device from the reply direction.
• Output packets—The total number of packets actually processed by the

device.
• Initial direction—The number of packets actually processed by the

device from the initial direction.
• Reply direction—The number of packets actually processed by the

device from the reply direction.
• Session rate—The total number of active and deleted sessions.
• Active sessions—The number of sessions currently present because of

access control lookups that used this policy.
• Session deletions—The number of sessions deleted since system startup.
• Policy lookups—The number of times the policy was accessed to check for
a match.
641
dynapp-redir-profile Displays unified policy redirect profile. See "profile(dynamic-application)" on

page 455.
Per policy TCP Options Configured syn and sequence checks, and the configured TCP MSS value for
the initial direction, the reverse direction or, both.
Feed Feeds details added in the security policy. The supported feeds are:
• add-source-ip-to-feed
• add-destination-ip-to-feed
• add-source-identity-to-feed
• add-destination-identity-to-feed
Sample Output

Policy: p1, State: enabled, Index: 4, Sequence number: 1
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::22/32
sa-4-wc: 203.0.113.1/255.255.0.255
da-1-ipv4: 10.2.2.2/24
da-2-ipv6: 2001:db8:a0b:12f0::8/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
da-4-wc: 192.168.22.11/255.255.0.255
Source identities: role1, role2, role4
642
Applications: any
Action: permit, application services, log, scheduled
Application firewall : my_ruleset1
Policy: p2, State: enabled, Index: 5, Sequence number: 2
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::22/32
da-1-ipv4: 10.2.2.2/24
da-2-ipv6: 2001:db8:a0b:12f0::1/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
Source identities: role1, role4
Applications: any
Action: deny, scheduled
show security policies (Dynamic Applications)
user@host>show security policies

Applications: any
Dynamic Applications: junos:YAHOO
Action: deny, log
Applications: any
Dynamic Applications: junos:web, junos:web:social-networking:facebook,
junos:TFTP, junos:QQ
Action: permit, log
Applications: any
Dynamic Applications: junos:HTTP, junos:SSL
Action: permit, application services, log
643
The following example displays the output with unified policies configured.

Dynamic Applications: junos:GMAIL, junos:FACEBOOK-CHAT
show security policies policy-name p2
user@host> show security policies policy-name p2

From zones: any
To zones: any
Source vrf group: any
Destination vrf group: any
Applications: any
Dynamic Applications: any
Action: permit, application services, feed
show security policies policy-name detail
user@host> show security policies policy-name p2 detail

Policy Type: Configured, global
Sequence number: 1
From zones:
any
To zones:
any
644
Source vrf group:

any
any
Source addresses:
Application: any
any: 0
Feed: add-source-ip-to-feed

Description: The policy p1 is for the sales team
Sequence number: 1
Source addresses:
sa-1-ipv4: 198.51.100.11/24
sa-2-ipv6: 2001:db8:a0b:12f0::1/32
sa-3-ipv6: 2001:db8:a0b:12f0::9/32
sa-4-wc: 203.0.113.1/255.255.0.255
da-1-ipv4: 192.0.2.0/24
da-2-ipv6: 2001:db8:a0b:12f0::1/32
da-3-ipv6: 2001:db8:a0b:12f0::9/32
da-4-wc: 192.168.22.11/255.255.0.255
Source identities:
role1
role2
role4
Application: any
645

Destination Address Translation: drop translated
Application firewall :
Rule-set: my_ruleset1
Rule: rule1
Dynamic Applications: junos:FACEBOOK-ACCESS, junos:YMSG
Dynamic Application groups: junos:web, junos:chat
Action: deny
Default rule: permit
Scheduler name: sch20
Policy statistics:
Input bytes : 18144 545 bps
Initial direction: 9072 272 bps
Reply direction : 9072 272 bps
Output bytes : 18144 545 bps
Input packets : 216 6 pps
Output packets : 216 6 pps
Session rate : 108 3 sps
Active sessions : 93
Session deletions : 15
Policy lookups : 108
show security policies (Services-Offload)

Sequence number: 1
From zone: trust, To zone: trust
Source addresses:
646
Application: any
dynapp-redir-profile: profile1(1)
show security policies (Device Identity)

Policy: dev-id-marketing, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
source-end-user-profile: marketing-profile
Applications: any
Action: permit
show security policies detail

Policy: p1, action-type: permit, services-offload:enabled , State: enabled, Index: 4, Scope
Policy: 0
Sequence number: 1
Source addresses:
Source identities:
647
role1
role2
role4
Application: any
Policy statistics:
Active sessions : 93
Session deletions : 15
Policy lookups : 108
Policy: p2, action-type: permit, services-offload:enabled , State: enabled, Index: 5, Scope
Policy: 0
Sequence number: 1
Source addresses:
Source identities:
role1
role2
role4
Application: any
648

The following example displays the output with unified policies configured.

Sequence number: 1
Source addresses:
649

junos:FACEBOOK-CHAT: 10704
junos:GMAIL: 51
dynapp-redir-profile: profile1(1)
show security policies detail (TCP Options)

node0:
--------------------------------------------------------------------------
Policy:p2, action-type:permit, State: enabled,Index: 4, Scope Policy: 0
Sequence number: 1
Source addresses:
650
IP protocol: tcp, ALG: 0, Inactivity timeout: 0
Dynamic-application: junos:HTTP
show security policies policy-name (Negated Address)

node0:
--------------------------------------------------------------------------
Source addresses(excluded): as1
Destination addresses(excluded): as2
Applications: any
Action: permit
show security policies policy-name detail (Negated Address)

node0:
--------------------------------------------------------------------------
Sequence number: 1
Source addresses(excluded):
ad1(ad): 255.255.255.255/32
ad2(ad): 198.51.100.1/24
ad3(ad): 198.51.100.6 ~ 198.51.100.56
ad4(ad): 192.0.2.8/24
ad5(ad): 198.51.100.99 ~ 198.51.100.199
ad6(ad): 203.0.113.9/24
ad7(ad): 203.0.113.23/24
Destination addresses(excluded):
ad13(ad2): 198.51.100.76/24
ad12(ad2): 198.51.100.88/24
651
ad11(ad2): 192.0.2.23 ~ 192.0.2.66

ad10(ad2): 192.0.2.93
ad9(ad2): 203.0.113.76 ~ 203.0.113.106
ad8(ad2): 203.0.113.199
Application: any
show security policies global
user@host> show security policies global policy-name Pa

node0:
--------------------------------------------------------------------------
Global policies:
Policy: Pa, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1
From zones: any
To zones: any
Source addresses: H0
Destination addresses: H1
Applications: junos-http
Action: permit
show security policies detail tenant
user@host> show security policies detail tenant TN1

Sequence number: 1
Application: junos-ping
ICMP Information: type=255, code=0
652
Application: junos-telnet
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Application: app_udp
IP protocol: udp, ALG: 0, Inactivity timeout: 1800
Application: junos-icmp6-all
ICMP Information: type=255, code=0
Policy statistics:
Active sessions : 0
Session deletions: 0
Policy lookups : 0
show security policies (threat profile feeds)

Source vrf group: any
Destination vrf group: any
653
Applications: any
Source identity feeds: user_feed_1, user_feed_2
Destination identity feeds: user_feed_3, user_feed_4
Action: permit, application services, feed
show security policies detail (threat profile feeds)

Sequence number: 2
Source vrf group:
any
any
Source addresses:
any-ipv4(bob_addrbook_1): 0.0.0.0/0
any-ipv6(bob_addrbook_1): ::/0
any-ipv4(bob_addrbook_1): 0.0.0.0/0
any-ipv6(bob_addrbook_1): ::/0
Application: any
Source identity feeds:
user_feed_1
user_feed_2
Destination identity feeds:
user_feed_3
user_feed_4
Feed: add-source-ip-to-feed
Feed: add-destination-ip-to-feed
Feed: add-source-identity-to-feed
Feed: add-destination-identity-to-feed
654
Release Information
Command modified in Junos OS Release 9.2.
Support for IPv6 addresses is added in Junos OS Release 10.2.
Support for wildcard addresses is added in Junos OS Release 11.1.
Support for global policy and services offloading is added in Junos OS Release 11.4.
Support for source-identities and the Description output field is added in Junos OS Release 12.1.
Support for negated address added in Junos OS Release 12.1X45-D10.
The output fields for Policy Statistics expanded, and the output fields for the global and policy-name
options are expanded to include from-zone and to-zone global match criteria in Junos OS Release
12.1X47-D10.
Support for the initial-tcp-mss and reverse-tcp-mss options is added in Junos OS Release 12.3X48-D20.
Output field and description for source-end-user-profile option is added in Junos OS Release 15.1x49-
D70.
Output field and description for dynamic-applications option is added in Junos OS Release 15.1x49-D100.
Output field and description for dynapp-redir-profile option is added in Junos OS Release 18.2R1.
The <all-logical-systems-tenants> option is introduced in Junos OS Release 18.4R1.
The information option is introduced in Junos OS Release 18.4R1.
The checksum option is introduced in Junos OS Release 18.4R1.

655
show security policies checksum
IN THIS SECTION
Syntax | 655
Description | 655
Options | 656
Sample Output | 657
Syntax
show security policies checksum

Description
Displays the security policy checksum value.
Verifying the checksum helps in validating the security policy sync status between the Routing Engine
and the Packet Forwarding Engine. The checksum value should be the same for the Routing Engine and
the Packet Forwarding Engine. If the checksum value is not same, then the different values indicates that
the security policies on the Routing Engine and the Packet Forwarding Engine are out-of-sync.
656
NOTE: The show security policies checksum command can only be used to ensure if the security
policies are out of sync but cannot confirm if they are in-sync. Use the request security policies
check command to get a list of all polices in-sync and/or out-of-sync.
Use the request security policies resync command to synchronize the configuration of security
policies in the Routing Engine and Packet Forwarding Engine.
Options
logical-system (logical- Displays the security policy checksum value for the security policies
system-name | all) configured on a logical system or on all logical systems.
root-logical-system Displays the security policy checksum value for the security policies
configured on the root logical system. This is the default outcome.
tenant tenant-name Displays the security policy checksum value for the security policies
configured on a tenant.
The checksum value is a 32-character hexadecimal number that is computed for the security policy on
the device.
When the policy configuration are modified and the policies are out of sync, the following error message
displays - error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)>. Please request security
policies check/resync.
657
view
Sample Output
show security policies checksum (RE)
user@host> show security policies checksum

From zone To zone Checksum
trust untrust 0xe0fc5791-d7ec5b89-cbc66724-35d706c
show security policies checksum (PFE)
FLOWD_OCTEON(vty)# show usp policy checksum

trust untrust 0xe0fc5791-d7ec5b89-cbc66724-35d706c
show security policies checksum logical-system all
user@host> show security policies checksum logical-system all

Logical system: LSYS1
lsys1-trust lsys1-untrust 0x7ff147ff-f9df0820-081fb02e-226455e3

lsys2-trust lsys2-untrust 0x4bfd47fa-64fbb3e7-3a9444b5-94dd9db5
658
Release Information

show security policies hit-count
IN THIS SECTION
Syntax | 659
Description | 659
Options | 659
Output Fields | 660
Sample Output | 661
Sample Output | 662
Sample Output | 662
Sample Output | 663
Sample Output | 663
Sample Output | 663
Sample Output | 664
Sample Output | 664

659
Syntax

<ascending>
<descending>
<dynamic-applications>
<greater-than count>
<less-than count>
<logical-system (logical-system-name | all)>
<tenant (tenant-name | all)>
<to-zone zone-name>
<url-categories>
Description
Display the utility rate of security policies by listing the number of times a security policy rule matches
the traffic (number of hits). You can specify the options to list the output in ascending or descending
order. You can specify the range to display security policies with certain number of hits. You can filter
the output by zones, logical or tenant systems, dynamic applications, and URL categories.
When the device is operating in chassis cluster mode, the count displayed is a sum of all the Services
Processing Cards (SPC) hit counts in the cluster setup. The security device retains the count if a Packet
Forwarding Engine (PFE) in a node is in failover mode, but does not reboot. . The device clears the count
if a node reboots and the PFE in the node also reboots. During an in-service software upgrade (ISSU), all
PFEs reboot, therefore all counters are cleared.
Use this command without options to display the number of hits in random order for all security policies
and for all zones.
Options
• ascending—(Optional) Displays the number of hits for security policies in ascending order.
• descending—(Optional) Displays the number of hits for security policies in descending order.
660
• dynamic-applications—(Optional) Displays the number of hits for security policies configured with
dynamic applications.
When you display the policy count for the dynamic applications, the device considers the count for
the final matched application identification. For example, if the traffic’s classification path is:
HTTP:FACEBOOK-ACCESS:FACEBOOK-CHAT, then the count increases only for FACEBOOK-
CHAT.
• from-zone zone-name—(Optional) Displays the number of hits for security policies associated with the
named source zone.
• greater-than count—(Optional) Displays security policies for which the number of hits is greater than
the specified number.
Range: 0 through 4,294,967,295
• less-than count—(Optional) Displays security policies for which the number of hits is less than the
specified number.
Range: 0 through 4,294,967,295
• root-logical-system—Displays the number of hits for security policies configured for a root logical
system.
• tenant—Displays the number of hits for security policies configured for the tenant system.
• to-zone zone-name—(Optional) Displays the number of hits for security policies associated with the
named destination zone.
• url-categories—(Optional) Displays the number of hits for security policies based on the matching URL
categories.
view
Output Fields
"No Link Title" on page 661 lists the output fields for the show security policies hit-count command.
661
show security policies hit-count Output Fields
index Displays the policy sequence number
from-zone Name of the source zone
to-zone Name of the destination zone
name Name of the security policy
policy count Number of hits for each security policy
tenant Displays the name of the tenant system.
Action Policy action - Permit or Deny.

Redirect Number of permitted sessions that are redirected by the policy
Dynamic-applications Details of the dynamic applications.
• Name - Dynamic-application name
• Count-
Number of hits for each dynamic application
url-categories Details of the URL categories.

• Name - URL category name
• Count-
Number of hits for each URL category
Sample Output
user@host> show security policies hit-count

index from zone to zone name policy count
1 untrust vrtrust policy1 40
2 untrust trust policy2 20
662
Number of policy: 3
Sample Output
show security policies hit-count ascending
user@host> show security policies hit-count ascending

Number of policy: 3
Sample Output
show security policies hit-count descending greater-than 70 less-than 100
user@host> show security policies hit-count descending greater-than 70 less-than 100

Number of policy: 3
663
Sample Output
show security policies hit-count from-zone untrust to-zone trust
user@host> show security policies hit-count from-zone untrust to-zone trust

Number of policy: 2
Sample Output
user@host> show security policies hit-count

Index From zone To zone Name Policy count Action
1 junos-global junos-global policy1 5202 Permit
Sample Output
show security policies hit-count detail
user@host> show security policies hit-count detail

Index From zone To zone Name Policy count Action Redirect
1 junos-global junos-global policy1 5202 Permit 0
2 junos-global junos-global policy2 5202 Reject 3
664
Sample Output
show security policies hit-count policy-name policy-name detail url-categories
user@host> show security policies hit-count policy-name policy1 detail url-categories

Index From zone To zone Name Policy count Action Redirects
URL-Categories
Name Count
Enhanced_Information_Technology 1000
Enhanced_Collaboration_Office 2000
Sample Output
show security policies hit-count policy-name policy-name detail dynamic-applications
user@host> show security policies hit-count policy-name policy1 detail dynamic-applications

Index From zone To zone Name Policy count Action Redirect
Dynamic-applications
Name Application Count
Junos:SSH 2234
Junos:HTTP 2502
Junos:TWITTER 529
Release Information
The index output field is added to the show security policies hit-count command to display the number of
sessions redirected in Junos OS Release 18.2R1.

665
The dynamic-applications and url-categories options are introduced in Junos OS Release 21.2R1.

show security policies information
IN THIS SECTION
Syntax | 665
Description | 666
Options | 666
Output Fields | 666
Sample Output | 670
Syntax

666
Description
Displays detailed information about the security policies configured on the device.
NOTE: Dynamic policy counters are only supported in the root logical system.
Options
logical-system Displays detailed information about the security policies configured on a logical
system or on all logical systems.
root-logical- Displays detailed information about the security policies configured on the root
system logical system. This is the default option.
tenant Displays detailed information about the security policies configured on a tenant.
view
Output Fields
Table 39 on page 666 lists the output fields for the show security policies information command. Output
fields are listed in the approximate order in which they appear.
Table 39: show security policies Output Fields
Number of global policies Number of global policies configured on the device.

667
Number of policies with Number of policies with schedulers configured on the device.
scheduler
Number of policies with Number of policies configured with statistics enabled on the device and the
statistics enabled maximum number of policies which can be configured with statistics enabled
on the device.
Number of unified policies Number of unified policies configured on the device.
Number of policy contexts Number of policy contexts configured on the device.
Number of Policies per context Number of policies per context configured on the device and the maximum
number of policies per context that can be configured on the device.
Number of Source addresses per Number of source addresses configured per policy and the maximum number
policy of source addresses configured per policy.
The source address in the match criteria is composed of one or more address
names or address set names in the from-zone.
Number of Destination addresses Number of destination addresses configured per policy and maximum of
per policy destination addresses that can be configured per policy.
The destination address of the match criteria is composed of one or more

address names or address set names in the to-zone.
Number of Applications per Number of applications per policy and the maximum number of applications
policy per policy.
Number of Dynamic applications Number of dynamic applications per policy and the maximum number of
per policy dynamic applications per policy.
Number of Source identities per Number of source identities per policy and the maximum number of source
policy identities per policy.
668
Number of Match source/ Number of source and destination identities feeds per policy matching traffic.
destination identity feeds per
policy
Messages received Number of messages received.
Messages rejected Number of messages rejected.
Add messages received Number of add messages received.
Delete messages received Number of delete messages received.
Clear messages received Number of clear messages received.
Invalid messages received Number of invalid messages received.
Add messages sent to PFE Number of add messages sent from Routing Engine to Packet Forwarding
Engine.
Delete messages sent to PFE Number of delete messages sent from Routing Engine to Packet Forwarding
Engine.
Clear messages sent to PFE Number of clear messages sent from Routing Engine to Packet Forwarding
Engine.
Policy added successfully Number of policies successfully added.
Policy deleted successfully Number of policies successfully deleted.
Policy cleared successfully Number of policies successfully cleared.

669
Policy add failures Number of policies unsuccessfully added.
Policy delete failures Number of policies unsuccessfully deleted.
Policy clear failures Number of policies unsuccessfully cleared.
SSAM send attempted Number of SSAM message attempts sent to Internet Key Exchange Protocol
Daemon (IKED).
SSAM send succeeded Number of SSAM messages sent to IKED.
SSAM send failed Number of SSAM messages unsucessfully sent to IKED.
Policy failures - bad Number of messages with invalid dynamic policy configurations provided.
configuration
Policy failures - bad scope Number of messages with invalid scope policy provided.
policy
Dependent-dynamic-application- Value of the unified policy dependent match flag’s value (Dependent-dynamic-
lookup application-lookup).
Unified-policy-implicit-match Value of the unified policy implicit match flag’s value (Unified-policy-implicit-
match).
670
Sample Output
user@host> show security policies information
Number of policies : 0 / 16000

Number of global policies : 0
Number of policies with scheduler : 0
Number of policies with statistics enabled: 0 / 256
Number of unified policies : 0
Number of policy contexts : 0 / 4096
Number of Policies per context : 0 / 10240
Number of Source addresses per policy : 0 / 4096
Number of Destination addresses per policy : 0 / 4096
Number of Applications per policy : 0 / 3072
Number of Dynamic applications per policy : 0 / 4096
Number of Source identities per policy : 0 / 128
Dynamic policy counters:

Messages received : 0
Messages rejected : 0
Add messages received : 0
Delete messages received : 0
Clear messages received : 0
Invalid messages received : 0
Add messages sent to PFE : 0
Delete messages sent to PFE : 0
Clear messages sent to PFE : 0
Policy added successfully : 0
Policy deleted successfully : 0
Policy cleared successfully : 0
Policy add failures : 0
Policy delete failures : 0
Policy clear failures : 0
SSAM send attempted : 0
SSAM send succeeded : 0
SSAM send failed : 0
Policy failures - bad configuration : 0
Policy failures - bad scope policy : 0
Unified policy status:
671
Dependent-dynamic-application-lookup: disable
Unified-policy-implicit-match: enable
show security policies information logical-system all
user@host> show security policies information logical-system all
Policy utilization counters:

Number of URL Category per policy : 0 / 1024

672

Logical system: lsys1

show security policies information (Threat Profiling)
user@host> show security policies information

Number of policies with statistics enabled : 0 / 1024
673

Number of Match source/destination identity feeds per policy : 4 / 1024

Release Information

674
show security policies unknown-source-identity
IN THIS SECTION
Syntax | 674
Description | 674
Output Fields | 675
Sample Output | 675
Syntax
Description
Display a list of any user or role that is referenced in a policy as a source-identity, but is not yet included
in the role provisioning table.
The role provisioning table is created from the local authentication table, UAC authentication tables, and
firewall authentication tables. The UAC and firewall authentication tables are dynamic and contain only
those users currently authenticated. Because of this, a role can be listed as unknown because no user
associated with the role has authenticated yet. There is no consequence if a role remains unknown.
view
675
Output Fields
Table 40 on page 675 lists the output fields for the show security policies unknown-source-identity
Table 40: show security policies unknown-source-identity Output Fields
From zone Part of the zone pair that identifies the source of the traffic to which a policy
applies. Affected policies are grouped by their zone pair.
To zone Part of the zone pair that identifies the destination of the traffic to which a
policy applies. Affected policies are grouped by their zone pair.
Policy The name of the policy that contains the unknown source identity.
Unknown source identities A list of user names and roles specified in the source-identity field of the
named policy that are unknown.
Sample Output
In the following sample output, policy p1 which controls traffic from the untrust zone to the trust zone
specifies two roles, r1 and r3, that are not yet provisioned. Similarly, policy p2 affecting traffic from the
trust zone to the trust zone also contains two roles that are not provisioned, role1 and abc.
user@host> show security policies unknown-source-identity

Policy: p1
Unknown source identities: r1, r3
Policy: p2
Unknown source identities: role1, abc
676
Release Information
show security policies zone-context
IN THIS SECTION
Syntax | 676
Description | 677
Options | 677
Output Fields | 678
Sample Output | 678
Syntax
show security policies zone-context

application-firewall
count
detail
from-zone <zone-name>
interface
logical-system <logical-system-name>
policy-name
root-logical-system
677
service-set
start
tenant <tenant-name>
to-zone <zone-name>
Description
Displays the security policy that applies the security rules to the transit traffic within a context (from-
zone to to-zone). From the perspective of security policies, traffic enters into one security zone and goes
out on another security zone. This combination of a from-zone and a to-zone is defined as a context. Each
context contains an ordered list of policies. The existing show command for security policies zone-
context is enhanced with tenant support.
Options
application-firewall Displays the information of application-firewall.
count Displays the number of policies to show.
detail Displays the detailed information.
from-zone Displays the policy information matching the given source zone.
interface Displays the name of adaptive services interface.
logical-system Displays the name of the logical system.
policy-name Displays the policy information matching the given policy name.
root-logical-system Displays root logical system as default.
service-set Displays the name of service set.
start Displays the policies from a given position.
tenant Displays the name of the tenant system.

678
to-zone Displays the policy information matching the given destination zone.
view
Output Fields
Table 41 on page 678 lists the output fields for the show security policies zone-context command. Output
Table 41: show security zone-context Output Fields
From zone Name or ID of the source zone of the traffic.
To zone Name or ID of the destination zone of the traffic.
Policy count Number of hits for each security policy.
Tenant Name of the tenant system.
Sample Output
show security policies zone-context tenant TN1
user@host> show security policies zone-context tenant TN1

From zone To zone Policy count
z1 z2 1
z2 z3 1
679
show security policies zone-context tenant all
user@host> show security policies zone-context tenant all

Tenant: TN1
z1 z2 1
Tenant: TN2
z1 z2 1
Release Information

show security policy-report
IN THIS SECTION
Syntax | 680
Description | 680
Options | 680
Sample Output | 682

680
Syntax
show security policy-report

<global>
<report-type report-type>
<to-zone zone-name>
Description
Displays detailed security policy reports.
Optimizing security policies ensure that the policies are efficient. Over time, policies become
disorganised and hence ineffective. You can use the show security policy-report command to notify end
users when you create new policies or change existing policies which adversely affect other security
policies.
Options
from-zone Displays the policy report matching the given source zone.
• Default: any
global Displays the security policy report of the global policies.
report- Displays the type of the policy report.

type
You can configure the following options for report-type:
1-year-not-hit Displays the policy report for policies that have not been hit in the last 1
year.
30d-not-hit Displays the policy report for policies that have not been hit in the last 30
days.
days.
681
days.
consolidation Displays the policy report for policies which can be consolidated.
When two policies share most fields in common and only one of the fields
contains difference, they are eligible for consolidation.
expired Displays the policy report for expired policies.
generalization Displays the policy report for generalized policies.
A policy is generalized when a following policy matches all the packets of

the current policy and the action for each policy is different.
least-hit Displays the policy report for policies with the least hit count.
most-hit Displays the policy report for policies with the most hit count.
no-comments Displays the policy report for policies which have no comments.
no-logging Displays the policy report for policies which do not have any logging
redundant Displays the policy report for redundant policies.
A policy is redundant if there exists a preceding policy within the policy

which performs the same action on the same packets as performed by the
current policy.
scheduler Displays the policy report for policies in which the scheduled has expired/
policies that have an active or inactive schedule.
shadowing Displays the policy report for shadowed policies.
A policy is shadowed when a preceding policy matches all the packets of

the current policy and the action for each policy is different.
unused Displays the policy report for policies which have a hit count value of zero.
• Default: If you don’t configure a specific report-type, then all the reports are displayed.
to-zone Displays the policy report matching the given destination zone.
• Default: any
682
NOTE: SRX series devices only analyze the following fields of a policy for the shadowing,
redundant, generalization, and consolidation reports:
• Source address (Ipv4 only)
• Destination address (Ipv4 only)
• Applications
view
Sample Output
show security policy-report report-type consolidation
user@host> show security policy-report report-type consolidation

Problem: Policy p2 is consolidated with policy p1
Recommendation: Please check if policy p2 and p1
Index: 129
Policy: p2
Source zone: trust
Destination zone: untrust
Source addresses: s_ad2
Destination addresses: d_ad2
Applications: app2
Action: permit
Policy: p1
Source zone: trust
Index: 180
683

Applications
show security policy-report report-type scheduler
user@host> show security policy-report report-type scheduler

Problem: Policy p2 has scheduler
Policy: p2, Index: 129
Source zone: trust
Applications: app2
Action: permit
Scheduler: sch
show security policy-report report-type 1-year-not-hit
user@host> show security policy-report report-type 1-year-not-hit

Problem: Not been hit for one year
Recommendation: Please check if you need to remove policy p2
Policy: p2, Index: 129
Source zone: trust
Applications: app2
Action: permit
Release Information

684
report-skip | 470
show security shadow-policies
IN THIS SECTION
Syntax | 684
Description | 685
Options | 685
Output Fields | 685
Sample Output | 686
Syntax
show security shadow-policies

<global>
<logical-system logical-system-name>
<policy policy-name>
<reverse>
<to-zone zone-name>
685
Description
Displays the shadowing and shadowed policies in a policy list. The output displays the list of all policies
that shadows other policies. The concept of policy shadowing refers to the situation where a policy
higher in the policy list always takes effect before a subsequent policy. Because the policy lookup always
uses the first policy it finds that matches the five-part tuple of the source and destination zone, source
and destination address, and application type, if another policy applies to the same tuple (or a subset of
the tuple), the policy lookup uses the first policy in the list and never reaches the second one. The
existing show command for security shadow-policy is enhanced with tenant support.
Options
• from-zone zone-name—Displays the name or ID of the source zone of the traffic.
• global—Displays the information about global policies.
• logical-system—Displays the name of the logical system.
• policy—Displays the shadow policy information for the given policy.
• reverse—Displays the policies which shadows the given policy.
• to-zone zone-name—Displays the shadow policy information for the given destination zone.
view
Output Fields
Table 42 on page 686 lists the output fields for the show security shadow-policies logical-system command.
686
Table 42: show security shadow-policies logical-system Output Fields
Policies The policies shadowing one or more policies in the policy list.
Shadowed policies The policies shadowed by one or more policies in the policy list.
Sample Output
show security shadow-policies from-zone zone-a to-zone zone-b
root@host> show security shadow-policies from-zone zone-a to-zone zone-b

P1 P3
P1 P4
P2 P5
show security shadow-policies from-zone zone-a to-zone zone-b policy P1
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P1

P1 P3
P1 P4
show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
root@host> show security shadow-policies from-zone zone-a to-zone zone-b policy P4 reverse
P1 P4
687
show security shadow-policies tenant TN1 from-zone trust to-zone untrust
user@host> show security shadow-policies tenant TN1 from-zone trust to-zone untrust
p12 p11
Release Information
The tenant option is added in Junos OS Release 18.3R1.
show security user-identification local-

authentication-table
IN THIS SECTION
Syntax | 688
Description | 688
Output Fields | 688
Sample Output | 689

688
Syntax
show security user-identification local-authentication-table [ ( all [brief | extensive]) |ip-

address ip-address | role role-name | start value | count value | user user-name]
Description
This command displays the content of the local authentication table by IP address.
all (Optional) All entries displayed from the beginning of the table or from the specified
starting entry.
brief (Default) Uses a tabular format and truncates longer entries: username—
displays up to 13 characters, roles—displays up to 32 characters.
extensive (Optional) Displays the full names and all items.
count value (Optional) The total number of entries to display.
ip-address ip- (Optional) The IP address of the entry to display.

address
role role-name (Optional) The role name of the entries to display.
start value (Optional) The first entry to display.
user user-name (Optional) The username of the entry to display.
view
Output Fields
Table 43 on page 689 lists the output fields for the show security user-identification local-authentication-
table command. Output fields are listed in the approximate order in which they appear.
689
Table 43: show security user-identification local-authentication-table Output Fields
Total entries The number of entries in the table.
IP address IP address of the associated user.
NOTE: Only one user can be associated with an IP address.
Username User associated with the specified IP address.
Roles A comma-separated list of all roles associated with this IP address and user.
Sample Output
show security user-identification local-authentication-table all

Total entries: 3
192.0.2.1 user1 role1
203.0.113.2 user1 role2
198.51.100.3 user3 role1, role2
show security user-identification local-authentication-table ip-address
user@host> show security user-identification local-authentication-table ip-address 203.0.113.2

Ip-address: 203.0.113.2
Username: user2
690
show security user-identification local-authentication-table start
user@host> show security user-identification local-authentication-table start 2 count 2

Total entries: 2
Ip-address: 203.0.113.2
Username: user2
Ip-address: 198.51.100.3 Username: user3

Roles: role2, role3
show security user-identification local-authentication-table role
user@host> show security user-identification local-authentication-table role qa3456

Total entries: 3
Ip-address: 203.0.113.2
Username: dev-grp-3
Roles: qa432, qa3456, qa84, qa794
Ip-address: 198.51.100.3
Username: dev-qa
Roles: qa3456, qa3985, qa23
Ip-address: 203.0.113.2
Username: brandall
Roles: qa3456
Release Information

691
show security user-identification role-provision all
IN THIS SECTION
Syntax | 691
Description | 691
Output Fields | 691
Sample Output | 692
Syntax
Description
Display all the available user roles for policy provisioning. The output combines user roles from all
available UITs.
view
Output Fields
Table 44 on page 692 lists the output fields for the show security user-identification role-provision all
692
Table 44: show security user-identification role-provision all Output Fields
Roles A comma-separated list of all user roles available for provisioning in user role
policies. This list combines user roles from both the local authentication table
and any UAC authentication tables that have been configured.
Sample Output
user@host> show security user-identification role-provision all

Roles: role1, role2, role3, role4, role_0_1, role_1_1
Release Information

693
show security user-identification source-identity-

provision all
IN THIS SECTION
Syntax | 693
Description | 693
Output Fields | 694
Sample Output | 694
Syntax
show security user-identification source-identity-provision all
Description
Display the available source identities for policy provisioning. The output combines users and user roles
from all available UITs.
view
694
Output Fields
Table 45 on page 694 lists the output fields for the show security user-identification source-identity-
provision all command. Output fields are listed in the approximate order in which they appear.
Table 45: show security user-identification source-identity-provision all Output Fields
Source identities A comma-separated list of all users and user roles available for policy
provisioning. This list combines users and user roles from both the local
authentication table and any UAC authentication tables that have been
configured.
Sample Output
show security user-identification source-identity-provision all
user@host> show security user-identification source-identity-provision all

Source identities: ariana, ben, guest5, role1, role2, role3, role4, role_0_1, role_1_1,u1, user2
Release Information

695
show security user-identification user-provision all
IN THIS SECTION
Syntax | 695
Description | 695
Output Fields | 695
Sample Output | 696
Syntax
Description
Display the available user names for policy provisioning. The output combines users from all available
UITs.
view
Output Fields
Table 46 on page 696 lists the output fields for the show security user-identification user-provision all
696
Table 46: show security user-identification user-provision all Output Fields
Users A comma-separated list of all users available for policy provisioning. This list
combines users from both the local authentication table and any UAC
authentication tables that have been configured.
Sample Output
user@host> show security user-identification user-provision all

Users: ariana, ben, guest5, u1 user2, ...
Release Information
Command introduced in Release Junos OS 12.1X44-D10.

show security zones
IN THIS SECTION
Syntax | 697
697
Description | 697
Options | 697
Output Fields | 698
Sample Output | 700
Syntax
show security zones

<zone-name>
<all-logical-systems-tenants>
<detail>
<tenant (tenant-name | all)>
<terse>
<type (functional | security)>
Description
This command displays the information about the security zones. You can define a security zone, which
allows you to divide the network into different segments and apply different security options to each
segment.
Options
• none—Displays information about all the security zones configured.
• zone-name—(Optional) Displays information about the specified security zone.

698
• all-logical-systems-tenants—(Optional) Displays the information about the security zone of all logical
systems and tenant systems.
• detail—(Optional) Displays the detail level information about the security zone.
• logical-system logical-system-name—(Optional) Displays the information about the security zones of a

specified logical system.
• logical-system all—(Optional) Displays the information about the security zones of all logical systems.
• root-logical-system—(Optional) Displays the information about the security zones of the root logical
system.
• tenant tenant-name—(Optional) Displays the information about the security zones of a specified tenant
system.
• tenant all—(Optional) Displays the information about the security zones of all tenant systems.
• terse—(Optional) Displays the specified level information about the security zone.
• type functional—(Optional) Displays the information for functional zones.
• type security—(Optional) Displays the information for security zones.
view
Output Fields
Table 47 on page 698 lists the output fields for the show security zones command. Output fields are
Table 47: show security zones Output Fields
Functional zone Name of the functional zone. none

699
Table 47: show security zones Output Fields (Continued)
Security zone Name of the security zone. detail
none
Description Description of the security zone. detail
none
Policy Whether the policy can be configured or not. detail

configurable
none
Interfaces bound Number of interfaces in the zone. detail
none
Interfaces List of the interfaces in the zone. detail
none
Zone Name of the zone. terse
Type Type of the zone. terse
Logical system Name of the logical system. detail
Tenant Name of the tenant system. detail

700
Sample Output
show security zones
user@host> show security zones

Functional zone: management
Description: This is the management zone.
Policy configurable: No
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: Host
Description: This is the host zone.
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
fxp0.0
Security zone: abc
Description: This is the abc zone.
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
Security zone: def
Description: This is the def zone.
Interfaces bound: 1
Interfaces:
ge-0/0/2.0
show security zones abc
user@host> show security zones abc

Security zone: abc
701
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
show security zones all-logical-systems-tenants
user@host> show security zones all-logical-systems-tenants
Security zone: HOST

Interfaces bound: all
Interfaces:
Security zone: junos-host

Interfaces bound: 0
Interfaces:
Security zone: z1
Interfaces bound: 0
Interfaces:
Logical system: TSYS1
Security zone: z3a

Interfaces bound: 0
Interfaces:
Security zone: z3b

702
Interfaces bound: 0
Interfaces:
Security zone: z3c

Interfaces bound: 0
Interfaces:
show security zones abc detail
user@host> show security zones abc detail

Security zone: abc
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
show security zones logical-system LSYS1
user@host> show security zones logical-system LSYS1
Security zone: z1
Interfaces bound: 0
Interfaces:
show security zones logical-system all
user@host> show security zones logical-system all
Security zone: HOST

703

Interfaces:

Interfaces bound: 0
Interfaces:
Security zone: z1
Interfaces bound: 0
Interfaces:
show security zones root-logical-system
user@host> show security zones root-logical-system
Security zone: HOST

Interfaces:

Interfaces bound: 0
Interfaces:
show security zones tenant TSYS1
user@host> show security zones tenant TSYS1
Security zone: z3a

704

Interfaces bound: 0
Interfaces:
Security zone: z3b

Interfaces bound: 0
Interfaces:
Security zone: z3c

Interfaces bound: 0
Interfaces:
show security zone tenant all
user@host> show security zone tenant all
Tenant: TSYS1
Security zone: Host

Interfaces bound: 0
Interfaces:
Security zone: abc

Interfaces bound: 0
Interfaces:xe-0/0/1.0
Security zone: def

Interfaces bound: 1
Interfaces:xe-0/0/3.0
705
show security zones terse
user@host> show security zones terse

Zone Type
my-internal Security
my-external Security
dmz Security
show security zones type security
user@host> show security zones type security
Security zone: HOST

Interfaces:

Interfaces bound: 0
Interfaces:
show security zones TRUST
user@host> show security zones TRUST

Security zone: TRUST
Interfaces bound: 0
Interfaces:
xe-7/0/3.0
unidirectional-session-refreshing: Yes
706
Release Information
tenant option introduced in Junos OS Release 18.3R1.

security-zone
show security zones type
IN THIS SECTION
Syntax | 707
Description | 707
Options | 707
Output Fields | 707
Sample Output | 708
Sample Output | 709
Sample Output | 709
Sample Output | 710

707
Syntax
show security zones type

(functional | security)
<detail | terse>
Description
This command displays information about security zones of the specified type.
Options
• functional—Display functional zones.
• security—Display security zones.
• detail | terse—(Optional) Display the specified level of output.
view
Output Fields
Table 48 on page 708 lists the output fields for the show security zones type command. Output fields are
708
Table 48: show security zones type Output Fields
Security zone Zone name. All levels
Description Description of the security zone. none
detail
Policy Whether the policy can be configured or not. none

configurable
detail
Interfaces bound Number of interfaces in the zone. none
detail
Interfaces List of the interfaces in the zone. none
detail
Zone Name of the zone. All levels
Type Type of the zone. All levels
Sample Output
show security zones type functional
user@host> show security zones type functional

Functional zone: management
Description: management zone
Policy configurable: No
Interfaces bound: 0
709
Interfaces:
Sample Output
show security zones type security
user@host> show security zones type security

Security zone: trust
Description: trust zone
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: untrust
Description: untrust zone
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
Description: junos-host zone
Interfaces bound: 0
Interfaces:
Sample Output
show security zones type security terse
user@host> show security zones type security terse

Zone Type
710
trust Security
untrust Security
junos-host Security
Sample Output
show security zones type security detail
user@host> show security zones type security detail

Security zone: trust
Description: trust zone
Interfaces bound: 1
Interfaces:
ge-0/0/0.0
Security zone: untrust
Description: untrust zone
Interfaces bound: 1
Interfaces:
ge-0/0/1.0
Description: junos-host zone
Interfaces bound: 0
Interfaces:
Release Information
The Description output field added in Junos OS Release 12.1.

711

security-zone
show system services dns dns-proxy
IN THIS SECTION
Syntax | 711
Description | 711
Options | 712
Output Fields | 712
Sample Output | 714
Syntax
show system services dns dns-proxy
Description
Display domain name system (DNS) proxy information. This option is supported on the SRX300,
SRX320, SRX340, SRX345, SRX380, and SRX550M devices.
712
Options
• none—Display DNS proxy statistics information.
• cache—(Optional) Display the DNS proxy cache.
• statistics—(Optional) Display the DNS proxy statistics.
view
Output Fields
Table 49 on page 713 lists the output fields for the show system services dns-proxy command. Output
713
Table 49: show system services dns-proxy
DNS proxy statistics Display information about the DNS proxy.
• Status—State of the proxy server as Enabled or disabled.
• Queries received—Number of DNS queries received by the DNS proxy.
• Responses sent—Number of DNS responses sent by the DNS proxy.
• Queries forwarded—Number of DNS queries forwarded by the DNS proxy.
• Negative responses—Number of negative responses the DNS proxy sent to

the DNS client.
• Retry requests—Number of retries the DNS proxy received from the DNS
client.
• Pending requests—Number of pending queries the DNS proxy has yet to

send the DNS client a response for.
• Server failures—Number of DNS proxy server failures.
Hostname Hostname of the host that has been cached.
IP address IP address of the host.
Time-to-live Length of time before an entry is purged from the DNS cache.
Type Type of DNS Resource Record. For example, A records refer to IPv4 host
addresses.
Class Class of DNS. A parameter used to define a DNS Resource Record. For
example, IN class is used for Internet domain names.
714
Sample Output
show system services dns-proxy statistics
user@host> show system services dns-proxy statistics

DNS proxy statistics :
DNS proxy statistics :
Status : enabled
IPV4 Queries received : 30
IPV6 Queries received : 0
Responses sent : 30
Queries forwarded : 13
Negative responses : 23
Positive responses : 23
Retry requests : 0
Pending requests : 0
Server failures : 0
Interfaces : fe-0/0/0.0, fe-1/0/1.0
show system services dns-proxy cache
user@host>show system services dns-proxy cache

Hostname Time-to-live Type Class IP address/Hostname
device1.example.com 408 A IN 207.17.137.229
a.l.example.com 408 A IN 203.0.113.9
b.l.example.com 408 A IN 198.51.100.9
maps.l.example.com 408 A IN 198.51.100.104
c.l.example.com 408 A IN 198.51.100.91
d.l.example.com 408 A IN 198.51.100.89
e.l.example.com 408 A IN 198.51.100.39
g.l.example.com 408 A IN 198.51.100.69
device8.example.com. 408 A IN 192.0.2.123
mail.example.com. 408 CNAME IN device8.example.com.
715
show system services dns-proxy cache <viewname V1>
user@host>show system services dns-proxy cache <viewname V1>

Hostname Time-to-live Type Class IP address/Hostname
device1.example.com. 495 A IN 198.51.100.123
mail.example.com. 495 CNAME IN device1.example.com.
Release Information

dns-proxy | 364
show system services dynamic-dns
IN THIS SECTION
Syntax | 716
Description | 716
Output Fields | 716
Sample Output | 717

716
Syntax
show system services dynamic-dns
Description
Display information about dynamic DNS clients. This option is supported on the SRX300, SRX320,
SRX340, SRX345, SRX380, and SRX550M devices.
view
Output Fields
Table 50 on page 716 lists the output fields for the show system services dynamic-dns command. Output
Table 50: show system services dynamic-dns
Hostname Hostname of the registered client
Server DDNS server name
Agent Name of the DDNS agent
Last response Status of the last response
Last update Date and time of the last update

717
Table 50: show system services dynamic-dns (Continued)
Interface Name of the interface
Sample Output
show system services dynamic-dns client
user@host> show system services dynamic-dns client

Internal hostname Server Last response
device1.example.com example.org success
device2.example.com. example.org failure
show system services dynamic-dns client detail
user@host>show system services dynamic-dns client detail

Hostname : device1.example.com
Server : example.org
Agent : branch-0.1
Last response: success
Last update : 2006-08-29 04:02:52 PDT
Interface : fe-0/0/0.0
Hostname : device2.example.com
Server : example.org
Agent : Branch-0.1
Last response: failure
Last update : 2006-08-29 04:03:03 PDT
Interface : fe-0/0/0.0
718
Release Information
dynamic-dns | 372

JUNIPER SRX Security-Policies

Uploaded by

Copyright:

Available Formats

JUNIPER SRX Security-Policies

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

JUNIPER SRX Security-Policies

Uploaded by

Copyright:

Available Formats

Junos® OS

Security Policies User Guide for Security

Juniper Networks, Inc.

Junos® OS Security Policies User Guide for Security Devices

YEAR 2000 NOTICE

END USER LICENSE AGREEMENT

Security Policies Overview | 2

Security Zones Overview | 7

Example: Creating Security Zones | 9

Supported System Services for Host Inbound Traffic | 13

Understanding How to Control Inbound Traffic Based on Traffic Types | 14

Example: Controlling Inbound Traffic Based on Traffic Types | 15

Understanding How to Control Inbound Traffic Based on Protocols | 19

Example: Controlling Inbound Traffic Based on Protocols | 20

Example: Configuring the TCP-Reset Parameter | 23

3 Address Books and Address Sets

Understanding Address Books | 26

Understanding Global Address Books | 28

Understanding Address Sets | 29

Limitations of Addresses and Address Sets in a Security Policy | 29

Configuring Addresses and Address Sets | 30

Example: Configuring Address Books and Address Sets | 36

Excluding Addresses from Policies | 44

Example: Excluding Addresses from Policies | 45

4 Security Policy Applications and Application Sets

Security Policy Applications Overview | 54

Security Policy Application Sets Overview | 55

Example: Configuring Security Policy Applications and Application Sets | 55

Understanding Policy Application Timeout Configuration and Lookup | 58

Understanding Policy Application Timeouts Contingencies | 59

Example: Setting a Policy Application Timeout | 59

Predefined Policy Applications | 61

Understanding Internet-Related Predefined Policy Applications | 62

Understanding Microsoft Predefined Policy Applications | 64

Understanding Dynamic Routing Protocols Predefined Policy Applications | 66

Understanding Streaming Video Predefined Policy Applications | 67

Understanding Sun RPC Predefined Policy Applications | 68

Understanding Security and Tunnel Predefined Policy Applications | 69

Understanding IP-Related Predefined Policy Applications | 70

Understanding Instant Messaging Predefined Policy Applications | 70

Understanding Management Predefined Policy Applications | 71

Understanding Mail Predefined Policy Applications | 73

Understanding UNIX Predefined Policy Applications | 74

Understanding Miscellaneous Predefined Policy Applications | 74

Understanding ICMP Predefined Policy Applications | 75

Example: Defining a Custom ICMP Application | 82

Custom Policy Applications | 85

Understanding Custom Policy Applications | 85

Custom Application Mappings | 85

Example: Adding and Modifying Custom Policy Applications | 86

Example: Configuring Custom Policy Application Term Options | 89

Understanding Security Policy Elements | 96

Understanding Security Policy Rules | 97

Understanding Security Policies for Self Traffic | 101

Security Policies Configuration Overview | 102

Best Practices for Defining Policies on SRX Series Devices | 103

Configuring Policies Using the Firewall Wizard | 106

Example: Configuring a Security Policy to Permit or Deny All Traffic | 107

Example: Configuring a Security Policy to Permit or Deny Selected Traffic | 113