Understanding Security Building Blocks - Juniper …...UNDERSTANDING SECURITY BUILDING BLOCKS By the writers and editors of the Juniper Networks TechLibrary Firewalls were one of the

UNDERSTANDING SECURITY BUILDING BLOCKS

By the writers and editors of the Juniper Networks TechLibrary

Firewalls were one of the first network security advances, a device that kept the bad people out of your

network. While the SRX Series of Juniper Networks security devices are common in both small and large

networks, it is amazing how many network engineers don’t know all the security building blocks that

make up that firewall concept. As security moves to the cloud, knowledge of the basic security build-

ing blocks is even more vital as you and your network grow – the concepts will stay the same while the

implementation advances.

Untrust Versus Trust Zones

Understanding Security Building Blocks is your individual briefing on the concepts and technologies of

this new secure world. Gleaned from thousands of pages within the Juniper Networks TechLibrary, this

book represents clear and lucid coverage on how the basic tenets of a secure network work together.

As part of the Juniper Networks Design and Architectural Center mandate, this book brings readers and

engineers together to a common staging area as network security moves from bare-metal firewalls to

secure cloud services.

Network Design and Architecture Center Books

http://www.juniper.net/documentation/en_US/design-and-architecture/index.html





http://www.juniper.net



Firewalls were one of the first network security advances, a device that kept the bad people out of your

network. While the SRX Series of Juniper Networks security devices are common in both small and large

networks, it is amazing how many network engineers don’t know all the security building blocks that

make up that firewall concept. As security moves to the cloud, knowledge of the basic security build-

ing blocks is even more vital as you and your network grow – the concepts will stay the same while the

implementation advances.

Untrust Versus Trust Zones

Understanding Security Building Blocks is your individual briefing on the concepts and technologies of

this new secure world. Gleaned from thousands of pages within the Juniper Networks TechLibrary, this

book represents clear and lucid coverage on how the basic tenets of a secure network work together.

As part of the Juniper Networks Design and Architectural Center mandate, this book brings readers and

engineers together to a common staging area as network security moves from bare-metal firewalls to

secure cloud services.







http://www.juniper.net

UNDERSTANDING SEcURITy bUIlDING blockS

by the writers and editors of the Juniper Networks Techlibrary

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Understanding Security Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Understanding Functional Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Understanding Address Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Security Policies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Security Policy Schedulers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Understanding User Role Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Understanding the User Identification Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Understanding Searching and Sorting Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Understanding Packet Flow Alarms and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Security Policy Applications Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Understanding Predefined Policy Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

NAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Understanding Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Firewall User Authentication for Security Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Appendix: Links and URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

The Network Design and Architecture Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102

4 Understanding Security building blocks

© 2017 by Juniper Networks, Inc. All rights reserved.Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. 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.

Published by Juniper Networks BooksUnderstanding Security Building Blocks is compiled from various articles and documents from the Juniper Networks TechLibrary listed in the Appendix.

¾

Version History: June 2017

2 3 4 5 6 7 8 9 10 overview


5 Glossary

Glossary

AAA

Authentication, authorization, and accounting. Process framework used to stan-dardize the control of access to computer resources, enforcement of policies, audit of usage, and ability to report. Authentication determines who the user is and whether to grant that user access to the network. Authorization determines what the user can do by giving you the ability to limit network services to different users. Accounting tracks the user’s activities and provides an audit trail that can be used for billing for connection time or resources used.

Address book

A collection of addresses and address sets. Junos OS allows you to configure mul-tiple address books. Address books are like components, or building blocks, that are referenced in other configurations such as security policies.

Application firewall

Set of related programs in a network security system that controls the access, input, and output from, to, or by an application. Any of the actions that do not comply with the configured policy of the application firewall are blocked. These firewalls are used to control network traffic and to help prevent distributed denial‐of‐service (DDoS) attacks and other malicious behavior.

Class of service (CoS)

Method of classifying traffic on a packet-by-packet basis using information in the type-of-service (ToS) byte to provide different service levels to different traffic. Enables you to divide traffic into classes and offer various levels of throughput and acceptable packet loss when congestion occurs.

Filter

Process or device that screens packets based on certain characteristics, such as source address, destination address, or protocol, and forwards or discards packets that match the filter. Filters are used to control data packets or local packets.

Functional zone

Used for special purposes, like management interfaces. Currently, only the manage-ment (MGT) zone is supported.

Interface

Physical and logical channels on a router, switch, or security device that define how data is transmitted to and received from lower layers in the protocol stack.

Interface set

A logical group of interfaces that describe the characteristics of set of service VLANs, logical interfaces, customer VLANs, or aggregated Ethernet interfaces. Interface sets establish the set and name the traffic control profiles.


lo0

loopback interface. Logical interface that emulates a physical interface on the security device, but is always available because it is independent of any physical interfaces. When configured with an address, the loopback interface is the default address for the routing platform and any unnumbered interfaces.

Logical interface

On a physical interface, the configuration of one or more units that include all addressing, protocol information, and other logical interface properties that enable the physical interface to function. Also known as subinterface.

NAT

Network Address Translation. Method of concealing a set of host addresses on a private network behind a pool of public addresses. Using NAT allows conservation of registered IP addresses within private networks, simplifies IP address management through a form of transparent routing, and increases network privacy by hiding internal IP addresses from external networks. It can be used as a security measure to protect the host addresses from direct targeting in network attacks. Also known as Network Address Translator.

Schedule object

Object that defines the time interval that a firewall rule is in effect. Use a schedule object in a firewall rule to determine when a device enforces that rule.

Security policy

Set of rules defining access to your network, including permitted services, users, and time periods. Use security policies to control the shape of your network traffic as it passes through the firewall, or to log specific network events.

Security zone

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.

SSL

Secure Sockets Layer. Protocol that encrypts security information using public-pri-vate key technology, which requires a paired private key and authentication certifi-cate, before transmitting data across a network.

Stateful firewall

Type of firewall created by a filter that evaluates the context of connections, permits or denies traffic based on the context, and updates this information dynamically. Context includes IP source and destination addresses, port numbers, TCP sequenc-ing information, and TCP connection flags. The context established in the first packet of a TCP session must match the context contained in all subsequent packets if a session is to remain active.

Trust zone

One of two predefined zones (trust, untrust) that enables packets to be secured from being seen by devices external to your current domain.

7 Glossary

Trusted network

Internal network (for instance, an intranet) or your personal computer. See also untrusted network.

Untrust zone

One of two predefined zones (trust, untrust) that enables packets to be seen by devices external to your current domain.

Untrusted network

External network, such as the Internet. See also trusted network.

Virtualization

Technology that abstracts the physical characteristics of a machine, creating a logical version of it, including creating logical versions of entities such as operating systems and various network resources.

VLAN

virtual local area network. Logical group of network devices that appear to be on the same LAN, regardless of their physical location. VLANs are configured as unique Layer 2 broadcast domains consisting of logical, rather than physical, connections, making them extremely flexible. VLANs allow network administrators to re-seg-ment their networks without physically rearranging the devices or network connec-tions. VLANs span one or more ports on multiple devices.

WebApp Secure

Application that protects websites from would-be attackers, fraud, and theft. It uses deception to detect, track, profile, and block attackers in real time by inserting detection points into a webserver’s output to identify attackers before they do damage. It then tracks detected attackers, profiles their behavior, and deploys countermeasures.


Understanding Security Building Blocks

NoTE The Appendix contains the links and URLs to all the original articles in this book.

Understanding Security Zones

Interfaces act as a doorway through which traffic enters and exits a Juniper Net-works 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.

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

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

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.

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

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

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


On a single device, you can configure multiple security zones and at a minimum, you must define two security zones, basically to protect one area of the network from the other. Default configuration of the branch SRX Series includes two security zones--trust and untrust. The vlan.0 belongs to the trust zone and ge-0/0/0 belongs to the untrust zone.

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 How to control Inbound Traffic

Understanding How to control Inbound Traffic based on Traffic Types

You can 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 configure the device selectively 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.

Understanding How to control Inbound Traffic based on Protocols

Any host-inbound traffic that corresponds to a protocol listed under the host-in-bound 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 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).


Supported System Services

all igmp pim sap

bfd ldp rip vrrp

bgp msdp ripng nhrp

router-discovery dvmrp ospf rsvp

pgm ospf3

Table 1 Supported Inbound System Protocols

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 com-mand. This option will prevent the device from responding to a Neighbor Solicita-tion (NS) from a prefix that 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 remaining in the forwarding-table.

Understanding Functional Zones

A functional zone is used for special purposes, like management interfaces. Cur-rently, 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.

Understanding Address Books

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.

11 Understanding Address books

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 address-ing 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. 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).

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.

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 key-words ipv4-only and ipv6-only, respectively.

Before you can use domain names for address entries, you must configure the security device for DNS services.

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.

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.

13 Understanding 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 ad-dresses, 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. There is a limit to the number of address objects that a policy can reference; the maximum number of address objects per poli-cy is 1024. Starting with Junos OS Release 12.3X48-D15, 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.

For example, if policy p1 references 10 address entries and 10 address sets (which in turn reference 3 address entries), then the number of address objects under this policy is 40 (10 address entries + [10 address sets x 3 address entries] = 40).

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.


Understanding Negated Address Support

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.

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.

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

15 Security Policies overview

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.

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, priori-tize, 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 initial-ization (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 that affects 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, and 550M 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, which is from the trust zone to intrazone trusted zones.

¾ Denies all traffic from the untrust zone to the trust zone.

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.

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

Understanding Security Policy Rules

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

¾ 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 secu-rity 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

The 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 applica-tion. 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 applica-tion 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 specific policies near the top of the list. You should also place IPsec VPN tunnel policies near the top. Place the more general poli-cies, 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:

Any policy configured with the to-zone as a global zone must have a single destina-tion address to indicate that either static NAT or incoming NAT has been configured in the policy.

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

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

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

¾ 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 destina-tion 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-de-faults configuration, so users can 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 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.

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 permit-ted 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 2, for example, if you create a 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 2 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.

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.

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 anyuser@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 anyuser@host# set security policies from-zone trust to-zone untrust set then permituser@host# set security policies from-zone untrust to-zone trust policy deny-all match source-address anyuser@host# set security policies from-zone untrust to-zone trust policy deny-all match destination-address anyuser@host# set security policies from-zone untrust to-zone trust policy deny-all match application anyuser@host# set security policies from-zone untrust to-zone trust policy deny-all then deny

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 untrustuser@host# set security address-book book2 address mail-trust 192.168.1.1/24user@host# set security address-book book2 attach zone trustuser@host# set security policies from-zone trust to-zone untrust policy permit-mail match source-address mail-trustuser@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


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 adminis-trator’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.

best Practices for Defining Policies on SRX Series Devices

A secure network is vital to a business. To secure a network, a network administra-tor 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 match-ing 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 5 provides the policy limitations for SRX1500, SRX4100, SRX4200, 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, some policy limitations are changed. The changed limitations appear in italic font.

Policy limitations

SRX1400 SRX1500 SRX3400 SRX3600

SRX4100 SRX4200 SRX5400 SRX5600 SRX5800

Address objects

1024 1024 1024/4096 1024 1024 1024/4096

Application objects

3072 3072 3072 3072 3072 3072

Security policies

40,000 40,000 40,000 40,000 60,000 80,000

Policy contexts (zone pairs)

4096 4096 4096 4096 4096 8192


Policy limitations

SRX1400 SRX1500 SRX3400 SRX3600


Policies per context

10,000/10,240 10,000 10,000/40,000 10,000 10,000 10,000/80,000

Policies with counting enabled

1024 1024 1024 1024 1024 1024

Table 5 Policy Limitations for SRX Series Devices

NoTE Starting with Junos OS Release 12.3X48-D15, 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.

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 compo-nents 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 memo-ry requirements.

25 Security Policy Schedulers overview

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.

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

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.

When a scheduler times out, the associated policy is deactivated and all sessions associated with the policy are also timed out.

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

¾ Scheduler can have a combination of two time slots (daily and timeslot).

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

27 Understanding User Role Firewalls

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 unau-thenticated 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 2 represents three policies in a user role firewall for the trust to untrust zone pair.

policy name

src-zone

dest-zone

src-IP dest-IP source-identity

application action services

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 –

Table 2 Trust Zone to Untrust Zone Policy Sequence


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 3 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 3 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 employ-ee), and the keyword authenticated-user become data used to match the traffic to the source-identity field of a policy.

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

Table 3 UIT Authentication Details

Policy lookup resumes and compares the match criteria in each policy in Table 2 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 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 4. 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.

policy name

src-zone

dest-zone

src-IP dest-IP source-identity application action services

P1 trust untrust any any unauthenticated- user

http deny –

P2 trust untrust any any mgmt any permit –

P3 trust untrust 198.51.100.3 any employee http deny –

Table 4 Trust Zone to Untrust Zone Policy Sequence

29 Understanding the User Identification Table

When the UIT entries in Table 3 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.

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 secu-rity... commands.

NoTE Usernames and roles in the firewall authentication table are not included in the following displays.

¾ To display all of the roles that are available for provisioning, use the show secu-rity 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 com-mand.

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.

Understanding the User Identification Table

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. These types of UITs are supported – the local authenti-cation table and the firewall authentication table.

¾ Local authentication table – A static UIT created on the SRX Series device either manually or programmatically using CLI commands. All users included in the local authentication table are 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.


¾ Firewall authentication table – A dynamic UIT created on the SRX when user-firewall is specified as the firewall authentication type in a security policy. 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 authentica-tion servers supporting RADIUS, LDAP, or SecureID authentication methods. When this type is specified for firewall authentication, the username and associ-ated groups (roles) from the authentication source are mapped to the IP address and added to the firewall authentication UIT.

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

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

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.

31 Understanding the User Identification Table

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

¾ 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 Roles198.51.100.1 user1 role1203.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 extensiveTotal entries: 3Ip-address: 198.51.100.2Username: user1Roles: role1

Ip-address: 203.0.113.2Username: user1Roles: role2

Ip-address: 192.0.2.3Username: user3Roles: role1, role2

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.

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 hierar-chy 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-useruser@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 authenti-cated 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 re-moved 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.)

Understanding Searching and Sorting Audit Log

An audit administrator analyzes the audit trail, reviews the audit record, and deletes the audit trail for maintenance purposes. The search and sort capability provides an efficient mechanism to the audit administrator for viewing pertinent audit informa-tion. This helps the audit administrator to identify potential security violations and take action against possible security breaches. The audit log can be viewed by all the administrators (such as Audit, Cryptographic, Security, and IDS administrators). An IDS audit log can be viewed only by IDS audit administrator.

The security administrator can configure audit events and set thresholds that could indicate a potential security violation. The device monitors the occurrences of these events and notifies the administrator after an event has occurred or a set threshold has been met.

The audit administrator can search or group the audit log data based on the follow-ing:

¾ Destination subject identity

¾ Source subject identity

¾ Range of date, time, user identities, subject service identifiers, or Transport Layer protocol

¾ Rule identity

¾ User identity

33 Understanding Packet Flow Alarms and Auditing

¾ Network interface

¾ Success of auditable security events

¾ Failure of auditable security events

NoTE The device sends an alarm to the console or the security alarm system when the in-memory audit event log exceeds the limit configured by the security administrator. The device then overwrites the oldest log messages with the new audit event log messages. During system reboot the device does a commit of the existing configuration includ-ing login classes. Therefore, there will be audit log entries for all user-defined classes indicating that they have been modified.

Understanding Packet Flow Alarms and Auditing

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

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


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 applica-tion 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 application, create a custom application.

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

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

35 Security Policy Applications overview

¾ 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, for custom applications, you must link the application to an application 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.

Understanding Policy Application Timeout configuration, lookup, and contingencies

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 appli-cation 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 6.


Protocol Default Timeout (seconds)

TCP 1800

UDP 60

ICMP 60

OSPF 60

Other 1800

Table 6 Protocol-Based Default Timeout

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 exam-ple, 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 20user@host# set applications application test term test protocol udpuser@host# set applications application test term test source-port 1-65535user@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 10user@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.

Understanding Predefined Policy Applications

Understanding Internet-Related Predefined Policy Applications

When you create a policy, you can specify predefined Internet-related applications for the policy.

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

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

67 server

Dynamic Host Configuration Protocol allocates network addresses and delivers configuration parameters from server to hosts.

37 Understanding Predefined Policy Applications

Application Name Port(s) Application Description

DNS 53 Domain Name System translates domain names into IP addresses.

FTP 20 data

21 control

File Transfer Protocol (FTP) allows the sending and receiving of files between machines. You can choose to deny or permit ANY or to selectively permit or deny.

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.

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

Internet Locator Service – Internet Locator Service includes LDAP, User Locator Service, and 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.

WAIS – Wide Area Information Server is a program that finds documents on the Internet.

Table 7 Predefined Applications

Understanding Microsoft Predefined Policy Applications

When you create a policy, you can specify predefined Microsoft applications for the policy.

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


Application Parameter/UUID Description

Junos MS-RPC-EPM 135

e1af8308-5d1f-11c9-91a4-08002b14a0fa

Microsoft remote procedure call (RPC) Endpoint Mapper (EPM) Protocol.

Junos MS-RPC – Any Microsoft remote procedure call (RPC) applications.

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

1a190310-bb9c-11cd-90f8-00aa00466520

Microsoft Exchange Database application.

Junos-MS-RPC-MSEXCHANGE-DIRECTORY

f5cc5a18-4264-101a-8c59-08002b2f8426

f5cc5a7c-4264-101a-8c59-08002b2f8426

f5cc59b4-4264-101a-8c59-08002b2f8426

Microsoft Exchange Directory application.

Junos-MS-RPC-MSEXCHANGE-INFO-STORE

0e4a0156-dd5d-11d2-8c2f-00c04fb6bcde

1453c42c-0fa6-11d2-a910-00c04f990f3b

10f24e8e-0fa6-11d2-a910-00c04f990f3b

1544f5e0-613c-11d1-93df-00c04fd7bd09

Microsoft Exchange Information Store application.

Junos-MS-RPC-TCP – Microsoft Transmission Control Protocol (TCP) application.

Junos-MS-RPC-UDP – Microsoft User Datagram Protocol (UDP) application.

Junos-MS-SQL – Microsoft Structured Query Language (SQL).

Junos-MSN – Microsoft Network Messenger application.

Table 8 Predefined Microsoft Applications

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 9 lists each supported dynamic routing protocol by name, port, and description.

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.

Table 9 Dynamic Routing Protocols

Understanding Streaming Video Predefined Policy Applications

When you create a policy, you can specify predefined streaming video applications for the policy.

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

Application Port Description

H.323 TCP source 1-65535; TCP destination 1720, 1503, 389, 522, 1731

UDP source 1-65535; UDP source 1719

H.323 is a standard approved by the International Telecommunication Union (ITU) that defines how audiovisual conference data is transmitted across networks.

NetMeeting TCP source 1-65535; TCP destination 1720, 1503, 389, 522

UDP source 1719

Microsoft NetMeeting uses TCP to provide teleconferencing (video and audio) applications over the Internet.

Real media TCP source 1-65535; TCP destination 7070

Real Media is streaming video and audio 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 7000-7010

VDOLive is a scalable, video streaming technology.

Table 10 Supported Streaming Video Applications


Understanding Sun RPc Predefined Policy Applications

When you create a policy, you can specify predefined Sun RPC applications for the policy.

Table 11 lists each Sun remote procedure call Application Layer Gateway (RPC ALG) application name, parameters, and full name.

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

100227

Sun RPC Network File System

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

SUN-RPC-PROGRAM-YPBIND

100007 SUN RPC Yellow Page Bind application

Table 11 RPC ALG Applications

Understanding Security and Tunnel Predefined Policy Applications

When you create a policy, you can specify predefined security and tunnel applica-tions for the policy.


Table 12 lists each supported application and gives the default port(s) and a descrip-tion of each entry.


IKE UDP source 1-65535; UDP destination 500

Internet Key Exchange is the protocol that 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.

Table 12 Supported Applications

Understanding IP-Related Predefined Policy Applications

When you create a policy, you can specify predefined IP-related applications for the policy.

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


Any – Any application

TCP-ANY 0-65,535 Any protocol using the TCP

UDP-ANY 0-65,535 Any protocol using the UDP

Table 13 Predefined IP-Related Applications

Understanding Instant Messaging Predefined Policy Applications

When you create a policy, you can specify predefined instant messaging applications for the policy.

Table 14 lists predefined Internet-messaging applications. Each entry includes the name of the application, the default or assigned port, and a description of the application.



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.

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.

Table 14 Predefined Internet-Messaging Applications

Understanding Management Predefined Policy Applications

When you create a policy, you can specify predefined management applications for the policy.

Table 15 lists the predefined management applications. Each entry includes the name of the application, the default or assigned port, and a description of the application.


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.

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 instance)

Microsoft SQL is a proprietary database server tool that allows for 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.

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.

Table 15 Predefined Management Applications

Understanding Mail Predefined Policy Applications

When you create a policy, you can specify predefined mail applications for the policy.

Table 16 lists the predefined mail applications. Each includes the name of the application, the default or assigned port number, and a description of the applica-tion.


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.

Table 16 Predefined Mail Applications

Understanding UNIX Predefined Policy Applications

When you create a policy, you can specify predefined UNIX applications for the policy.


Table 17 lists the predefined UNIX applications. Each entry includes the name of the application, the default or assigned port, and a description of the application.


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.

Table 17 Predefined UNIX Applications

Understanding Miscellaneous Predefined Policy Applications

When you create a policy, you can specify miscellaneous predefined applications for the policy.

Table 18 lists predefined miscellaneous applications. Each entry includes the applica-tion name, default or assigned port, and a description of the application.


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.

LPR 515 listen; 721-731 source range (inclusive)

Line Printer Daemon protocol is a TCP-based protocol used for printing applications.

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 Port) SQL monitor (Microsoft)

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.

Table 18 Predefined Miscellaneous Applications


Understanding the IcMP Predefined Policy Application

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 informa-tion 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 character-istics. Table 19 lists ICMP message names, the corresponding code, type, and description.

IcMP Message Name Type code Description

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

Request

Reply

17 18

0 0

ICMP address mask query is used for systems that need the local subnet mask from a bootstrap server. 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.

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. We recommend denying these messages from the Internet (external) to the trusted (internal) network.

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. We recommend denying these messages 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

Request

Reply

15 16

0 0

ICMP-INFO query messages allow diskless host systems to query the network and self-configure. 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 We recommend denying these messages from the Internet to a trusted network. Permitting ICMP parameter problem error messages allows others to make assumptions about your network.

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. We recommend denying these messages from the Internet to a trusted 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. We recommend denying these messages from the Internet to a trusted 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. We recommend denying these messages from the Internet to a trusted network.



ICMP-REDIRECT-HOST 5 1 ICMP redirect messages indicate datagrams destined for the specified host to be sent along another path.

CMP-REDIRECT-TOS-HOST

5 3 ICMP redirect type of service (TOS) and host error is a type of message.

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 We recommend denying these messages 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. We recommend denying these messages from a trusted network out to the Internet.

ICMP-TIMESTAMP

Request

Reply

13 14

0 0

ICMP-TIMESTAMP query messages provide the mechanism to synchronize time and coordinate time distribution in a large, diverse network.

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

11 1 ICMP fragment echo reassembly time expired error message indicates that the reassembly time was exceeded. We recommend denying these messages.

Traceroute

Forward

Discard

30 30

0 1

Traceroute is a utility to indicate the path to access a specific host. We recommend denying this utility from the Internet (external) to your trusted network (internal).

Table 19 Predefined ICMP Applications


NAT Overview

Network Address Translation (NAT) is a method for modifying or translating network address information in packet headers. Either or both source and destina-tion addresses in a packet may be translated. NAT can include the translation of port numbers as well as IP addresses.

NAT is described in RFC 1631 to solve IP (version 4) address depletion problems. Since then, NAT has been found to be a useful tool for firewalls, traffic redirect, load sharing, network migrations, and so on.

The following types of NAT are supported on Juniper Networks devices:

¾ Static NAT

¾ Destination NAT

¾ Source NAT

NoTE SRX Series devices perform both policy lookup and service lookup based on the translated destination port.

You can use the NAT Wizard to perform basic NAT configuration. To perform more advanced configuration, use the J-Web interface or the CLI.

Understanding NAT Rule Sets and Rules

NAT processing centers on the evaluation of NAT rule sets and rules. A rule set determines the overall direction of the traffic to be processed. For example, a rule set can select traffic from a particular interface or to a specific zone. A rule set can contain multiple rules. Once a rule set is found that matches specific traffic, each rule in the rule set is evaluated for a match. Each rule in the rule set further specifies the traffic to be matched and the action to be taken when traffic matches the rule.

NAT Rule Sets

A rule set specifies a general set of matching conditions for traffic. For static NAT and destination NAT, a rule set specifies one of the following:

¾ Source interface

¾ Source zone

¾ Source routing instance

For source NAT rule sets, you configure both source and destination conditions:

¾ Source interface, zone, or routing instance

¾ Destination interface, zone, or routing instance

It is possible for a packet to match more than one rule set; in this case, the rule set with the more specific match is used. An interface match is considered more specific than a zone match, which is more specific than a routing instance match. If a packet matches both a destination NAT rule set that specifies a source zone and a destina-tion NAT rule set that specifies a source interface, the rule set that specifies the source interface is the more specific match.

49 NAT overview

Source NAT rule set matching is more complex because you specify both source and destination conditions in a source NAT rule set. In the case where a packet matches more than one source NAT rule set, the rule set chosen is based on the following source/destination conditions (in order of priority):

1. Source interface/destination interface

2. Source zone/destination interface

3. Source routing instance/destination interface

4. Source interface/destination zone

5. Source zone/destination zone

6. Source routing instance/destination zone

7. Source interface/destination routing instance

8. Source zone/destination routing instance

9. Source routing instance/destination routing instance

For example, you can configure rule set A, which specifies a source interface and a destination zone, and rule set B, which specifies a source zone and a destination interface. If a packet matches both rule sets, rule set B is the more specific match.

NoTE You cannot specify the same source and destination conditions for source NAT rule sets.

NAT Rules

Once a rule set that matches the traffic has been found, each rule in the rule set is evaluated in order for a match. NAT rules can match on the following packet information:

¾ Source and destination address

¾ Source port (for source and static NAT only)

¾ Destination port

The first rule in the rule set that matches the traffic is used. If a packet matches a rule in a rule set during session establishment, traffic is processed according to the action specified by that rule.

You can use the show security nat source rule and show security nat destina-tion rule and the show security nat static rule commands to view the number of sessions for a specific rule.

Rule Processing

The NAT type determines the order in which NAT rules are processed. During the first packet processing for a flow, NAT rules are applied in the following order:

1. Static NAT rules

2. Destination NAT rules

3. Route lookup


4. Security policy lookup

5. Reverse mapping of static NAT rules

6. Source NAT rules

Figure 3 illustrates the order for NAT rule processing.

Figure 3 NAT Rule Processing

Static NAT and destination NAT rules are processed before route and security policy lookup. Static NAT rules take precedence over destination NAT rules. Reverse mapping of static NAT rules takes place after route and security policy lookup and takes precedence over source NAT rules. Source NAT rules are processed after route and security policy lookup and after reverse mapping of static NAT rules.

The configuration of rules and rule sets is basically the same for each type of NAT – source, destination, or static. But because both destination and static NAT are processed before route lookup, you cannot specify the destination zone, interface or routing instance in the rule set.

NAT Rule capacity

Table 20 provides the NAT rule capacity requirements per device. Platform support depends on the Junos OS release in your installation.

NAT Rule Type SRX100 SRX300 SRX320


SRX5400 SRX5600 SRX5800

Source NAT rule 1024 2048 4096 8192 20480 20480 30720

Destination NAT rule 1024 2048 4096 8192 20480 30720

Static NAT rule 1024 2048 4096 8192 20480 30720

Table 20 Number of Rules on SRX Series Devices

51 NAT overview

The restriction on the number of rules per rule set is a device-wide limitation on how many rules a device can support. This restriction is provided to help you better plan and configure the NAT rules for the device.

For memory consumption, there is no guarantee to support these numbers (maxi-mum source rule or rule set + maximum destination rule or rule set + maximum static rule or rule-set) at the same time for SRX3400, SRX3600, SRX5400, SRX5600, and SRX5800 devices.

Table 21 provides the suggested total number of rules and rule sets for SRX3400, SRX3600, SRX5400, SRX5600, and SRX5800 devices. Platform support depends on the Junos OS release in your installation.

objects SRX3400 SRX3600

SRX5400 SRX5600 SRX5800

Total NAT rule sets per system

20,480 30,720

Total NAT rules per rule set

20,480 30,720

Table 21 Number of Rules and Rule Sets

Understanding Source NAT

Source NAT is the translation of the source IP address of a packet leaving the Juniper Networks device. Source NAT is used to allow hosts with private IP addresses to access a public network.

Source NAT allows connections to be initiated only for outgoing network connec-tions – for example, from a private network to the Internet. Source NAT is com-monly used to perform the following translations:

¾ Translate a single IP address to another address (for example, to provide a single device in a private network with access to the Internet).

¾ Translate a contiguous block of addresses to another block of addresses of the same size.

¾ Translate a contiguous block of addresses to another block of addresses of smaller size.

¾ Translate a contiguous block of addresses to a single IP address or a smaller block of addresses using port translation.

¾ Translate a contiguous block of addresses to the address of the egress interface.

Translation to the address of the egress interface does not require an address pool; all other source NAT translations require configuration of an address pool. One-to-one and many-to-many translations for address blocks of the same size do not require port translation because there is an available address in the pool for every address that would be translated.


If the size of the address pool is smaller than the number of addresses that would be translated, either the total number of concurrent addresses that can be translated is limited by the size of the address pool or port translation must be used. For example, if a block of 253 addresses is translated to an address pool of 10 addresses, a maxi-mum of 10 devices can be connected concurrently unless port translation is used.

The following types of source NAT are supported:

¾ Translation of the original source IP address to the egress interface’s IP address (also called interface NAT). Port address translation is always performed.

¾ Translation of the original source IP address to an IP address from a user-defined address pool without port address translation. The association between the original source IP address to the translated source IP address is dynamic. How-ever, once there is an association, the same association is used for the same original source IP address for new traffic that matches the same NAT rule.

¾ Translation of the original source IP address to an IP address from a user-defined address pool with port address translation. The association between the original source IP address to the translated source IP address is dynamic. Even if an association exists, the same original source IP address may be translated to a different address for new traffic that matches the same NAT rule.

¾ Translation of the original source IP address to an IP address from a user-defined address pool by shifting the IP addresses. This type of translation is one-to-one, static, and without port address translation. If the original source IP address range is larger than the IP address range in the user-defined pool, untranslated packets are dropped.

Understanding central Point Architecture Enhancements for NAT

System session capacity and session ramp-up rate are limited by central point memory capacity and CPU capacity. Starting in Junos OS Release 15.1X49-D30, the central point architecture for NAT has been enhanced to handle higher system session capacity and session ramp-up rate for the SRX5000 line. Hence, the work-load on the central point is reduced to increase the session capacity and to support more sessions to achieve higher connections per second (CPS). The following list describes the enhancements to NAT to improve performance:

¾ The central point architecture no longer supports central point sessions. There-fore, NAT needs to maintain a NAT tracker to track the IP address or port allocation and usage. NAT tracker is a global array for SPU session ID to NAT IP or port mapping that is used to manage NAT resources.

¾ By default, a NAT rule alarm and trap statistics counter update message is sent from the Services Processing Unit (SPU) to the central point at intervals of 1 second instead of updating the statistics based on each session trigger in the central point system.

¾ To support a specific NAT IP address or port allocated such that the 5-tuple hash after NAT is the same as the original 5-tuple hash before NAT, select a NAT port that results in the same hash as the original hash by the specific calculation. Hence, the forwarding session is reduced. When NAT is used, the reverse wing is hashed to a different SPU. A forward session has to be installed to forward reverse traffic to a session SPU. NAT tries to select a port that can be used by the

53 NAT overview

hash algorithm to make the reverse wing be hashed to the same SPU as the initial wing. So, both NAT performance and throughput are improved with this ap-proach.

¾ To improve NAT performance, IP shifting pool (non-PAT pool) management is moved from the central point to the SPU so that all local NAT resources for that pool are managed locally instead of sending the NAT request to the central point. Hence, IP address-shifting NAT pool connections per second and throughput are improved.

Understanding Source NAT Rules

Source NAT rules specify two layers of match conditions:

¾ Traffic direction – Allows you to specify combinations of from interface, from zone, or from routing-instance and to interface, to zone, or to routing-in-stance. You cannot configure the same from and to contexts for different rule sets.

¾ Packet information – Can be source and destination IP addresses or subnets, source port numbers or port ranges, destination port numbers or port ranges, protocols, or applications.

For all ALG traffic, except FTP, we recommend that you not use the source-port rule option. Data session creation can fail if this option is used because the IP address and the source port value, which is a random value, might not match the rule.

In addition, we recommend that you not use the destination-port option or the application option as matching conditions for ALG traffic. If these options are used, translation may fail because the port value in the application payload might not match the port value in the IP address.

If multiple source NAT rules overlap in the match conditions, the most specific rule is chosen. For example, if rules A and B specify the same source and destination IP addresses, but rule A specifies traffic from zone 1 to zone 2 and rule B specifies traffic from zone 1 to interface ge-0/0/0, rule B is used to perform source NAT. An interface match is considered to be more specific than a zone match, which is more specific than a routing instance match.

The actions you can specify for a source NAT rule are:

¾ off – Do not perform source NAT.

¾ pool – Use the specified user-defined address pool to perform source NAT.

¾ interface – Use the egress interface’s IP address to perform source NAT.

Source NAT rules are applied to traffic in the first packet that is processed for the flow or in the fast path for the ALG. Source NAT rules are processed after static NAT rules, destination NAT rules, and reverse mapping of static NAT rules and after route and security policy lookup.


Understanding Source NAT Pools

A NAT pool is a user-defined set of IP addresses that are used for translation. Unlike static NAT, where there is a one-to-one mapping that includes destination IP address translation in one direction and source IP address translation in the reverse direction, with source NAT, you translate the original source IP address to an IP address in the address pool.

For source Network Address Translation (NAT) address pools, specify the follow-ing:

¾ Name of the source NAT address pool.

¾ Up to eight address or address ranges.

NoTE Do not overlap NAT addresses for source NAT, destination NAT, and static NAT within one routing instance.

¾ Routing instance – Routing instance to which the pool belongs (the default is the main inet.0 routing instance).

¾ Port – The Port Address Translation (PAT) for a source pool. By default, PAT is performed with source NAT. If you specify the no-translation option, the number of hosts that the source NAT pool can support is limited to the number of addresses in the pool. If you specify block-allocation, a block of ports is allo-cated for translation, instead of individual ports being allocated. If you specify deterministic, an incoming (source) IP address and port always map to the specific destination address and port block, based on predefined, deterministic NAT algorithm. If you specify port-overloading, you can configure the port overloading capacity in source NAT. If you specify range, you can provide the port number range attached to each address in the pool, and the twin port range for source NAT pools.

¾ Overflow pool (optional) – Packets are dropped if there are no addresses avail-able in the designated source NAT pool. To prevent that from happening when the port no-translation option is configured, you can specify an overflow pool. Once addresses from the original source NAT pool are exhausted, IP addresses and port numbers are allocated from the overflow pool. A user-defined source NAT pool or an egress interface can be used as the overflow pool. (When the overflow pool is used, the pool ID is returned with the address.)

¾ IP address shifting (optional) – A range of original source IP addresses can be mapped to another range of IP addresses, or to a single IP address, by shifting the IP addresses. Specify the host-address-base option with the base address of the original source IP address range.

¾ Address sharing (optional) – Multiple internal IP addresses can be mapped to the same external IP address. This option can be used only when the source NAT pool is configured with no port translation. Specify the address-shared option when a source NAT pool has few external IP addresses available, or only one external IP address. With a many-to-one mapping, use of this option increases NAT resources and improves traffic.

¾ Address pooling (optional) – Address pooling can be configured as paired or no-paired. Specify address-pooling paired for applications that require all sessions associated with one internal IP address to be mapped to the same

55 NAT overview

external IP address for the duration of a session. This differs from the persis-tent-address option, in which the same internal address is translated to the same external address every time. Specify address-pooling no-paired for applications that can be can be assigned IP addresses in a round-robin fashion. If either address-pooling paired or address-pooling no-paired is configured for a source NAT pool with PAT, the persistent address option is disabled. If address-shared is configured on a source NAT pool without PAT, then the persistent-address option is enabled. Both address-shared and address-pooling paired can be configured on the same source NAT pool without PAT.

¾ Pool utilization alarm (optional) – When the raise-threshold option is config-ured for source NAT, an SNMP trap is triggered if the source NAT pool utiliza-tion rises above this threshold. If the optional clear-threshold option is config-ured, an SNMP trap is triggered if the source NAT pool utilization drops below this threshold. If clear-threshold is not configured, it is set by default to 80 percent of the raise-threshold value.

You can use the show security nat resource usage source pool command to view address use in a source NAT pool without PAT, and to view port use in a source NAT pool with PAT.

Understanding Source NAT Pool capacities

Maximum capacities for source pools and IP addresses on SRX300, SRX320, SRX340, SRX345 and SRX650 devices are as follows:

Pool/PAT Maximum Address capacity

SRX300 SRX320

SRX340 SRX345

SRX650

Source NAT pools 1024 2048 1024

IP addresses supporting port translation

1024 2048 1024

PAT port number 64M 64M 64M

Maximum capacities for source pools and IP addresses on SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices are as follows:

Pool/PAT Maximum Address capacity

SRX1400 SRX1500

SRX3400 SRX3600

SRX4100 SRX4200

SRX5400 SRX5600 SRX5800

Source NAT pools 8192 10,240 10,240 12,288

IP addresses supporting port translation

8192 12,288 12,288 1M

PAT port number 256M 384M 384M 384M

NoTE In Release 12.3X48-D40, and in Release 15.1X49-D60 and later releases, you can increase the source NAT port capacity to 2.4G on SRX5400, SRX5600, and SRX5800 devices with next-generation Services Processing Cards (SPCs) using the port-scaling-enlargement option at the [edit security nat source] hierarchy level.


NoTE Platform support depends on the Junos OS release in your installation.

Increasing the total number of IP addresses used for source NAT, either by increasing the number of pools in the configuration and/or by increasing the capacity or IP-addresses per pool, consumes memory needed for port allocation. When source NAT pool and IP address limits are reached, port ranges should be reassigned. That is, the number of ports for each IP address should be decreased when the number of IP addresses and source NAT pools is increased. This ensures NAT does not con-sume too much memory.

For example, in a source NAT pool for SRX5000 devices, when the number of IP addresses supporting port translation reaches the limit of 1M, the total number of PAT ports is 64G, which exceeds the 384M limitation. This is because, by default, each IP address supports 64,512 ports. To ensure that PAT port numbers are within capacity, the port range for each IP needs to be configured to decrease the total number of PAT ports.

Use the range and range twin-port options at the [edit security nat source pool port] hierarchy level to assign a new port range or twin port range for a specific pool. Use the pool-default-port-range and the pool-default-twin-port-range options at the [edit security nat source] hierarchy level to specify the global default port range or twin port range for all source NAT pools.

Configuring port overloading should also be done carefully when source NAT pools are increased.

For a source pool with PAT in range (63,488 through 65,535), two ports are allo-cated at one time for RTP/RTCP applications, such as SIP, H.323, and RTSP. In these scenarios, each IP address supports PAT, occupying 2048 ports (63,488 through 65,535) for ALG module use.

Understanding Persistent Addresses

By default, port address translation is performed with source NAT. However, an original source address may not be translated to the same IP address for different traffic that originates from the same host. The source NAT address-persistent option ensures that the same IP address is assigned from the source NAT pool to a specific host for multiple concurrent sessions.

This option differs from the address-pooling paired option, where the internal address is mapped to an external address within the pool on a first-come, first-served basis, and might be mapped to a different external address for each session.

Understanding Source NAT Pools with Address Pooling

When a host initiates several sessions that match a policy that requires NAT, and is assigned an IP address from a source pool that has port address translation enabled, a different source IP address is used for each session.

Because some applications require the same source IP address for each session, you can use the address-pooling paired feature to enable all sessions associated with one internal IP address to map to the same external IP address for the duration of the sessions. When the sessions end, the mapping between the internal IP address and the external IP address ceases. The next time the host initiates a session, a different IP address from the pool might be assigned to it.

57 NAT overview

This differs from the source NAT address-persistent feature, which keeps the mapping static; the same internal IP address is mapped to the same external IP address every time. It also differs from the address-persistent feature in that address-pooling paired is configured for a specific pool. The address-persistent feature is a global configuration that applies to all source pools.

Understanding Source NAT Pools with Address Shifting

The match conditions for a source NAT rule set do not allow you to specify an address range; only address prefixes may be specified in a rule. When configuring a source NAT pool, you can specify the host-base-address option; this option specifies the IP address where the original source IP address range begins.

The range of original source IP addresses that are translated is determined by the number of addresses in the source NAT pool. For example, if the source NAT pool contains a range of ten IP addresses, then up to ten original source IP addresses can be translated, starting with a specified base address. This type of translation is one-to-one, static, and without port address translation.

The match condition in a source NAT rule may define a larger address range than that specified in the source NAT pool. For example, a match condition might specify an address prefix that contains 256 addresses, but the source NAT pool might contain a range of only a few IP addresses, or only one IP address. A packet’s source IP address can match a source NAT rule, but if the source IP address is not within the address range specified in the source NAT pool, the source IP address is not trans-lated.

Understanding Source NAT Pools with PAT

Using the source pool with Port Address Translation (PAT), Junos OS translates both the source IP address and the port number of the packets. When PAT is used, multiple hosts can share the same IP address.

Junos OS maintains a list of assigned port numbers to distinguish what session belongs to which host. When PAT is enabled, up to 63,488 hosts can share a single IP address. Each source pool can contain multiple IP addresses, multiple IP address ranges, or both. For a source pool with PAT, Junos OS may assign different address-es to a single host for different concurrent sessions, unless the source pool or Junos OS has the persistent address feature or the paired address pooling feature enabled.

For interface source pool and source pool with PAT, range (1024, 65535) is available for port number mapping per IP address. Within range (1024, 63487) one port is allocated at a time, for a total of 62,464 ports. In range (63488, 65535), two ports are allocated at a time for RTP/RTCP applications such as SIP, H.323, and RTSP, for a total of 2,048 ports.

When a host initiates several sessions that match a policy that requires network address translation and is assigned an address from a source pool that has PAT enabled, the device assigns a different source IP address for each session. Such random address assignment can be problematic for services that create multiple sessions that require the same source IP address for each session. For example, it is important to have the same IP address for multiple sessions when using the AOL Instant Message (AIM) client.


To ensure that the router assigns the same IP address from a source pool to a host for multiple concurrent sessions, you can enable a persistent IP address per router. To ensure that the device assigns the same IP address from a source pool to a host for the duration of a single session, you can enable paired address pooling.

Understanding Source NAT Pools Without PAT

When you define a source pool, Junos OS enables PAT by default. To disable PAT, you must specify no port translation when you are defining a source pool.

When using a source pool without PAT, Junos OS performs source Network Address Translation for the IP address without performing PAT for the source port number. For applications that require that a particular source port number remain fixed, you must use source pool without PAT.

The source pool can contain multiple IP addresses, multiple IP address ranges, or both. For source pool without PAT, Junos OS assigns one translated source address to the same host for all its concurrent sessions unless the address-pooling no-paired option is enabled.

The number of hosts that a source NAT pool without PAT can support is limited to the number of addresses in the pool. When you have a pool with a single IP address, only one host can be supported, and traffic from other hosts is blocked because there are no resources available. If a single IP address is configured for a source NAT pool without PAT when NAT resource assignment is not in active-backup mode in a chassis cluster, traffic through node 1 will be blocked.

Pool utilization for each source pool without PAT is computed. You can turn on pool utilization alarm by configuring alarm thresholds. An SNMP trap is triggered every time pool utilization rises above a threshold and goes below a threshold.

NoTE If a static NAT rule is for one-to-one IP translation, avoid dividing the rule into a destination rule and a source rule when source no-pat pool without address sharing is used. If you choose to divide the rule, you will then have to use source pat-pool with single IP or source no-pat pool with multiple IP.

Understanding Source NAT Pools with Shared Address

Source NAT pools with no port address translation perform static, one-to-one mappings from one source IP address to one external IP address. When there is only one external IP address, or very few available in a source no-pat pool , the address-shared option enables you to map many source IP addresses to one external IP address as long as the traffic comes from different source ports.

For example, if there is a source NAT pool with no port translation containing only two IP addresses, IP 1 and IP 2, when a packet arrives from:

1. Source IP 1, port 1, it is translated to IP 1, port 1.

2. Source IP 2, port 2, it is translated to IP 2, port 2.

3. Source IP 3, port 1, it is translated to IP 2, port 1. (It cannot be translated to IP 1 port 1 because that port is already used:

59 NAT overview

¾ However, if another packet arrives from Source IP 3, port 1 for a different destination IP and port, it cannot be translated to IP 1, port 1 or IP 2, port 1 because port 1 is already used for both available IP addresses. The session will fail.

This option increases NAT resources and improves the possibility of setting up successful translated traffic. It cannot be used on source NAT pools with port address translation because address sharing is already their default behavior.

Understanding Destination NAT

Destination NAT is the translation of the destination IP address of a packet entering the Juniper Networks device. Destination NAT is used to redirect traffic destined to a virtual host (identified by the original destination IP address) to the real host (identified by the translated destination IP address).

NoTE When destination NAT is performed, the destination IP address is translated accord-ing to configured destination NAT rules and then security policies are applied.

Destination NAT allows connections to be initiated only for incoming network connections – for example, from the Internet to a private network. Destination NAT is commonly used to perform the following actions:

¾ Translate a single IP address to another address (for example, to allow a device on the Internet to connect to a host on a private network).

¾ Translate a contiguous block of addresses to another block of addresses of the same size (for example, to allow access to a group of servers).

¾ Translate a destination IP address and port to another destination IP address and port (for example, to allow access to multiple services using the same IP address but different ports).

The following types of destination NAT are supported:

¾ Translation of the original destination IP address to an IP address from a user-defined pool. This type of translation does not include Port Address Translation (PAT). If the original destination IP address range is larger than the address range in the user-defined address pool, any untranslated packets are dropped.

¾ Translation of the original destination IP address (and optional port number) to one specific IP address (and port number) from a user-defined pool.

Understanding Destination NAT Address Pools

A NAT pool is a user-defined set of IP addresses that are used for translation. Unlike static NAT, where there is a one-to-one mapping that includes destination IP address translation in one direction and source IP address translation in the reverse direc-tion, with destination NAT, you translate the original destination address to an IP address in the address pool.

For destination NAT address pools, specify the following:

¾ Name of the destination NAT address pool

¾ Destination address or address range


NoTE Do not overlap NAT addresses for source NAT, destination NAT, and static NAT within one routing instance.

¾ Destination port that is used for port forwarding

¾ Routing instance to which the pool belongs – A destination NAT pool that does not specify a specific routing instance will default to the routing instance of the ingress zone.

NoTE You can configure a NAT pool to exist in the default routing instance. Configuration option to specify that a NAT pool exists in the default routing-instance is available. As a result, the NAT pool is reachable from zones in the default routing instance, and from zones in other routing instances.

Understanding Destination NAT Rules

Destination NAT rules specify two layers of match conditions:

¾ Traffic direction – Allows you to specify from interface, from zone, or from routing-instance.

¾ Packet information – Can be source IP addresses, destination IP address or subnet, destination port numbers or port ranges, protocols, or applications.

For ALG traffic, we recommend that you not use the destination-port option or the application option as matching conditions. If these options are used, translation may fail because the port value in the application payload might not match the port value in the IP address.

If multiple destination NAT rules overlap in the match conditions, the most specific rule is chosen. For example, if rules A and B specify the same source and destination IP addresses, but rule A specifies traffic from zone 1 and rule B specifies traffic from interface ge-0/0/0, rule B is used to perform destination NAT. An interface match is considered to be more specific than a zone match, which is more specific than a routing instance match.

The actions you can specify for a destination NAT rule are:

¾ off – Do not perform destination NAT.

¾ pool – Use the specified user-defined address pool to perform destination NAT.

Destination NAT rules are applied to traffic in the first packet that is processed for the flow or in the fast path for the ALG. Destination NAT rules are processed after static NAT rules but before source NAT rules.

Understanding Static NAT

Static NAT defines a one-to-one mapping from one IP subnet to another IP subnet. The mapping includes destination IP address translation in one direction and source IP address translation in the reverse direction. From the NAT device, the original destination address is the virtual host IP address while the mapped-to address is the real host IP address.

61 NAT overview

Static NAT allows connections to be originated from either side of the network, but translation is limited to one-to-one or between blocks of addresses of the same size. For each private address, a public address must be allocated. No address pools are necessary.

Static NAT also supports the following types of translation:

¾ To map multiple IP addresses and specified ranges of ports to a same IP address and different range of ports

¾ To map a specific IP address and port to a different IP address and port

The port address translation (PAT) is also supported by giving static mapping between destination-port (range) and mapped-port (range).

NoTE The original destination address, along with other addresses in source and destina-tion NAT pools, must not overlap within the same routing instance.

In NAT rule lookup, static NAT rules take precedence over destination NAT rules and reverse mapping of static NAT rules take precedence over source NAT rules.

Understanding Static NAT Rules

Static Network Address Translation (NAT) rules specify two layers of match conditions:

¾ Traffic direction – Allows you to specify from interface, from zone, or from routing-instance.

¾ Packet information – Can be source addresses and ports, and destination ad-dresses and ports.

For all ALG traffic, except FTP, we recommend that you not use the static NAT rule options source-address or source-port. Data session creation can fail if these options are used because the IP address and the source port value, which is a random value, might not match the static NAT rule. For FTP ALG traffic, the source-ad-dress option can be used because an IP address can be provided to match the source address of a static NAT rule.

When both source and destination addresses are configured as match conditions for a rule, traffic is matched to both the source address and destination address. Because static NAT is bidirectional, traffic in the opposite direction reverse matches the rule, and the destination address of the traffic is matched to the configured source ad-dress.

If multiple static NAT rules overlap in the match conditions, the most specific rule is chosen. For example, if rules A and B specify the same source and destination IP addresses, but rule A specifies traffic from zone 1 and rule B specifies traffic from interface ge-0/0/0, rule B is used to perform static NAT. An interface match is considered to be more specific than a zone match, which is more specific than a routing instance match.


Because static NAT rules do not support overlapping addresses and ports, they should not be used to map one external IP address to multiple internal IP addresses for ALG traffic. For example, if different sites want to access two different FTP servers, the internal FTP servers should be mapped to two different external IP addresses.

For the static NAT rule action, specify the translated address and (optionally) the routing instance.

In NAT lookup, static NAT rules take precedence over destination NAT rules and reverse mapping of static NAT rules takes precedence over source NAT rules.

Understanding Persistent NAT and NAT64

Persistent NAT allows applications to use the Session Traversal Utilities for NAT (STUN) protocol when passing through NAT firewalls. Persistent NAT ensures that all requests from the same internal transport address (internal IP address and port) are mapped to the same reflexive transport address (the public IP address and port created by the NAT device closest to the STUN server).

NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice versa that allows IPv6 clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. It is an enhancement of Network Address Translation-Protocol Translation (NAT-PT).

NAT64 supports the following:

¾ Endpoint-independent mappings

¾ Endpoint-independent filtering and address-dependent filtering

NoTE The mapping and filtering behaviors of NAT64 and persistent NAT are identical.

The following types of persistent NAT can be configured on the Juniper Networks device:

¾ Any remote host – All requests from a specific internal IP address and port are mapped to the same reflexive transport address. Any external host can send a packet to the internal host by sending the packet to the reflexive transport address.

¾ Target host – All requests from a specific internal IP address and port are mapped to the same reflexive transport address. An external host can send a packet to an internal host by sending the packet to the reflexive transport address. The internal host must have previously sent a packet to the external host’s IP address.

¾ Target host port – All requests from a specific internal IP address and port are mapped to the same reflexive transport address. An external host can send a packet to an internal host by sending the packet to the reflexive transport ad-dress. The internal host must have previously sent a packet to the external host’s IP address and port.

NoTE The target-host-port configuration is not supported for NAT64 when configured with IPv6 address.

63 NAT overview

You configure any of the persistent NAT types with source NAT rules. The source NAT rule action can use a source NAT pool (with or without port translation) or an egress interface. Persistent NAT is not applicable for destination NAT, because persistent NAT bindings are based on outgoing sessions from internal to external.

NoTE Port overloading is used in Junos OS only for normal interface NAT traffic. Persis-tent NAT does not support port overloading, and you must explicitly disable port overloading with one of the following options at the [edit security nat source] hierarchy level:

¾ port-overloading off

¾ port-overloading-factor 1

To configure security policies to permit or deny persistent NAT traffic, you can use two new predefined services – junos-stun and junos-persistent-nat.

NoTE Persistent NAT is different from the persistent address. The persistent address feature applies to address mappings for source NAT pools configured on the device. The persistent NAT feature applies to address mappings on an external NAT device, and is configured for a specific source NAT pool or egress interface. Also, persistent NAT is intended for use with STUN client/server applications.

Understanding Session Traversal Utilities for NAT (STUN) Protocol

Many video and voice applications do not work properly in a NAT environment. For example, Session Initiation Protocol (SIP), used with VoIP, encodes IP addresses and port numbers within application data. If a NAT firewall exists between the requestor and receiver, the translation of the IP address and port number in the data invalidates the information.

Also, a NAT firewall does not maintain a pinhole for incoming SIP messages. This forces the SIP application to either constantly refresh the pinhole with SIP messages or use an ALG to track registration, a function that may or may not be supported by the gateway device.

The Session Traversal Utilities for NAT (STUN) protocol, first defined in RFC 3489, Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) and then later in RFC 5389, Session Traversal Utilities for NAT, is a simple client/server protocol. A STUN client sends requests to a STUN server, which returns responses to the client. A STUN client is usually part of an application that requires a public IP address and/or port. STUN clients can reside in an end system such as a PC or in a network server whereas STUN servers are usually attached to the public Internet.

NoTE Both the STUN client and STUN server must be provided by the application. Juniper Networks does not provide a STUN client or server.

The STUN protocol allows a client to:

¾ Discover whether the application is behind a NAT firewall.

¾ Determine the type of NAT binding being used.


¾ Learn the reflexive transport address, which is the IP address and port binding allocated by NAT device closest to the STUN server. (There may be multiple levels of NAT between the STUN client and the STUN server.)

The client application can use the IP address binding information within protocols such as SIP and H.323.

Understanding NAT64 IPv6 Prefix to IPv4 Address-Persistent Translation

The NAT64 mechanism enables IPv6 clients to contact IPv4 servers by translating IPv6 addresses to IPv4 addresses (and vice versa). However, some IPv4 applications and services cannot work correctly over IPv6-only networks with standard NAT64 in a dual-translation scenario, such as 464XLAT. In those scenarios, address-persis-tent translation is required.

Figure 4 illustrates the 464XLAT architecture, whereby IPv4 packets are translated to IPv6 packets on the customer-side translator (CLAT), then go across the IPv6-only network, and are translated back to IPv4 packets on the provider-side translator (PLAT) to access global IPv4-only content in the core network. This architecture uses a combination of stateless translation on the CLAT and stateful translation on the PLAT.

Figure 4 464XLAT Architecture

When an SRX Series device functions as a PLAT, it is responsible for keeping the sticky mapping relationship between one specific IPv6 prefix and one translated IPv4 address. The SRX Series device treats the IPv6 prefix as a single user. This mapping is accomplished by configuring the specific IPv6 prefix length in an IPv4 source NAT pool using the address-persistent feature.

Figure 5 illustrates a NAT rule configured in the CLAT, which translates an IPv4 address to an IPv6 address with an address-persistent prefix. With stateless NAT46 translation on the CLAT and stateful NAT64 translation on the PLAT, the traffic from IPv4 host 192.168.1.2 reaches the global server 198.51.100.1 over an IPv6-only network.

65 NAT overview

Figure 5 NAT64 Translation on the PLAT (SRX Series Device)

Table 22 lists other NAT features and their compatibility with the address-persistent feature.

Feature compatible

PAT pools IPv4 NAT IPv4 to IPv6 No

NAT IPv6 to IPv4 Yes

IPv6 NAT IPv4 to IPv6 No

NAT IPv6 to IPv4 No

Non-PAT pools No

Port-overloading Yes

Persistent NAT in PAT pool Yes

Port block allocation Yes

Deterministic NAT No

Address pooling paired No

ALG (Existing ALG NAT translations , such as FTP/PPTP/RTSP/DNS/SIP from native IPv6 clients.)

Yes

Table 22 NAT Feature Compatibility with the Address Persistent Feature

Persistent NAT Hairpinning overview

When traffic is sent between two hosts, the source host of the traffic may only know the destination host by its public IP address. In reality, the destination host may be in the same private address space as the source host. Hairpinning is the process of returning the traffic in the direction from where it came from as a way to get it to its destination host in a private subnetwork.

Generally, a source host in a subnetwork may not recognize that the traffic is intended for a destination host within the same subnetwork, because it identifies the destination host only by its public IP address. The NAT analyzes the IP packets and routes the packet back to the correct host.

NAT hairpinning support is required if two hosts on the internal network want to communicate with each other by using a binding on the NAT device. In this case, the NAT device receives a packet from the internal network and forwards it back to the internal network. If hairpinning is not supported, forwarding the packet will fail and it will be dropped.


NoTE NAT hairpinning behavior is not supported by target host persistent NAT and target host port persistent NAT. Only any remote host persistent NAT supports hairpin-ning behavior.

To allow hairpinning, you must configure a security policy to allow traffic between endpoints in the same zone. Actually the two endpoints can be located in two different zones as well as long as either of the two hosts can only see the public address of the peer.

Persistent NAT hairpinning applies only to any remote host persistent NAT type.

IPv6 NAT overview

IPv6 has a vastly larger address space than the impending exhausted IPv4 address space. IPv4 has been extended using techniques such as Network Address Transla-tion (NAT), which allows for ranges of private addresses to be represented by a single public address, and temporary address assignment. There are a lot of tech-nologies to provide the transition mechanism for the legacy IPv4 host to keep the connection to the Internet. IPv6 NAT provides address translation between IPv4 and IPv6 addressed network devices. It also provides address translation between IPv6 hosts. NAT between IPv6 hosts is done in a similar manner and for similar purposes as IPv4 NAT.

IPv6 NAT in Junos OS provides the following NAT types:

¾ Source NAT

¾ Destination NAT

¾ Static NAT

Source NAT Translations Supported by IPv6 NAT

Source NAT is the translation of the source IP address of a packet leaving the Juniper Networks device. Source NAT is used to allow hosts with private IP addresses to access a public network.

IPv6 NAT in Junos OS supports the following source NAT translations:

¾ Translation of one IPv6 subnet to another IPv6 subnet without port address translation

¾ Translation of IPv4 addresses to IPv6 prefix + IPv4 addresses

¾ Translation of IPv6 hosts to IPv6 hosts with or without port address translation



Destination NAT Mappings Supported by IPv6 NAT

Destination NAT is the translation of the destination IP address of a packet entering the Juniper Networks device. Destination NAT is used to redirect traffic destined to a virtual host (identified by the original destination IP address) to the real host (identified by the translated destination IP address).

67 NAT overview

IPv6 NAT in Junos OS supports the following destination NAT translations:

¾ Prefix translation between IPv4 and IPv6 prefix

¾ Mapping of one IPv6 subnet to another IPv6 subnet

¾ Mapping of one IPv6 subnet to an IPv6 host

¾ Mapping of one IPv6 subnet to one IPv4 subnet

¾ Mapping of one IPv4 subnet to one IPv6 subnet

¾ Mapping of one IPv6 host (and optional port number) to one special IPv6 host (and optional port number)



Static NAT Mappings Supported by IPv6 NAT

Static NAT defines a one-to-one mapping from one IP subnet to another IP subnet. The mapping includes destination IP address translation in one direction and source IP address translation in the reverse direction. From the NAT device, the original destination address is the virtual host IP address while the mapped-to address is the real host IP address.

IPv6 NAT in Junos OS supports the following static NAT translations:

¾ Translation of one IPv6 subnet to another IPv6 subnet

¾ Translation of one IPv6 host to another IPv6 host

¾ Translation of one IPv4 address a.b.c.d to IPv6 address Prefix::a.b.c.d

¾ Translation of IPv4 hosts to IPv6 hosts

¾ Translation of IPv6 hosts to IPv4 hosts

¾ Mapping of one IPv6 prefix to one IPv4 prefix

¾ Mapping of one IPv4 prefix to one IPv6 prefix

¾ Mapping of one iPv6 prefix to one IPv6 prefix

IPv6 NAT PT overview

IPv6 Network Address Translation-Protocol Translation (NAT-PT) provides address allocation and protocol translation between IPv4 and IPv6 addressed network devices. The translation process is based on the Stateless IP/ICMP Translation (SIIT) method; however, the state and the context of each communication are retained during the session lifetime. IPv6 NAT-PT supports Internet Control Message Protocol (ICMP), TCP, and UDP packets.

IPv6 NAT-PT supports the following types of NAT-PT:

¾ Traditional NAT-PT – In traditional NAT-PT, the sessions are unidirectional and outbound from the IPv6 network . Traditional NAT-PT allows hosts within an


IPv6 network to access hosts in an IPv4 network. There are two variations to traditional NAT-PT: basic NAT-PT and NAPT-PT.

In basic NAT-PT, a block of IPv4 addresses at an IPv4 interface is set aside for translating addresses as IPv6 hosts as they initiate sessions to the IPv4 hosts. The basic NAT-PT translates the source IP address and related fields such as IP, TCP, UDP, and ICMP header checksums for packets outbound from the IPv6 domain. For inbound packets, it translates the the destination IP address and the checksums.

Network Address Port Translation-Protocol Translation (NAPT-PT) can be com-bined with basic NAT-PT so that a pool of external addresses is used in conjunction with port translation. NAPT-PT allows a set of IPv6 hosts to share a single IPv4 address. NAPT-PT translates the source IP address, source transport identifier, and related fields such as IP, TCP, UDP, and ICMP header checksums, for packets outbound from the IPv6 network. The transport identifier can be a TCP/UDP port or an ICMP query ID. For inbound packets, it translates the destination IP address, destination transport identifier, and the IP and the transport header checksums.

¾ Bidirectional NAT-PT – In bidirectional NAT-PT, sessions can be initiated from hosts in the IPv4 network as well as the IPv6 network. IPv6 network addresses are bound to IPv4 addresses, either statically or dynamically as connections are established in either direction. The static configuration is similar to static NAT translation. Hosts in IPv4 realm access hosts in the IPv6 realm using DNS for address resolution. A DNS ALG must be employed in conjunction with bidirec-tional NAT-PT to facilitate name-to-address mapping. Specifically, the DNS ALG must be capable of translating IPv6 addresses in DNS queries and responses into their IPv4 address bindings, and vice versa, as DNS packets traverse between IPv6 and IPv4 realms.

NoTE The SRX Series devices partially support the bidirectional NAT-PT specification. It supports flow of bidirectional traffic assuming that there are other ways to convey the mapping between the IPv6 address and the dynamically allocated IPv4 address. For example, a local DNS can be configured with the mapped entries for IPv4 nodes to identify the addresses.

NAT- PT Operation – The SRX Series devices support the traditional NAT-PT and allow static mapping for the user to communicate from IPv4 to IPv6. The user needs to statically configure the DNS server with an IPv4 address for the hostname and then create a static NAT on the device for the IPv6-only node to communicate from an IPv4-only node to an IPv6-only node based on the DNS.

Understanding Interfaces

Interfaces act as a doorway through which traffic enters and exits a device. Juniper Networks devices support a variety of interface types:

¾ Network interfaces – Networking interfaces primarily provide traffic connectiv-ity.

¾ Services interfaces – Services interfaces manipulate traffic before it is delivered to its destination.

69 Understanding Interfaces

¾ Special interfaces – Special interfaces include management interfaces, the loop-back interface, and the discard interface.

Each type of interface uses a particular medium to transmit data. The physical wires and Data Link Layer protocols used by a medium determine how traffic is sent. To configure and monitor interfaces, you need to understand their media characteris-tics, as well as physical and logical properties such as IP addressing, link-layer protocols, and link encapsulation.

NoTE Most interfaces are configurable, but some internally generated interfaces are not configurable.

Network Interfaces

All Juniper Networks devices use network interfaces to make physical connections to other devices. A connection takes place along media-specific physical wires through an I/O card (IOC) in the SRX Series Services Gateway. Networking inter-faces primarily provide traffic connectivity.

You must configure each network interface before it can operate on the device. Configuring an interface can define both the physical properties of the link and the logical properties of a logical interface on the link.

Table 23 describes network interfaces that are available on SRX Series devices.

Interface Name Description

ae Aggregated Ethernet interface.

at ATM-over-ADSL or ATM-over-SHDSL WAN interface.

dl Dialer interface for initiating USB modem connections.

e1 E1 (also called DS1) WAN interface.

e3 E3 (also called DS3) WAN interface.

fe Fast Ethernet interface.

ge Gigabit Ethernet interface.

pt VDSL2 interface.

reth For chassis cluster configurations only, redundant Ethernet interface.

se Serial interface (either RS-232, RS-422/499, RS-530, V.35, or X.21).

t1 T1 (also called DS1) WAN interface.

t3 T3 (also called DS3) WAN interface.

wx WXC Integrated Services Module (ISM 200) interface for WAN acceleration.

xe 10-Gigabit Ethernet interface.

Table 23 Network Interfaces


NoTE Starting in Junos OS Release 15.1X49-D10, support for multiple network interfaces is not available on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices. The affected interfaces are these: ATM-over-ADSL or ATM-over-SHDSL (at) interface, dialer interface (dl), E1 (also called DS1) WAN interface, E3 (also called DS3) WAN interface, VDSL2 interface (pt), serial interface (se), T1 (also called DS1) WAN interface, T3 (also called DS3) WAN interface. However, starting from Junos OS Release 15.1X49-D40 and onwards, SRX300, SRX320, SRX340, SRX345, and SRX550HM devices support VDSL2 (pt), serial (se), T1 (t1) , and E1 (e1) interfaces.

Services Interfaces

Services interfaces provide specific capabilities for manipulating traffic before it is delivered to its destination. On Juniper Networks M Series and T Series routing platforms, individual services such as IP-over-IP encapsulation, link services such as multilink protocols, adaptive services such as stateful firewall filters and NAT, and sampling and logging capabilities are implemented by services Physical Interface Cards (PICs). On SRX Series devices, services processing is handled by the Services Processing Card (SPC).

Although the same Junos OS image supports the services features across all routing platforms, on SRX Series devices, services interfaces are not associated with a physical interface. To configure services on these devices, you configure one or more internal interfaces by specifying slot 0, interface carrier 0, and port 0 – for example, gr-0/0/0 for GRE.

Table 24 describes services interfaces that you can configure on SRX Series Services Gateways.


gr-0/0/0 Configurable generic routing encapsulation (GRE) interface. GRE allows the encapsulation of one routing protocol inside another routing protocol.

Packets are routed to this internal interface, where they are first encapsulated with a GRE packet and then sent.

You can create multiple instances of this interface for forwarding encapsulated data to multiple destination addresses by using the default interface as the parent and creating extensions, for example, gr-0/0/0.1, gr-0/0/0.2, and so on.

The GRE interface is an internal interface only and is not associated with a physical interface. It is used only for processing GRE traffic.

ip-0/0/0 Configurable IP-over-IP encapsulation (IP-IP tunnel) interface. IP tunneling allows the encapsulation of one IP packet inside another IP packet.

With IP routing, you can route IP packets directly to a particular address or route the IP packets to an internal interface where they are encapsulated inside an IP-IP tunnel and forwarded to the encapsulating packet’s destination address.

You can create multiple instances of this interface for forwarding IP-IP tunnel data to multiple destination addresses by using the default interface as the parent and creating extensions, for example, ip-0/0/0.1, ip-0/0/0.2, and so on.

The IP-IP interface is an internal interface only and is not associated with a physical interface. It is used only for processing IP-IP tunnel traffic.



lsq-0/0/0 Configurable link services queuing interface. Link services include the multilink services MLPPP, MLFR, and Compressed Real-Time Transport Protocol (CRTP).

Packets are routed to this internal interface for link bundling or compression. The link services interface is an internal interface only and is not associated with a physical interface. You must configure the interface for it to perform multilink services.

Note: The ls-0/0/0 interface has been deprecated. All multiclass multilink features supported by ls-0/0/0 are now supported by lsq-0/0/0.

lt-0/0/0 Configurable logical tunnel interface that interconnects logical systems on SRX Series devices.

pp0 Configurable PPPoE encapsulation interface. PPP packets being routed in an Ethernet network use PPPoE encapsulation.

Packets are routed to this internal interface for PPPoE encapsulation. The PPPoE encapsulation interface is an internal interface only and is not associated with a physical interface. You must configure the interface for it to forward PPPoE traffic.

ppd0 Protocol Independent Multicast (PIM) de-encapsulation interface. In PIM sparse mode, the first-hop routing platform encapsulates packets destined for the rendezvous point device. The packets are encapsulated with a unicast header and are forwarded through a unicast tunnel to the rendezvous point. The rendezvous point then de-encapsulates the packets and transmits them through its multicast tree.

Within a device, packets are routed to this internal interface for de-encapsulation. The PIM de-encapsulation interface is an internal interface only and is not associated with a physical interface. You must configure PIM with the [edit protocol pim] hierarchy to perform PIM de-encapsulation.

Use the show pim interfaces command to check the status of ppd0 interface.

ppe0 Protocol Independent Multicast (PIM) encapsulation interface. In PIM sparse mode, the first-hop routing platform encapsulates packets destined for the rendezvous point device. The packets are encapsulated with a unicast header and are forwarded through a unicast tunnel to the rendezvous point. The rendezvous point then de-encapsulates the packets and transmits them through its multicast tree.

Within a device, packets are routed to this internal interface for encapsulation. The PIM encapsulation interface is an internal interface only and is not associated with a physical interface. You must configure PIM with the [edit protocol pim] hierarchy to perform PIM encapsulation.

st0 Secure tunnel interface used for IPSec VPNs

umd0 Configurable USB modem physical interface. This interface is detected when a USB modem is connected to the USB port on the device.

Table 24 Configurable Services Interfaces

NoTE Starting in Junos OS Release 15.1X49-D10, the lsq-0/0/0 service interface is not configurable on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices. These devices become configurable again in Junos OS Release 15.1X49-D40.


Table 25 describes non-configurable services interfaces for SRX Series Services Gateways.


gre Internally generated Generic Routing Encapsulation (GRE) interface created by Junos OS to handle GRE traffic. It is not a configurable interface.

ipip Internally generated IP-over-IP interface created by Junos OS to handle IP tunnel traffic. It is not a configurable interface.

lsi Internally generated link services interface created by Junos OS to handle multilink services like MLPPP, MLFR, and CRTP. It is not a configurable interface.

pc-pim/0/0 Internally configured interface used by the system as a control path between the WXC Integrated Services Module and the Routing Engine. It is not a configurable interface.

pimd Internally generated Protocol Independent Multicast (PIM) de-encapsulation interface created by Junos OS to handle PIM de-encapsulation. It is not a configurable interface.

pime Internally generated Protocol Independent Multicast (PIM) encapsulation interface created by Junos OS to handle PIM encapsulation. It is not a configurable interface.

tap Internally generated interface created by Junos OS to monitor and record traffic during passive monitoring. Packets discarded by the Packet Forwarding Engine are placed on this interface. It is not a configurable interface.

Table 25 Non-Configurable Services Interfaces

Special Interfaces

Special interfaces include management interfaces, which are primarily intended for accessing the device remotely, the loopback interface, which has several uses depend-ing on the particular Junos OS feature being configured, and the discard interface.

Table 26 describes special interfaces for SRX Series Services Gateways.


xp0, fxp1 On SRX Series devices, the fxp0 management interface is a dedicated port located on the Routing Engine.

lo0 Loopback address. The loopback address has several uses, depending on the particular Junos feature being configured.

dsc Discard interface.

Table 26 Special Interfaces


Interface Naming conventions

Each device interface has a unique name that follows a naming convention. If you are familiar with Juniper Networks M Series and T Series routing platforms, be aware that device interface names are similar to but not identical to the interface names on those routing platforms.

The unique name of each network interface identifies its type and location and indicates whether it is a physical interface or an optional logical unit created on a physical interface.

¾ The name of each network interface has the following format to identify the physical device that corresponds to a single physical network connector:

type-slot/pim-or-ioc/port

¾ Network interfaces that are fractionalized into time slots include a channel number in the name, preceded by a colon (:):

type-slot/pim-or-ioc/port:channel

¾ Each logical interface has an additional logical unit identifier, preceded by a period (.):

type-slot/pim-or-ioc/port:<channel>.unit

The parts of an interface name are summarized in Table 27.

Name Part Meaning Possible Values

type Type of network medium that can connect to this interface.

ae, at, ei, e3, fe, fxp0, fxp1, ge, lo0, lsq, lt, ppo, pt, sto, t1, t3, xe, and so on.

slot Number of the chassis slot in which a PIM or IOC is installed.

SRX5600 and SRX5800 devices: The slot number begins at 0 and increases as follows from left to right, bottom to top:

SRX5600 device – Slots 0 to 5

SRX5800 device – Slots 0 to 5, 7 to 11

SRX3400 and SRX3600 devices: The Switch Fabric Board (SFB) is always 0. Slot numbers increase as follows from top to bottom, left to right:



pim-or-ioc Number of the PIM or IOC on which the physical interface is located.

SRX5600 and SRX5800 devices: For 40-port Gigabit Ethernet IOCs or 4-port 10-Gigabit Ethernet IOCs, this number can be 0, 1, 2, or 3.

SRX3400 and SRX3600 devices: This number is always 0. Only one IOC can be installed in a slot.


Name Part Meaning Possible Values

port Number of the port on a PIM or IOC on which the physical interface is located.

On SRX5600 and SRX5800 devices:

For 40-port Gigabit Ethernet IOCs, this number begins at 0 and increases from left to right to a maximum of 9.

For 4-port 10-Gigabit Ethernet IOCs, this number is always 0.

On SRX3400 and SRX3600 devices:

For the SFB built-in copper Gigabit Ethernet ports, this number begins at 0 and increases from top to bottom, left to right, to a maximum of 7. For the SFB built-in fiber Gigabit Ethernet ports, this number begins at 8 and increases from left to right to a maximum of 11.

For 16-port Gigabit Ethernet IOCs, this number begins at 0 to a maximum of 15.

For 2-port 10-Gigabit Ethernet IOCs, this number is 0 or 1.

Port numbers appear on the PIM or IOC faceplate.

channel Number of the channel (time slot) on a fractional or channelized T1 or E1 interface.

On an E1 interface, a value from 1 through 31. The 1 time slot is reserved.

On a T1 interface, a value from 1 through 24.

unit Number of the logical interface created on a physical interface.

A value from 0 through 16384.

If no logical interface number is specified, unit 0 is the default, but must be explicitly configured.

In addition to user-configured interfaces, there are some logical interfaces that are created dynamically. Hence, for Junos OS, the maximum limit for configuring logical interfaces is 2,62,143 (user configured and dynamically created). Based on performance, for each platform, the maximum number of logical interfaces supported can vary.

Table 27 Network Interface Names

NoTE Platform support depends on the Junos OS release in your installation.

Understanding the Data link layer

The Data Link Layer is Layer 2 in the Open Systems Interconnection (OSI) model. The Data Link Layer is responsible for transmitting data across a physical network link. Each physical medium has link-layer specifications for network and link-layer protocol characteristics such as physical addressing, network topology, error notification, frame sequencing, and flow control.


Physical Addressing

Physical addressing is different from network addressing. Network addresses differentiate between nodes or devices in a network, allowing traffic to be routed or switched through the network. In contrast, physical addressing identifies devices at the link-layer level, differentiating between individual devices on the same physical medium. The primary form of physical addressing is the media access control (MAC) address.

Network Topology

Network topology specifications identify how devices are linked in a network. Some media allow devices to be connected by a bus topology, while others require a ring topology. The bus topology is used by Ethernet technologies, which are supported on Juniper Networks devices.

Error Notification

The Data Link Layer provides error notifications that alert higher layer protocols that an error has occurred on the physical link. Examples of link-level errors include the loss of a signal, the loss of a clocking signal across serial connections, or the loss of the remote endpoint on a T1 or T3 link.

Frame Sequencing

The frame sequencing capabilities of the Data Link Layer allow frames that are transmitted out of sequence to be reordered on the receiving end of a transmission. The integrity of the packet can then be verified by means of the bits in the Layer 2 header, which is transmitted along with the data payload.

Flow control

Flow control within the Data Link Layer allows receiving devices on a link to detect congestion and notify their upstream and downstream neighbors. The neighbor devices relay the congestion information to their higher layer protocols so that the flow of traffic can be altered or rerouted.

Data link Sublayers

The Data Link Layer is divided into two sublayers: logical link control (LLC) and media access control (MAC). The LLC sublayer manages communications between devices over a single link of a network. This sublayer supports fields in link-layer frames that enable multiple higher layer protocols to share a single physical link.

The MAC sublayer governs protocol access to the physical network medium. Through the MAC addresses that are typically assigned to all ports on a device, multiple devices on the same physical link can uniquely identify one another at the Data Link Layer. MAC addresses are used in addition to the network addresses that are typically configured manually on ports within a network.


MAc Addressing

A MAC address is the serial number permanently stored in a device adapter to uniquely identify the device. MAC addresses operate at the Data Link Layer, while IP addresses operate at the Network Layer. The IP address of a device can change as the device is moved around a network to different IP subnets, but the MAC address remains the same, because it is physically tied to the device.

Within an IP network, devices match each MAC address to its corresponding configured IP address by means of the Address Resolution Protocol (ARP). ARP maintains a table with a mapping for each MAC address in the network.

Most Layer 2 networks use one of three primary numbering spaces – MAC-48, EUI-48 (extended unique identifier), and EUI-64 – which are all globally unique. MAC-48 and EUI-48 spaces each use 48-bit addresses, and EUI-64 spaces use a 64-bit addresses, but all three use the same numbering format. MAC-48 addresses identify network hardware, and EUI-48 addresses identify other devices and soft-ware.

The Ethernet and ATM technologies supported on devices use the MAC-48 address space. IPv6 uses the EUI-64 address space.

MAC-48 addresses are the most commonly used MAC addresses in most networks. These addresses are 12-digit hexadecimal numbers (48 bits in length) that typically appear in one of the following formats:

¾ MM:MM:MM:SS:SS:SS

¾ MM-MM-MM-SS-SS-SS

The first three octets (MM:MM:MM or MM-MM-MM) are the ID number of the hardware manufacturer. Manufacturer ID numbers are assigned by the Institute of Electrical and Electronics Engineers (IEEE). The last three octets (SS:SS:SS or SS-SS-SS) make up the serial number for the device, which is assigned by the manu-facturer. For example, an Ethernet interface card might have a MAC address of 00:05:85:c1:a6:a0.

Understanding Interface logical Properties

The logical properties of an interface are the characteristics that do not apply to the physical interface or the wires connected to it. Logical properties include:

¾ Protocol families running on the interface (including any protocol-specific MTUs)

¾ IP address or addresses associated with the interface. A logical interface can be configured with an IPv6 address, IPv4 address, or both. The IP specification requires a unique address on every interface of each system attached to an IP network, so that traffic can be correctly routed. Individual hosts such as home computers must have a single IP address assigned. Devices must have a unique IP address for every interface.

¾ Virtual LAN (VLAN) tagging

¾ Any firewall filters or routing policies that are operating on the interface


Understanding Protocol Families

A protocol family is a group of logical properties within an interface configuration. Protocol families include all the protocols that make up a protocol suite. To use a protocol within a particular suite, you must configure the entire protocol family as a logical property for an interface. The protocol families include common and not-so-common protocol suites.

common Protocol Suites

Junos OS protocol families include the following common protocol suites:

¾ Inet – Supports IP protocol traffic, including OSPF, BGP, and Internet Control Message Protocol (ICMP).

¾ Inet6 – Supports IPv6 protocol traffic, including RIP for IPv6 (RIPng), IS-IS, and BGP.

¾ ISO – Supports IS-IS traffic.

¾ MPLS – Supports MPLS.

NoTE Junos OS security features are flow-based – meaning the device sets up a flow to examine the traffic. Flow-based processing is not supported for ISO or MPLS protocol families.

other Protocol Suites

In addition to the common protocol suites, Junos protocol families sometimes use the following protocol suites:

¾ ccc – Circuit cross-connect (CCC).

¾ mlfr-uni-nni – Multilink Frame Relay (MLFR) FRF.16 user-to-network net-work-to-network (UNI NNI).

¾ mlfr-end-to-end – Multilink Frame Relay end-to-end.

¾ mlppp – Multilink Point-to-Point Protocol.

¾ tcc – Translational cross-connect (TCC).

¾ tnp – Trivial Network Protocol. This Juniper Networks proprietary protocol provides communication between the Routing Engine and the device’s packet for-warding components. Junos OS automatically configures this protocol family on the device’s internal interfaces only.

Understanding IPv4 Addressing

IPv4 addresses are 32-bit numbers that are typically displayed in dotted decimal notation. A 32-bit address contains two primary parts: the network prefix and the host number.

All hosts within a single network share the same network address. Each host also has an address that uniquely identifies it. Depending on the scope of the network and the type of device, the address is either globally or locally unique. Devices that are visible


to users outside the network (webservers, for example) must have a globally unique IP address. Devices that are visible only within the network must have locally unique IP addresses.

IP addresses are assigned by a central numbering authority called the Internet Assigned Numbers Authority (IANA). IANA ensures that addresses are globally unique where needed and has a large address space reserved for use by devices not visible outside their own networks.

IPv4 classful Addressing

To provide flexibility in the number of addresses distributed to networks of different sizes, 4-octet (32-bit) IP addresses were originally divided into three different categories or classes: class A, class B, and class C. Each address class specifies a different number of bits for its network prefix and host number:

¾ Class A addresses use only the first byte (octet) to specify the network prefix, leaving 3 bytes to define individual host numbers.

¾ Class B addresses use the first 2 bytes to specify the network prefix, leaving 2 bytes to define host addresses.

¾ Class C addresses use the first 3 bytes to specify the network prefix, leaving only the last byte to identify hosts.

In binary format, with an x representing each bit in the host number, the three address classes can be represented as follows:

00000000 xxxxxxxx xxxxxxxx xxxxxxxx (Class A)00000000 00000000 xxxxxxxx xxxxxxxx (Class B)00000000 00000000 00000000 xxxxxxxx (Class C)

Because each bit (x) in a host number can have a 0 or 1 value, each represents a power of 2. For example, if only 3 bits are available for specifying the host number, only the following host numbers are possible:

111 110 101 100 011 010 001 000

In each IP address class, the number of host-number bits raised to the power of 2 indicates how many host numbers can be created for a particular network prefix. Class A addresses have 224 (or 16,777,216) possible host numbers, class B addresses have 216 (or 65,536) host numbers, and class C addresses have 28 (or 256) possible host numbers.

IPv4 Dotted Decimal Notation

The 32-bit IPv4 addresses are most often expressed in dotted decimal notation, in which each octet (or byte) is treated as a separate number. Within an octet, the rightmost bit represents 20 (or 1), increasing to the left until the first bit in the octet is 27 (or 128). Following are IP addresses in binary format and their dotted decimal equivalents:

11010000 01100010 11000000 10101010 = 208.98.192.17001110110 00001111 11110000 01010101 = 118.15.240.8500110011 11001100 00111100 00111011 = 51.204.60.59


IPv4 Subnetting

Because of the physical and architectural limitations on the size of networks, you often must break large networks into smaller subnetworks. Within a network, each wire or ring requires its own network number and identifying subnet address.

Figure 6 shows two subnets in a network.

Figure 6 Subnets in a Network

Figure 6 shows three devices connected to one subnet and three more devices connected to a second subnet. Collectively, the six devices and two subnets make up the larger network. In this example, the network is assigned the network prefix 192.14.0.0, a class B address. Each device has an IP address that falls within this network prefix.

In addition to sharing a network prefix (the first two octets), the devices on each subnet share a third octet. The third octet identifies the subnet. All devices on a subnet must have the same subnet address. In this case, the alpha subnet has the IP address 192.14.126.0 and the beta subnet has the IP address 192.14.17.0.

The subnet address 192.14.17.0 can be represented as follows in binary notation:

11000000 . 00001110 . 00010001 . xxxxxxxx

Because the first 24 bits in the 32-bit address identify the subnet, the last 8 bits are not significant. To indicate the subnet, the address is written as 192.14.17.0/24 (or just 192.14.17/24). The /24 is the subnet mask (sometimes shown as 255.255.255.0).


IPv4 Variable-length Subnet Masks

Traditionally, subnets were divided by address class. Subnets had either 8, 16, or 24 significant bits, corresponding to 224, 216, or 28 possible hosts. As a result, an entire /16 subnet had to be allocated for a network that required only 400 addresses, wasting 65,136 (216 – 400 = 65,136) addresses.

To help allocate address spaces more efficiently, variable-length subnet masks (VLSMs) were introduced. Using VLSM, network architects can allocate more precisely the number of addresses required for a particular subnet.

For example, suppose a network with the prefix 192.14.17/24 is divided into two smaller subnets, one consisting of 18 devices and the other of 46 devices.

To accommodate 18 devices, the first subnet must have 25 (32) host numbers. Having 5 bits assigned to the host number leaves 27 bits of the 32-bit address for the subnet. The IP address of the first subnet is therefore 192.14.17.128/27, or the following in binary notation:

11000000 . 00001110 . 00010001 . 100xxxxx

The subnet mask includes 27 significant digits.

To create the second subnet of 46 devices, the network must accommodate 26 (64) host numbers. The IP address of the second subnet is 192.14.17.64/26, or

11000000 . 00001110 . 00010001 . 01xxxxxx

By assigning address bits within the larger /24 subnet mask, you create two smaller subnets that use the allocated address space more efficiently.

Understanding IPv6 Addressing

Understanding IP Version 6 (IPv6)

The ongoing expansive growth of the Internet and the need to provide IP addresses to accommodate it – to support increasing numbers of new users, computer net-works, Internet-enabled devices, and new and improved applications for collabora-tion and communication – is escalating the emergent use of a new IP protocol. IPv6, with its robust architecture, was designed to satisfy these current and anticipated near future requirements.

IP version 4 (IPv4) is widely used throughout the world today for the Internet, intranets, and private networks. IPv6 builds upon the functionality and structure of IPv4 in the following ways:

¾ Provides a simplified and enhanced packet header to allow for more efficient routing.

¾ Improves support for mobile phones and other mobile computing devices.

¾ Enforces increased, mandatory data security through IPsec (which was originally designed for it).

¾ Provides more extensive quality-of-service (QoS) support.


IPv6 addresses consist of 128 bits, instead of 32 bits, and include a scope field that identifies the type of application suitable for the address. IPv6 does not support broadcast addresses, but instead uses multicast addresses for broadcast. In addition, IPv6 defines a new type of address called anycast.

Understanding IPv6 Address Types and How Junos oS for SRX Series Services Gateway Uses Them

IP version 6 (IPv6) includes the following types of addresses:

¾ Unicast

A unicast address specifies an identifier for a single interface to which packets are delivered. Under IPv6, the vast majority of Internet traffic is foreseen to be unicast, and it is for this reason that the largest assigned block of the IPv6 address space is dedicated to unicast addressing. Unicast addresses include all addresses other than loopback, multicast, link-local-unicast, and unspecified.

For SRX Series devices, the flow module supports the following kinds of IPv6 unicast packets:

¾ Pass-through unicast traffic, including traffic from and to virtual routers. The device transmits pass-through traffic according to its routing table.

¾ Host-inbound traffic from and to devices directly connected to SRX Series interfaces. For example, host-inbound traffic includes logging, routing protocol, and management types of traffic. The flow module sends these unicast packets to the Routing Engine and receives them from it. Traffic is processed by the Routing Engine instead of by the flow module, based on rout-ing protocols defined for the Routing Engine.

¾ The flow module supports all routing and management protocols that run on the Routing Engine. Some examples are OSPFv3, RIPng, TELNET, and SSH.

¾ Multicast

¾ A multicast address specifies an identifier for a set of interfaces that typically belong to different nodes. It is identified by a value of 0xFF. IPv6 multicast addresses are distinguished from unicast addresses by the value of the high-order octet of the addresses.

¾ The devices support only host-inbound and host-outbound multicast traffic. Host inbound traffic includes logging, routing protocols, management traffic, and so on.

¾ Anycast

¾ An anycast address specifies an identifier for a set of interfaces that typically belong to different nodes. A packet with an anycast address is delivered to the nearest node, according to routing protocol rules.

¾ There is no difference between anycast addresses and unicast addresses except for the subnet-router address. For an anycast subnet-router address, the low order bits, typically 64 or more, are zero. Anycast addresses are taken from the unicast address space.

¾ The flow module treats anycast packets in the same way as it handles unicast packets. If an anycast packet is intended for the device, it is treated as host-


inbound traffic, and it delivers it to the protocol stack which continues processing it.

IPv6 Address Scope

Unicast and multicast IPv6 addresses support address scoping, which identifies the application suitable for the address.

Unicast addresses support global address scope and two types of local address scope:

¾ Link-local unicast addresses – Used only on a single network link. The first 10 bits of the prefix identify the address as a link-local address. Link-local addresses cannot be used outside the link.

¾ Site-local unicast addresses – Used only within a site or intranet. A site consists of multiple network links. Site-local addresses identify nodes inside the intranet and cannot be used outside the site.

Multicast addresses support 16 different types of address scope, including node, link, site, organization, and global scope. A 4-bit field in the prefix identifies the address scope.

IPv6 Address Structure

Unicast addresses identify a single interface. Each unicast address consists of n bits for the prefix, and 128 – n bits for the interface ID.

Multicast addresses identify a set of interfaces. Each multicast address consists of the first 8 bits of all 1s, a 4-bit flags field, a 4-bit scope field, and a 112-bit group ID:

11111111 | flgs | scop | group ID

The first octet of 1s identifies the address as a multicast address. The flags field identifies whether the multicast address is a well-known address or a transient multicast address. The scope field identifies the scope of the multicast address. The 112-bit group ID identifies the multicast group.

Similar to multicast addresses, anycast addresses identify a set of interfaces. How-ever, packets are sent to only one of the interfaces, not to all interfaces. Anycast addresses are allocated from the normal unicast address space and cannot be distinguished from a unicast address in format. Therefore, each member of an anycast group must be configured to recognize certain addresses as anycast address-es.

Understanding IPv6 Address Space, Addressing, and Address Types

Addressing is the area where most of the differences between IP version 4 (IPv4) and IPv6 exist, but the changes are largely about the ways in which addresses are imple-mented and used. IPv6 has a vastly larger address space than the impending exhaust-ed IPv4 address space. IPv6 increases the size of the IP address from the 32 bits that compose an IPv4 address to 128 bits. Each extra bit given to an address doubles the size of the address space.

IPv4 has been extended using techniques such as Network Address Translation (NAT), which allows for ranges of private addresses to be represented by a single public address, and temporary address assignment. Although useful, these tech-


niques fall short of the requirements of novel applications and environments such as emerging wireless technologies, always-on environments, and Internet-based consumer appliances.

In addition to the increased address space, IPv6 addresses differ from IPv4 addresses in the following ways:

¾ Includes a scope field that identifies the type of application that the address pertains to

¾ Does not support broadcast addresses, but instead uses multicast addresses to broadcast a packet

¾ Defines a new type of address, called anycast

Understanding IPv6 Address Format

All IPv6 addresses are 128 bits long, written as 8 sections of 16 bits each. They are expressed in hexadecimal representation, so the sections range from 0 to FFFF. Sections are delimited by colons, and leading zeroes in each section may be omitted. If two or more consecutive sections have all zeroes, they can be collapsed to a double colon.

IPv6 addresses consist of 8 groups of 16-bit hexadecimal values separated by colons (:). IPv6 addresses have the following format:

aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa:aaaa

Each aaaa is a 16-bit hexadecimal value, and each a is a 4-bit hexadecimal value. Following is a sample IPv6 address:

3FFE:0000:0000:0001:0200:F8FF:FE75:50DF

You can omit the leading zeros of each 16-bit group, as follows:

3FFE:0:0:1:200:F8FF:FE75:50DF

You can compress 16-bit groups of zeros to double colons (::) as shown in the following example, but only once per address:

3FFE::1:200:F8FF:FE75:50DF

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 address-ing 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, 10FA:6604:8136:6502::/64 is a possible IPv6 prefix.

For more information on the text representation of IPv6 addresses and address prefixes, see RFC 4291, IP Version 6 Addressing Architecture.

limitations

SRX300, SRX320, SRX340, SRX345, and SRX550HM devices have the following limitations:

¾ Changes in source AS and destination AS are not immediately reflected in exported flows.


¾ IPv6 traffic transiting over IPv4 based IP over IP tunnel (for example, IPv6-over-IPv4 using ip-x/x/x interface) is not supported.

Understanding Interface Physical Properties

The physical properties of a network interface are the characteristics associated with the physical link that affect the transmission of either link-layer signals or the data across the links. Physical properties include clocking properties, transmission properties, such as the maximum transmission unit (MTU), and encapsulation methods, such as point-to-point and Frame Relay encapsulation.

The default property values for an interface are usually sufficient to successfully enable a bidirectional link. However, if you configure a set of physical properties on an interface, those same properties must be set on all adjacent interfaces to which a direct connection is made.

Table 28 summarizes some key physical properties of device interfaces.

Physical Property Description

bert-error-rate Bit error rate (BER). The error rate specifies the number of bit errors in a particular bit error rate test (BERT) period required to generate a BERT error condition.

bert-period Bit error rate test (BERT) time period over which bit errors are sampled.

chap Challenge Handshake Authentication Protocol (CHAP). Specifying chap enables CHAP authentication on the interface.

clocking Clock source for the link. Clocking can be provided by the local system (internal) or a remote endpoint on the link (external). By default, all interfaces use the internal clocking mode. If an interface is configured to accept an external clock source, one adjacent interface must be configured to act as a clock source. Under this configuration, the interface operates in a loop timing mode, in which the clocking signal is unique for that individual network segment or loop.

description A user-defined text description of the interface, often used to describe the interface’s purpose.

disable Administratively disables the interface.

encapsulation Type of encapsulation on the interface. Common encapsulation types include PPP, Frame Relay, Cisco HDLC, and PPP over Ethernet (PPPoE).

fcs Frame check sequence (FCS). FCS is an error-detection scheme that appends parity bits to a digital signal and uses decoding algorithms that detect errors in the received digital signal.

mtu Maximum transmission unit (MTU) size. MTU is the largest size packet or frame, specified in bytes or octets, that can be sent in a packet-based or frame-based network. The TCP uses MTU to determine the maximum size of each packet in any transmission.

no-keepalives Disabling of keepalive messages across a physical link. A keepalive message is sent between network devices to indicate that they are still active. Keepalives help determine whether the interface is operating correctly. Except for ATM-over-ADSL interfaces, all interfaces use keepalives by default.

pap Password Authentication Protocol (PAP). Specifying pap enables PAP authentication on the interface.

payload-scrambler Scrambling of traffic transmitted out the interface. Payload scrambling randomizes the data payload of transmitted packets. Scrambling eliminates non-variable bit patterns (strings of all 1s or all 0s) that generate link-layer errors across some physical links.

85 Firewall User Authentication for Security Devices

Table 28 Interface Physical Properties

Firewall User Authentication for Security Devices

Firewall user authentication lets you define firewall users and create policies that require the users to authenticate themselves through one of two authentication schemes: pass-through authentication or web 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.

A firewall user is a network user who must provide a username and password for authentication when initiating a connection across the firewall. Junos OS enables administrators to restrict and permit firewall users to access protected resources (different zones) behind a firewall based on their source IP address and other credentials.

Junos OS also supports the administrator and Point-to-Point Protocol (PPP) user types.

NoTE Starting in Junos OS Release 15.1X49-D40, HTTPS-based authentication is intro-duced on vSRX, SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 Services Gateways.

After you define firewall users, you can create a policy that requires the users to authenticate themselves through one of three authentication schemes:

¾ Pass-through authentication – A host or a user from one zone tries to access resources on another zone. You must use an FTP client, a Telnet client, an HTTP client, or an HTTPS client to access the IP address of the protected resource and to get authenticated by the firewall. The device uses FTP, Telnet, HTTP, or HTTPS to collect username and password information, and subsequent traffic from the user or host is allowed or denied based on the result of this authentica-tion. When the device is using an HTTPS server, and after the authentication is done, the subsequent traffic from the user is always terminated whether the authentication is successful or not.

NoTE Starting with Junos OS Release 12.1X44-D10, support for HTTPS-based authenti-cation is introduced for high-end SRX Series Services Gateways. It is not supported on SRX Series branch devices. For branch devices, you must use HTTP-based authentication.

¾ Pass-through with web-redirect authentication – This authentication scheme is for HTTP and HTTPS. when firewall authentication is performed using the pass-through authentication scheme for HTTP and HTTPs clients, the web-redi-rect feature optionally, redirects HTTP or HTTPS requests to the device’s internal webserver by sending a redirect HTTP or HTTPS 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.


Using this feature allows for a richer user login experience. For example. instead of a popup prompt asking for username and password, users can get the login page in a browser. Enabling web-redirect has the same effect as users typing the Web authenti-cation IP address in a client browser. Using web-redirect provides a more seamless authentication experience because users do not need to know the Web authentica-tion IP address but only the IP address of the resource they are trying to access. After the user has been authenticated this way, traffic from user’s IP address is authenti-cated to go through the web-redirect method.

When you web-redirect, you http or https the destination url, the authentication page prompts you after successful authentication.

A message is displayed to inform you about the successful authentication. After successful authentication, the browser launches your original destination URL without your needing to retype the URL.

The following message is displayed:

Redirecting to the original url, please wait

¾ Web authentication – Users try to connect, using HTTP or HTTPS, to an IP address on the device that is enabled for Web authentication; in this scenario, you do not use HTTP or HTTPS to get to the IP address of the protected resource. You are prompted for the username and password that are verified by the device. Subsequent traffic from the user or host to the protected resource is allowed or denied based on the result of this authentication.

SSl Proxy overview

Secure Sockets Layer (SSL) is an application-level protocol that provides encryption technology for the Internet. SSL, also called Transport Layer Security (TLS), ensures the secure transmission of data between a client and a server through a combination of privacy, authentication, confidentiality, and data integrity. SSL relies on certifi-cates and private-public key exchange pairs for this level of security. SSL is support-ed on the SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and the SRX5800 devices.

Server authentication guards against fraudulent transmissions by enabling a Web browser to validate the identity of a webserver. Confidentiality mechanisms ensure that communications are private. SSL enforces confidentiality by encrypting data to prevent unauthorized users from eavesdropping on electronic communications. Finally, message integrity ensures that the contents of a communication have not been tampered with.

SSL proxy is transparent; that is, it performs SSL encryption and decryption between the client and the server, but neither the server nor the client can detect its presence. Existing features like SSL offload and SSL inspection require the servers to share their secret keys to be able to decrypt the SSL traffic. However, sharing server keys is sometimes not feasible or might not be available in certain circumstances, in which case the SSL traffic cannot be decrypted.

SSL proxy addresses this problem by ensuring that it has the keys to encrypt and decrypt the payload:


¾ For the server, SSL proxy acts as a client – Because SSL proxy generates the shared pre-master key, it determines the keys to encrypt and decrypt.

¾ For the client, SSL proxy acts as a server – SSL proxy first authenticates the original server and replaces the public key in the original server certificate with a key that is known to it. It then generates a new certificate by replacing the original issuer of the certificate with its own identity and signs this new certificate with its own public key (provided as a part of the proxy profile configuration). When the client accepts such a certificate, it sends a shared pre-master key encrypted with the public key on the certificate. Because SSL proxy replaced the original key with its own key, it is able to receive the shared pre-master key. Decryption and encryption take place in each direction (client and server), and the keys are different for both encryption and decryption.

Figure 7 depicts how SSL inspection (on an existing SRX Series IDP module) is typically used to protect servers. SSL inspection requires access to the private keys used by the servers so that the SRX Series device can decrypt the encrypted traffic.

Figure 7 SSL Inspection on an Existing SRX Series IDP Module

Supported ciphers in Proxy Mode

An SSL cipher comprises encryption ciphers, authentication method, and compres-sion. The following SSL protocols are supported on SRX Series devices:

¾ TLS version 1.0 – Provides secure communication over networks by providing privacy and data integrity between communicating applications

¾ TLS version 1.1 – This enhanced version of TLS provides protection against cipher-block chaining (CBC) attacks.

¾ TLS version 1.2 – This enhanced version of TLS provides improved flexibility for negotiation of cryptographic algorithms.


Starting with Junos OS Release 15.1X49-D30 , TLS version 1.1 and TLS version 1.2 protocols are supported on SRX Series devices along with TLS version 1.0.

Starting with Junos OS Release 15.1X49-D20, the SSL protocol 3.0 (SSLv3) support is deprecated.

Server Authentication

Implicit trust between the client and the device (because the client accepts the certificate generated by the device) is an important aspect of SSL proxy. It is extreme-ly important that server authentication is not compromised; however, in reality, self-signed certificates and certificates with anomalies are in abundance. Anomalies can include expired certificates, instances of common name not matching a domain name, and so forth. Server authentication is governed by setting the ignore-server-auth-failure option in the SSL proxy.

¾ By default, the ignore-server-auth-failure option is not defined as an action in the SSL proxy profile, and the following occurs:

¾ If authentication succeeds, a new certificate is generated by replacing the keys and changing the issuer name to the issuer name that is configured in the root CA certificate in the proxy profile.

¾ If authentication fails, the connection is dropped.

¾ If the ignore-server-auth-failure option is defined as an action in the SSL proxy profile, the following occurs:

¾ If the certificate is self-signed, a new certificate is generated by replacing the keys only. The issuer name is not changed. This ensures that the client browser displays a warning that the certificate is not valid.

¾ If the certificate has expired or if the common name does not match the domain name, a new certificate is generated by replacing the keys and changing the issuer name to SSL-PROXY: DUMMY_CERT:GENERATED DUE TO SRVR AUTH FAILURE. This ensures that the client browser displays a warning that the certificate is not valid.

Trusted cA list

SSL proxy ensures secure transmission of data between a client and a server. Before establishing a secure connection, SSL proxy checks CA certificates to verify signa-tures on server certificates. For this reason, a reasonable list of trusted CA certificates is required to effectively authenticate servers.

Junos OS provides the following options for trusted CA certificates:

¾ Loading the default trusted CA list – Junos OS provides a default list of certifi-cates that contains well-known trusted CA certificates similar to the default certificates used by most common browsers. Without these default certificates, browsers would not be able to validate the identity of most websites and would mark them as untrusted sites.

The Junos OS package contains the default CA certificates as a PEM file (for exam-ple, trusted_CA.pem). After you download the package and reboot your device, you can easily load the default certificates on your system using a CLI command.


We recommend you load the default trusted CA list if you want to trust the same CA certificates as common browsers and avoid importing CA certificates manually.

¾ Importing the trusted CA list manually – You can import your own trusted CA certificates using the Public Key Infrastructure (PKI). The PKI helps verify and authenticate the validity of the trusted CA certificates. You create CA profile groups that include trusted CA certificates, then import the group on your device for server authentication.

¾ Ignoring server authentication – You can use the ignore-server-auth-failure option to ignore server authentication completely. In this case, SSL proxy ignores errors encountered during the server certificate verification process (such as CA signature verification failure, self-signed certificates, and certificate expiry).

We do not recommend this option for authentication, because configuring it results in websites not being authenticated at all. However, you can use this option to effectively identify the root cause for dropped SSL sessions.

Root cA

In a public key infrastructure (PKI) hierarchy, the root CA is at the top of the trust path. The root CA identifies the server certificate as a trusted certificate.

client Authentication

Currently, client authentication is not supported in SSL proxy. If a server requests client authentication, a warning is issued that a certificate is not available. The warning lets the server determine whether to continue or to exit.

Whitelists

Because SSL encryption and decryption are complicated and expensive procedures, network administrators can selectively bypass SSL proxy processing for some sessions. Such sessions mostly include connections and transactions with trusted servers or domains with which network administrators are very familiar. There are also legal requirements to exempt financial and banking sites. Such exemptions are achieved by configuring the IP addresses or domain names of the servers under whitelists.

Starting with Junos OS Release 15.1X49-D80, the whitelisting feature is extended to include URL categories supported by UTM in the whitelist configuration of SSL forward proxy. In this implementation, the Server Name Indication (SNI) field is extracted by the UTM module from client hello messages to determine the URL category. Each URL category has a unique ID. The list of URL categories under whitelist is parsed and the corresponding category IDs are pushed to the Packet Forwarding Engine for each SSL forward proxy profile. The SSL forward proxy then determines through APIs whether to accept, and proxy, or to ignore the session.

Dynamic Resolution of Domain Names

The IP addresses associated with domain names are dynamic and can change at any time. Whenever a domain IP address changes, it is propagated to the SSL proxy configuration (similar to what is done in the firewall policy configuration).


Session Resumption

An SSL session refers to the set of parameters and encryption keys created by performing a full handshake. A connection is the conversation or active data transfer that occurs within the session. The computational overhead of a complete SSL handshake and generation of master keys is considerable. In short-lived sessions, the time taken for the SSL handshake can be more than the time for data transfer.

To improve throughput and still maintain an appropriate level of security, SSL session resumption provides a session caching mechanism so that session informa-tion, such as the pre-master secret key and agreed-upon ciphers, can be cached for both the client and server. The cached information is identified by a session ID. In subsequent connections both parties agree to use the session ID to retrieve the information rather than create a new pre-master secret key. Session resumption shortens the handshake process and accelerates SSL transactions.

Session Renegotiation

After a session is created and SSL tunnel transport has been established, a change in SSL parameters requires renegotiation. SSL proxy supports both secure (RFC 5746) and non-secure (TLS v1.0, TLS v1.1, and TLS v1.2) renegotiation. When session resumption is enabled, session renegotiation is useful in the following situations:

¾ Cipher keys need to be refreshed after a prolonged SSL session.

¾ Stronger ciphers need to be applied for a more secure connection.

A change in an SSL proxy profile that modifies a certificate, cipher strength, or trusted CA list flushes cache entries when the modified policy is committed. When a session is resumed, the SSL parameters associated with its session ID are retrieved from the cache. If the SSL proxy profile is not altered, cache entries corresponding to that profile are not flushed and the session continues. If the cache has been flushed, however, a full handshake must be performed to establish the new SSL parameters. (There is no impact to non-SSL sessions.)

leveraging Dynamic Application Identification

SSL proxy uses application identification services to dynamically detect if a particu-lar session is SSL encrypted. SSL proxies are allowed only if a session is SSL encrypt-ed. The following rules apply for a session:

¾ Session is marked Encrypted=Yes in the application system cache. If the session is marked Encrypted=Yes, it indicates that the final match from application identifi-cation for that session is SSL encrypted, and SSL proxy transitions to a state where proxy functionality can be initiated.

¾ Session is marked Encrypted=No in the application system cache. If a non-SSL entry is found in the application system cache, it indicates that the final match from application identification for that session is non-SSL and SSL proxy ignores the session.

¾ An entry is not found in the application system cache. This can happen on the first session, or when the application system cache has been cleaned or has expired. In such a scenario, SSL proxy cannot wait for the final match (requires traffic in both directions). In SSL proxy, traffic in reverse direction happens only if SSL proxy has initiated an SSL handshake. Initially, for such a scenario SSL proxy


tries to leverage prematch or aggressive match results from application identifica-tion , and if the results indicate SSL, SSL proxy will go ahead with the handshake.

¾ Application identification fails due to resource constraints and other errors. Whenever the result from application identification is not available, SSL proxy will assume static port binding and will try to initiate SSL handshake on the session. This will succeed for actual SSL sessions, but it will result in dropped sessions for non SSL sessions.

Understanding Pass-Through Authentication

Pass-through user authentication is a form of active authentication; the user is prompted to enter a username and password when pass-through authentication is invoked. If the user’s identity is validated, the user is allowed to pass through the firewall and gain access to the requested resources.

When a user attempts to initiate an HTTP, an HTTPS, an FTP, or a Telnet connec-tion request that has a policy requiring authentication, the device intercepts the request and prompts the user to enter a username and password. Depending on the configuration, the device validates the username and password by checking them against those stored in the local database or on an external authentication server.

If an external authentication server is used, after the user’s credentials are collected, they are processed through firewall user authentication. The following external authentication servers are supported:

¾ RADIUS authentication and authorization (compatible with Juniper Steel-Belted Radius servers)

You can use an external RADIUS server if, in addition to authentication, you want to obtain authorization information about the user’s access right (what the user can do on the network).

¾ LDAP authentication only (supports LDAP version 3, compatible with Windows AD)

¾ SecurID authentication only (uses an RSA SecurID external authentication server)

A firewall user is a network user who must provide a username and password for authentication when initiating a connection across the firewall. You can put several user accounts together to form a user group, which you can store on the local database or on a RADIUS, an LDAP, or a SecurID server. When you reference an authentication user group and an external authentication server in a policy, the traffic matching the policy triggers an authentication check.

NoTE You use family inet to assign an IPv4 address. You use family inet6 to assign an IPv6 address. An interface can be configured with both an IPv4 and an IPv6 address. For the sake of brevity, these examples use IPv4 addresses only.


Figure 8 Policy Lookup for a User

The steps in Figure 8 are as follows:

1. A client user sends an FTP, an HTTP, an HTTPS, or a Telnet packet to 198.51.100.9.

2. The device intercepts the packet, notes that its policy requires authentication from either the local database or an external authentication server, and buffers the packet.

3. The device prompts the user for login information through FTP, HTTP, HTTPS, or Telnet.

4. The user replies with a username and password.

5. The device either checks for an authentication user account on its local database or sends the login information to the external authentication server as specified in the policy.

6. Finding a valid match (or receiving notice of such a match from the external authentication server), the device informs the user that the login has been successful.

7. For HTTP, HTTPS, or Telnet traffic, the device forwards the packet from its buffer to its destination IP address, 198.51.100.9/24. However, for FTP traffic, after successful authentication, the device closes the session and the user must reconnect to the FTP server at IP address 198.51.100.9/24.

After the device authenticates a user at a particular source IP address, it subsequently permits traffic – as specified in the policy requiring authentication through pass through – from any other user at that same address. This might be the case if the user originates traffic from behind a NAT device that changes all original source address-es to a single translated address.


NoTE The pass-through user authentication method is recommended in situations when security has a higher priority than convenience. This authentication method applies only to the session and child sessions matching the policy that triggered it. You can apply this method on Internet-facing links, if used with caution.

Understanding Web Authentication

Web authentication is an alternative to pass-through user authentication. Instead of pointing to the resource that you want to connect to from your client browser, you point the browser to an IP address on the device that is enabled for Web authentica-tion. This initiates an HTTP session to the IP address hosting the Web authentication feature on the device. The device then prompts you for your username and password and caches the result in the device. Later, when traffic encounters a Web authentica-tion policy, you are allowed or denied access based on the prior Web authentication results, as shown in Figure 9.

NoTE You use family inet to assign an IPv4 address. You use family inet6 to assign an IPv6 address. An interface can be configured with both an IPv4 and an IPv6 address. For the sake of brevity, these examples use IPv4 addresses only.

Figure 9 Web Authentication Example

Follow these Web authentication guidelines:

¾ You can leave the default Web authentication server as the local database or you can choose an external authentication server for the role. The default Web authentication profile determines if the user authenticates using the local data-


base or the external authentication server. An access profile stores usernames and passwords of users or points to external authentication servers where such information is stored.

¾ The Web authentication address must be in the same subnet as the interface that you want to use to host it. For example, if you want authentication users to connect using Web authentication through ethernet3, which has IP address 203.0.113.1/24, then you can assign Web authentication an IP address in the 203.0.113.0/24 subnet.

¾ You can put a Web authentication address in the same subnet as the IP address of any physical interface or virtual security interface (VSI).

¾ You can put Web authentication addresses on multiple interfaces.

¾ After a device authenticates a user at a particular source IP address, it subsequent-ly permits traffic – as specified in the policy requiring authentication through Web authentication – from any other user at that same address. This might be the case if the user originates traffic from behind a NAT device that changes all original source addresses to a single translated address.

¾ With Web authentication enabled, any HTTP traffic to the IP address will get the Web authentication login page instead of the administrator login page. Disabling this option will show the administrator login page (assuming that [system services web-management HTTP] is enabled.

¾ We recommend that you have a separate primary or preferred IP address, if an address is used for Web authentication.

NoTE The Web authentication method is recommended in situations when the client devices are immediately adjacent to the security gateway and there is high assurance that the client devices are not multiuser hosts. This authentication method is best applied to wireless links and DMZ, or conference room links.

Understanding External Authentication Servers

Authentication, authorization, and accounting (AAA) servers provide an extra level of protection and control for user access in the following ways:

¾ Authentication determines the firewall user.

¾ Authorization determines what the firewall user can do.

¾ Accounting determines what the firewall user did on the network.

You can use authentication alone or with authorization and accounting. Authoriza-tion always requires a user to be authenticated first. You can use accounting alone, or with authentication and authorization.

Once the user’s credentials are collected, they are processed using firewall user authentication, which supports the following types of servers:

¾ Local authentication and authorization

¾ RADIUS authentication and authorization (compatible with Juniper Steel-Belted Radius server)


¾ LDAP authentication only (supports LDAP version 3 and is compatible with Windows AD)

¾ SecurID authentication only (using an RSA SecurID external authentication server)

NoTE Junos OS also supports administrative authentication using local, RADIUS, and TACACS+ servers.

Understanding SecurID User Authentication

SecurID is an authentication method that allows users to enter either static or dynamic passwords as their credentials. A dynamic password is a combination of a user’s PIN and a randomly generated token that is valid for a short period of time, approximately one minute. A static password is set for the user on the SecurID server. For example, the SecurID server administrator might set a temporary static password for a user who lost his or her SecurID token.

When a user attempts to access a resource protected by a policy and SecurID is configured in the profile authentication-order parameter as either the only authen-tication mode or the first one to be used, the device forwards the user’s credentials to the SecurID server for authentication. If the user enters valid values, the user is allowed access to the requested resource.

NoTE The SecurID server includes a feature that presents a user with a challenge if the user provides wrong credentials repeatedly. However, Junos OS does not support the challenge feature. Instead, the SecurID server administrator must resynchronize the RSA token for the user.

For SecurID, you configure information about the Juniper Networks device on the SecurID server, and this information is exported to a file called sdconf.rec.

To install the sdconf.rec file on the device, you must use an out-of-band method such as FTP. Install the file in a directory whose files are not deleted regularly. Do not put it in a temporary directory. For example, you might install it in /var/db/secureid/server1/sdconf.rec.

The sdconf.rec file contains information that provides the Juniper Networks device with the address of the SecurID server. You do not need to configure this information explicitly when you configure the SecurID server to be used as the external authenti-cation server.

Attack Detection and Prevention overview

Attack detection and prevention, also known as stateful firewall, detects and prevents attacks in network traffic. An exploit can be either an information-gather-ing probe or an attack to compromise, disable, or harm a network or network resource. In some cases, the distinction between the two objectives of an exploit can be unclear. For example, a barrage of TCP SYN segments might be an IP address sweep with the intent of triggering responses from active hosts, or it might be a SYN flood attack with the intent of overwhelming a network so that it can no longer func-tion properly. Furthermore, because an attacker usually precedes an attack by


performing reconnaissance on the target, we can consider information-gathering efforts as a precursor to an impending attack – that is, they constitute the first stage of an attack. Thus, the term exploit encompasses both reconnaissance and attack activities, and the distinction between the two is not always clear.

Juniper Networks provides various detection and defense mechanisms at the zone and policy levels to combat exploits at all stages of their execution:

¾ Screen options at the zone level.

¾ Firewall policies at the inter-, intra-, and super-zone policy levels (super-zone here means in global policies, where no security zones are referenced).

To secure all connection attempts, Junos OS uses a dynamic packet-filtering method known as stateful inspection. Using this method, Junos OS identifies various compo-nents in the IP packet and TCP segment headers – source and destination IP address-es, source and destination port numbers, and packet sequence numbers – and maintains the state of each TCP session and pseudo UDP session traversing the firewall. (Junos OS also modifies session states based on changing elements such as dynamic port changes or session termination.) When a responding TCP packet arrives, Junos OS compares the information reported in its header with the state of its associated session stored in the inspection table. If they match, the responding packet is allowed to pass the firewall. If the two do not match, the packet is dropped.

Junos OS screen options secure a zone by inspecting, then allowing or denying, all connection attempts that require crossing an interface bound to that zone.

97 Appendix

Appendix: Links and URLs

SRX Series TechLibrary: https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/srx-series/index.html

Understanding Security Zones: https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-basic-zone-interface.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-security-understanding.html

Understanding Security Zone Interfaces: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-and-interface-overview.html

Understanding How to Control Inbound Traffic Based on Traffic Types: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-host-inbound-traffic-how-to-control-based-on-traffic-type-understanding.html

Understanding How to Control Inbound Traffic Based on Protocols: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-inbound-traffic-how-to-control-based-on-protocol-understanding.html

Understanding Functional Zones: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-functional-understanding.html

Understanding Address Books: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-understanding.html

Understanding Global Address Books: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-global-understanding.html

Understanding Address Sets: https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-set-understanding.html

Limitations of Addresses and Address Sets in a Security Policy: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/address-address-sets-limitations.html

Understanding Negated Address Support: https://www.juniper.net/documentation/en_US/junos/topics/concept/negated-address-support-understanding.html

Security Policies Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-overview.html

Understanding Security Policy Rules: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-rule-understanding.html

Understanding Security Policy Elements: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-element-understanding.html

Understanding Security Policies for Self Traffic: https://www.juniper.net/documen-tation/en_US/junos/topics/concept/security-policy-for-self-traffic-understanding.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/srx-series/index.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/srx-series/index.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-basic-zone-interface.html





https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-and-interface-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-and-interface-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-host-inbound-traffic-how-to-control-based-on-traffic-type-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-inbound-traffic-how-to-control-based-on-protocol-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-functional-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-functional-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-global-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-book-global-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-set-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/zone-address-set-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/address-address-sets-limitations.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/negated-address-support-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/negated-address-support-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-element-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-element-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-for-self-traffic-understanding.html




Global Policy Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-global-policy-overview.html

Understanding Security Policy Ordering: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-ordering-understanding.html

Best Practices for Defining Policies on SRX Series Devices: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-memory-opti-mizing.html

Security Policy Schedulers Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-scheduler-overview.html

Understanding User Role Firewalls: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-firewall-understanding.html

User Role Retrieval and the Policy Lookup Process: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-policy-lookup-understanding.html

Understanding the User Identification Table: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/security-user-role-uit-understanding.html

Understanding Searching and Sorting Audit Log: https://www.juniper.net/docu-mentation/en_US/junos/topics/concept/search-and-sort-functionality-under-standing.html

Understanding Packet Flow Alarms and Auditing: https://www.juniper.net/documentation/en_US/junos/topics/concept/packet-flow-alarm-audit-under-standing.html

Security Policy Applications Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-overview.html

Policy Application Sets Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-set-overview.html

Understanding Custom Policy Applications: https://www.juniper.net/documenta-tion/en_US/junos/topics/reference/general/policy-application-custom-under-standing.html

Custom Application Mappings: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-custom-mapping.html

Understanding Policy Application Timeout Configuration, Lookup, and Contin-gencies: https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-timeout-configuration-lookup-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-contingency-understanding.html

Understanding Internet-Related Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-applica-tion-predefined-internet-related-understanding.html

Understanding Microsoft Predefined Policy Applications:https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-pre-defined-microsoft-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-global-policy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-global-policy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-ordering-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-ordering-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-policy-memory-optimizing.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-scheduler-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-scheduler-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-firewall-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-firewall-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-policy-lookup-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-uit-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/security-user-role-uit-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/search-and-sort-functionality-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/packet-flow-alarm-audit-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-set-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-set-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-custom-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-custom-mapping.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-custom-mapping.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-timeout-configuration-lookup-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-application-timeout-configuration-lookup-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-internet-related-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-microsoft-understanding.html



99 Appendix: links and URls

Understanding Dynamic Routing Protocols Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-dynamic-routing-protocol-understanding.html

Understanding Streaming Video Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-applica-tion-predefined-streaming-video-understanding.html

Understanding Sun RPC Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-pre-defined-sun-rpc-understanding.html

Understanding Security and Tunnel Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-applica-tion-predefined-security-tunnel-understanding.html

Understanding IP-Related Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-ip-related-understanding.html

Understanding Instant Messaging Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-applica-tion-predefined-instant-messaging-understanding.html

Understanding Management Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-management-understanding.html

Understanding Mail Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-pre-defined-mail-understanding.html

Understanding UNIX Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-pre-defined-unix-understanding.html

Understanding Miscellaneous Predefined Policy Applications: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-miscellaneous-understanding.html

Understanding the ICMP Predefined Policy Application: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-icmp-predefined-policy-application-understanding.html

NAT Overview: https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-nat.html

Understanding NAT Rule Sets and Rules: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/nat-security-rule-set-and-rule-understanding.html

Understanding Source NAT: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-understanding.html

Understanding Central Point Architecture Enhancements for NAT: https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-cp-en-hancements-for-nat.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-dynamic-routing-protocol-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-streaming-video-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-sun-rpc-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-security-tunnel-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-ip-related-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-instant-messaging-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-management-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-mail-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-unix-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-predefined-miscellaneous-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/reference/general/policy-application-icmp-predefined-policy-application-understanding.html



https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-nat.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-nat.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-rule-set-and-rule-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-cp-enhancements-for-nat.html




Understanding Source NAT Rules: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-rule-understanding.html

Understanding Source NAT Pools: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-understanding.html

Understanding Source NAT Pool Capacities: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/nat-security-source-pool-capacity-understanding.html

Understanding Persistent Addresses: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-persistent-address-understanding.html

Understanding Source NAT Pools with Address Pooling: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-address-pooling-understanding.html

Understanding Source NAT Pools with Address Shifting: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-address-shifting-understanding.html

Understanding Source NAT Pools with PAT: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/nat-security-source-pool-with-pat-understanding.html

Understanding Source NAT Pools Without PAT: https://www.juniper.net/documen-tation/en_US/junos/topics/concept/nat-security-source-pool-without-pat-under-standing.html

Understanding Source NAT Pools with Shared Address: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-shared-ad-dress-understanding.html

Understanding Destination NAT: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-understanding.html

Understanding Destination NAT Address Pools: https://www.juniper.net/documen-tation/en_US/junos/topics/concept/nat-security-destination-address-pool-under-standing.html

Understanding Destination NAT Rules: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-rule-understanding.html

Understanding Static NAT: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-understanding.html

Understanding Static NAT Rules: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-rule-understanding.html

Understanding Persistent NAT and NAT64: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/nat-security-source-persistent-nat-understand-ing.html

Understanding Session Traversal Utilities for NAT (STUN) Protocolhttps://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-ses-sion-traversal-utilities-for-nat-protocol-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-capacity-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-persistent-address-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-address-pooling-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-address-shifting-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-with-pat-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-without-pat-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-shared-address-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-address-pool-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-destination-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-static-rule-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-persistent-nat-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-session-traversal-utilities-for-nat-protocol-understanding.html



101 Appendix: links and URls

Understanding NAT64 IPv6 Prefix to IPv4 Address-Persistent Translation: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-persistent-address-understanding.html

Persistent NAT Hairpinning Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-hairpinning-overview.html

IPv6 NAT Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-overview.html

IPv6 NAT PT Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-protocol-translation-overview.html

Understanding Interfaces: https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/interfaces-overview.html

Network Interfaces: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-network.html

Services Interfaces: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-service.html

Special Interfaces: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-special.html

Interface Naming Conventions: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-naming-convention.html

Understanding the Data Link Layer: https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-data-link-layer-understanding.html

Understanding Interface Logical Properties: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/interface-security-logical-property-understand-ing.html

Understanding Protocol Families: https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-logical-property-protocol-family-under-standing.html

Understanding IPv4 Addressing: https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-logical-property-ipv4-addressing-under-standing.html

Understanding IPv6 Addressing: https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-flow-ipv6-address-types.html

Understanding Interface Physical Properties: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/interface-security-physical-property-under-standing.html

Firewall User Authentication for Security Devices: https://www.juniper.net/docu-mentation/en_US/junos/information-products/pathway-pages/security/security-authentication-firewall.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-overview.html

SSL Proxy Overview: https://www.juniper.net/documentation/en_US/junos/topics/concept/ssl-proxy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-security-source-pool-persistent-address-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-hairpinning-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-hairpinning-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-protocol-translation-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-nat-protocol-translation-overview.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/interfaces-overview.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/interfaces-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-network.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-network.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-service.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-service.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-special.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-special.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-naming-convention.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/general/interface-security-naming-convention.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-data-link-layer-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-data-link-layer-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-logical-property-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-logical-property-protocol-family-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-logical-property-ipv4-addressing-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-flow-ipv6-address-types.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ipv6-flow-ipv6-address-types.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-security-physical-property-understanding.html



https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-authentication-firewall.html





https://www.juniper.net/documentation/en_US/junos/topics/concept/ssl-proxy-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/ssl-proxy-overview.html


Understanding Pass-Through Authentication: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/firewall-user-authentication-pass-through-un-derstanding.html

Understanding Web Authentication: https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-web-understanding.html

Understanding External Authentication Servers: https://www.juniper.net/docu-mentation/en_US/junos/topics/concept/firewall-user-authentication-external-authentication-server-understanding.html

Attack Detection and Prevention Overview: https://www.juniper.net/documenta-tion/en_US/junos/topics/concept/attack-detection-prevention-overview.html

The Network Design and Architecture Center

The Network Design and Architecture Center provides all the resources you need to design and deploy your network, all in one place.


https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-pass-through-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-web-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-web-understanding.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-user-authentication-external-authentication-server-understanding.html



https://www.juniper.net/documentation/en_US/junos/topics/concept/attack-detection-prevention-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/attack-detection-prevention-overview.html


Documents

Understanding Security Building Blocks - Juniper …...UNDERSTANDING SECURITY BUILDING BLOCKS By the writers and editors of the Juniper Networks TechLibrary Firewalls were one of the