Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Monitoring Security Flow Sessions

This topic covers information for monitoring, displaying and verifying of flow sessions using operational mode commands. Thus, you can debug without having to commit or modify your running configuration.

Monitoring Security Flow Sessions Overview

Junos OS allows you to configure and start the monitoring of flow sessions using operational mode commands. Thus, you can debug without having to commit or modify your running configuration. This approach can be especially useful when you do not want to change the state of your device by committing the configuration to turn on trace options.

To configure flow session monitoring, you must define flow filters, specify the output file, and start monitoring. Flow session monitoring does not start unless a filter (at least one) and an output file are specified. Also, defining the filters themselves does not trigger monitoring. You have to explicitly use the monitor security flow start and monitor security flow stop commands to enable and disable monitoring, respectively.

  • Define flow filters—Define the flow sessions that you want to monitor using combinations of match criteria, such as source address, destination address, source port, destination port, IP protocol number, name of the incoming or outgoing interface, and the logical system name. You can delete filters using the clear monitor security flow filter command.

    Note:

    Unlike filters defined in the configuration mode, filters defined using operational mode commands are cleared when you reboot your system.

  • Specify the output file—Create an output file in which the security flow monitoring information is to be saved. This file is saved in the /var/log/ directory. You can view the contents of this file by using the show log filename command. Use the monitor security flow file command to specify output file characteristics, such as its maximum size, maximum number, and type.

  • Start monitoring—Use the monitor security flow start command to start monitoring. Once monitoring starts, any traffic that matches the filters is saved in the specified output file in the /var/log/ directory. The basic-datapath flag is the default flag and turns on as monitoring starts.

    Use the monitor security flow stop command to stop monitoring. Once monitoring stops, the basic-datapath flag is cleared.

  • Display monitoring flow information—Use the show monitoring security flow command to display details about the monitoring operation.

Note:

You can configure flow session monitoring and debugging by using the monitoring operational mode commands and flow traceoptions configuration statements. These two operations cannot run in parallel. When you turn on security flow monitoring, the flow traceoption session is blocked and when the flow traceoption session is running, monitoring of the flow session is blocked.

Understanding How to Obtain Session Information for SRX Series Firewalls

You can obtain information about the sessions and packet flows active on your device, including detailed information about specific sessions. (The SRX Series Firewall also displays information about failed sessions.) You can display this information to observe activity and for debugging purposes. For example, you can use the show security flow session command:

  • To display a list of incoming and outgoing IP flows, including services

  • To show the security attributes associated with a flow, for example, the policies that apply to traffic belonging to that flow

  • To display the session timeout value, when the session became active, for how long it has been active, and if there is active traffic on the session

Note:

If an interface NAT is configured and sessions are set up with the NAT using that interface IP address, whenever the interface IP address changes, the sessions set up with NAT get refreshed and new sessions will be setup with new IP address. This you can verify using show security flow session CLI command.

Session information can also be logged if a related policy configuration includes the logging option. For the flow session log on all SRX Series Firewalls, policy configuration has been enhanced. Information on the packet incoming interface parameter in the session log for session-init and session-close and when a session is denied by a policy or by the application firewall is provided to meet Common Criteria (CC) Medium Robustness Protection Profiles (MRPP) compliance:

Policy configuration—To configure the policy for the session for which you want to log matches as log session-init or session-close and to record sessions in syslog:

  • set security policies from-zone untrustZone to-zone trust zone policy policy13 match source-address extHost1

  • set security policies from-zone untrustZone to-zone trustZone policy policy13 match application junos-ping

  • set security policies from-zone untrustZone to-zone trustZone policy policy13 then permit

  • set security policies from-zone untrustZone to-zone trustZone policy policy13 then log session-init

  • set security policies from-zone untrustZone to-zone trustZone policy policy13 then log session-close

Example : Flow match policy13 will record the following information in the log:

<14>1 2010-09-30T14:55:04.323+08:00 mrpp-srx550-dut01 RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2626.192.0.2.1.40 source-address="192.0.2.1" source-port="1" destination-address="198.51.100.12" destination-port="46384" service-name="icmp" nat-source-address="192.0.2.1" nat-source-port="1" nat-destination-address="198.51.100.12" nat-destination-port="46384" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="1" policy-name="policy1" source-zone-name="trustZone" destination-zone-name="untrustZone" session-id-32="41" packet-incoming-interface="ge-0/0/1.0"] session created 192.0.2.1/1-->198.51.100.12/46384 icmp 192.0.2.1/1-->198.51.100.12/46384 None None 1 policy1 trustZone untrustZone 41 ge-0/0/1.0

<14>1 2010-09-30T14:55:07.188+08:00 mrpp-srx550-dut01 RT_FLOW - RT_FLOW_SESSION_CLOSE [junos@2626.192.0.2.1.40 reason="response received" source-address="192.0.2.1" source-port="1" destination-address="198.51.100.12" destination-port="46384" service-name="icmp" nat-source-address="192.0.2.1" nat-source-port="1" nat-destination-address=”198.51.100.12" nat-destination-port="46384" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="1" policy-name="policy1" source-zone-name="trustZone" destination-zone-name="untrustZone" session-id-32="41" packets-from-client="1" bytes-from-client="84" packets-from-server="1" bytes-from-server="84" elapsed-time="0" packet-incoming-interface="ge-0/0/1.0"] session closed response received: 192.0.2.1/1-->198.51.100.12/46384 icmp 192.0.2.1/1-->198.51.100.12/46384 None None 1 policy1 trustZone untrustZone 41 1(84) 1(84) 0 ge-0/0/1.0

Displaying Global Session Parameters for All SRX Series Services Gateways

Purpose

Obtain information about configured parameters that apply to all flows or sessions.

Action

To view session information in the CLI, enter the following command:

Meaning

The show security flow configuration command displays the following information:

  • allow-dns-reply—Identifies if unmatched incoming Domain Name System (DNS) reply packets are allowed.

  • route-change-timeout—If enabled, displays the session timeout value to be used on a route change to a nonexistent route.

  • tcp-mss—Shows the current configuration for the TCP maximum segment size value to be used for all TCP packets for network traffic.

  • tcp-session—Displays all configured parameters that control session parameters.

  • syn-flood-protection-mode—Displays the SYN Proxy mode.

Displaying a Summary of Sessions for SRX Series Services Gateways

Purpose

Determine the kinds of sessions on your device, how many of each kind there are—for example, the number of unicast sessions and multicast sessions—the number of failed sessions, the number of sessions that are currently used and the maximum number of sessions that the device supports. This command also displays the details of the sessions that are currently used. For example, valid sessions, pending sessions, invalidated sessions and sessions in other states.

Action

To view session summary information in the CLI, enter the following CLI command:

Displaying Session and Flow Information About Sessions for SRX Series Services Gateways

Purpose

Display information about all sessions on your device, including the session ID, the virtual system the session belongs to, the Network Address Translation (NAT) source pool (if source NAT is used), the configured timeout value for the session and its standard timeout, and the session start time and how long the session has been active. The display also shows all standard flow information, including the direction of the flow, the source address and port, the destination address and port, the IP protocol, and the interface used for the session.

Action

To view session flow information in the CLI, enter the following command:

Displaying Session and Flow Information About a Specific Session for SRX Series Services Gateways

Purpose

When you know the session identifier, you can display all session and flow information for a specific session rather than for all sessions.

Action

To view information about a specific session in the CLI, enter the following command:

Using Filters to Display Session and Flow Information for SRX Series Services Gateways

Purpose

You can display flow and session information about one or more sessions by specifying a filter as an argument to the show security flow session command. You can use the following filters: application, destination-port, destination-prefix, family, idp, interface, nat, protocol, resource-manager, session-identifier, source-port, source-prefix and tunnel. The device displays the information for each session followed by a line specifying the number of sessions reported on. Here is an example of the command using the source-prefix filter.

Action

To view information about selected sessions using filters in the CLI, enter the following command:

Information Provided in Session Log Entries for SRX Series Services Gateways

Session log entries are tied to policy configuration. Each main session event—create, close, and deny—will create a log entry if the controlling policy has enabled logging.

Different fields are logged for session create, session close, and session deny events as shown in Table 1, Table 2, and Table 3. The same field name under each type indicates that the same information is logged, but each table is a full list of all data recorded for that type of session log.

The following table defines the fields displayed in session log entries.

Table 1: Session Create Log Fields

Field

Description

source-address

Source IP address of the packet that created the session.

source-port

Source port of the packet that created the session.

destination-address

Destination IP address of the packet that created the session.

destination-port

Destination port of the packet that created the session.

service-name

Application that the packet traversed (for example, “junos-telnet” for Telnet traffic during the session allowed by a policy that permits native Telnet).

nat-source-address

The translated NAT source address if NAT was applied; otherwise, the source address as above.

nat-source-port

The translated NAT source port if NAT was applied; otherwise, the source port as above.

nat-destination-address

The translated NAT destination address if NAT was applied; otherwise, the destination address as above.

nat-destination-port

The translated NAT destination port if NAT was applied; otherwise, the destination port as above.

src-nat-rule-name

The source NAT rule that was applied to the session (if any). If static NAT is also configured and applied to the session and if source address translation takes place, then this field shows the static NAT rule name.*

dst-nat-rule-name

The destination NAT rule that was applied to the session (if any). If static NAT is also configured and applied to the session and if destination address translation takes place, then this field shows the static NAT rule name.*

protocol-id

The protocol ID of the packet that created the session.

policy-name

The name of the policy that permitted the session creation.

session-id-32

The 32-bit session ID.

* Note that some sessions might have both destination and source NAT applied and the information logged.

Starting with Junos OS Release 12.1X47-D20 and Junos OS Release 17.3R1, the system log includes information about NAT rule type. Two new src-nat-rule-type and dst-nat-rule-type fileds are introduced in the NAT rule session.

Table 2: Session Close Log Fields

Field

Description

reason

The reason the session was closed.

source-address

Source IP address of the packet that created the session.

source-port

Source port of the packet that created the session.

destination-address

Destination IP address of the packet that created the session.

destination-port

Destination port of the packet that created the session.

service-name

Application that the packet traversed (for example, “junos-telnet” for Telnet traffic during the session allowed by a policy that permits native Telnet).

nat-source-address

The translated NAT source address if NAT was applied; otherwise, the source address as above.

nat-source-port

The translated NAT source port if NAT was applied; otherwise, the source port as above.

nat-destination-address

The translated NAT destination address if NAT was applied; otherwise, the destination address as above.

nat-destination-port

The translated NAT destination port if NAT was applied; otherwise, the destination port as above.

src-nat-rule-name

The source NAT rule that was applied to the session (if any). If static NAT is also configured and applied to the session and if source address translation takes place, then this field shows the static NAT rule name.*

dst-nat-rule-name

The destination NAT rule that was applied to the session (if any). If static NAT is also configured and applied to the session and if destination address translation takes place, then this field shows the static NAT rule name.*

protocol-id

The protocol ID of the packet that created the session.

policy-name

The name of the policy that permitted the session creation.

session-id-32

The 32-bit session ID.

packets-from-client

The number of packets sent by the client related to this session.

bytes-from-client

The number of data bytes sent by the client related to this session.

packets-from-server

The number of packets sent by the server related to this session.

bytes-from-server

The number of data bytes sent by the server related to this session.

elapsed-time

The total session elapsed time from permit to close, given in seconds.

unset

During the session creation, you can set the session close reason as unset.

The session closes with the reason unset if the session installation on the control point is not successful. The reason for session installation varies, for example, nonavailability of memory for nonmanagement session installation.

TCP CLIENT RST

The session was closed by a TCP reset packet sent to it from the client.

TCP SERVER RST

The session was closed by a TCP reset packet sent to it from the server.

TCP FIN

FIN received from either end.

response received

Response received for a packet request (for example, ICMP req-reply).

ICMP error

ICMP error received.

aged out

Session aged out was reached.

ALG

ALG errors closed the session (for example, remote access server (RAS) maximum limit reached).

HA

HA message closed the session.

idle Timeout

There was no traffic for the session before the configured age-out time was reached.

auth

Authentication failed.

IDP

IDP closed the session because of security module (SM) internal error.

synproxy failure

SYN proxy failure closed the session.

synproxy limit

Reason for failure in allocating minor session, need to free original session.

parent closed

Parent session closed.

CLI

Session cleared by a CLI .

CP NACK

CP NACK response received.

CP delete

CP ACK deletion closed the session.

policy delete

Corresponding policy marked for deletion.

fwd session

Session closed because of forwarding session deletion.

multicast route change

Session closed because multicast route changed.

first path reroute, session recreated

The first path is rerouted and session is re-created.

source NAT allocation failure

SPU received ACK message from the central point but failed to receive the DIP resource. Therefore this packet is dropped and the session is closed.

other

Session closed because of all other reasons (for example, the pim reg tun needed refreshing).

error create IKE pass-through template

IKE pass-through template creation errors.

IKE pass-through child session ageout

Session is deleted because the IKE pass through template session has no child.

sess timeout on pending state

Pending session closed because time out timer reached the pending state.

unknown

Session closed because of unknown reasons.

* Note that some sessions might have both destination and source NAT applied and the information logged.
Table 3: Session Deny Log Fields

Field

Description

source-address

Source IP address of the packet that attempted to create the session.

source-port

Source port of the packet that attempted to create the session.

destination-address

Destination IP address of the packet that attempted to create the session.

destination-port

Destination port of the packet that attempted to create the session.

service-name

Application that the packet attempted to traverse.

protocol-id

The protocol ID of the packet that attempted to create the session.

icmp-type

The ICMP type if the denied packet was ICMP configured; otherwise, this field will be 0.

policy-name

The name of the policy that denied the session creation.

Error Handling Extensions

Understanding Chassis Manager FPC Fault Detection and Error Handling Enhancements

The Junos OS Routing Engine and microkernel error detection and management feature on the SRX5400, SRX5600, and SRX5800 devices enables the Routing Engine and the ukernel to accumulate and store the history of all reported error activity and counters for various severity levels. You can configure how errors are handled and specify the severity levels and the actions to perform when an error is detected and a threshold is reached. You can generate and display reports for encountered errors based on stored information.

Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, error detection enhancements are provided that detect additional errors on IOCs and SPCs and provide enhanced error management. This implementation extends the error detection and management covered in the show chassis fpc error topic.

Note:

This feature is not supported on Routing Engine version 1.

Error Handling on IOCs and SPCs

Starting with Junos OS Release 15.1-X49-D50 and Junos OS Release 17.3R1, the error management enhancements are supported on IOC2 and IOC3 I/O cards (IOCs) and SPC2 Services Processing Cards (SPCs). Some enhancement functions are particular to either the IOC2 and the IOC3 or the SPC2 FPCs, and the differences are called out in this topic.

Error Detection and Management

Error management entails:

  • Detecting an error.

    Junos OS monitors the chassis component state to detect a set of error conditions. A detected error can belong to one of the preconfigured error severity levels:

    • Fatal

    • Major

    • Minor

  • Identifying the action to take.

    When an error occurs, the system identifies the action to take based on the severity level of the error and the thresholds set and met.

    An FPC maintains a set of error counters for each error severity level. An error counter set consists of a counter that is cumulative across all errors and counters for individual errors and types. It is this information that is stored in the Routing Engine. Each occurrence counter is associated with an error occurrence threshold. There are two threshold levels: one based on the type and the other on severity.

  • Executing the action.

    For these enhancements, the preconfigured actions that you can direct the device to take when the Routing Engine’s error occurrence count for a given security level reaches the configured threshold are:

    • Reset

    • Offline

    • Alarm

    • Get-state

    • Log

CAUTION:

Take care when setting the fault handling actions for SPC2 cards on the SRX5000 line of devices. Consider that if you set the fault handling action on an SPC2 card to offline or reset, when the card is either taken offline or the reboot occurs, the chassis daemon (chassisd) will reboot all of its FPC cards, both SPCs and IOCs—that is, the entire chassis will be rebooted.

Error Detection Processes

With these enhancements, the following error detection processes are enabled and supported:

  • Error management on the Routing Engine version 2.

  • Error management on ukernel modules on SPC2 cards.

  • Error management on the IOC2 and IOC3 cards.

  • Driver checks for datapath error detection of wedge conditions.

    Note:

    Wedge condition detection for the Trinity Offload Engine driver is supported only on SPC2 cards. That is, it is not supported on the IOC2 and IOC3 cards.

  • Wedge detection for host loopback.

    Note:

    Wedge condition detection for host loopback is supported only on SPC2 cards. That is, it is not supported on the IOC2 and IOC3 cards.

  • Chassis Manager fabric error detection.

  • Control path error detections on IOC2 and IOC3 cards.

Integration with Chassis Cluster

In a chassis cluster environment, when an alarm is raised for the first time because of a major or a fatal error, a Redundancy Group 1 (RG1) switchover is triggered. This is the standard behavior on SRX Series Firewalls, and it remains unchanged. However, with these enhancements, the alarm is added to the default fault handling action list for a fatal error. Adding an alarm to the default fault handling list allows the chassis alarm to trigger the RG1 switchover as soon as the fatal error is detected.

Wedge Detection, Reporting, and Management

A wedge condition is caused by an error that blocks network traffic.

This feature detects several types of wedge conditions. It:

  • Determines if the wedge is transient or irreversible.

  • Records the wedge conditions in statistics and syslogs.

  • Alerts network administrators to irreversible wedges by raising a chassis alarm on the Routing Engine.

  • Verifies that the following datapath error detections are enabled for the IOC2, IOC3, and SPC2 cards:

    • Wedge detection for XM driver

    • Wedge detection for LU driver

    • Wedge detection for XL driver

    • Wedge detection for TOE driver (SPC2 only)

    • Wedge detection for host loopback (SPC2 only)

All datapath wedge conditions are detected and reported within 5 seconds. Each error detecting module records and reports the state and history of its identifiable wedge conditions.

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
15.1X49-D50
Starting with Junos OS Release 15.1-X49-D50 and Junos OS Release 17.3R1, the error management enhancements are supported on IOC2 and IOC3 I/O cards (IOCs) and SPC2 Services Processing Cards (SPCs).
15.1X49-D30
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, error detection enhancements are provided that detect additional errors on IOCs and SPCs and provide enhanced error management.
12.1X47-D20
Starting with Junos OS Release 12.1X47-D20 and Junos OS Release 17.3R1, the system log includes information about NAT rule type.