Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

TCP Sessions

To send data over TCP in a network, a three-way handshake session establishment process is followed. There is a process to start a session, and there is also a process to terminate the TCP session. This topic helps you to understand the process involved in processing a TCP session.

Understanding TCP Session Checks per Policy

By default, the TCP SYN check and sequence check options are enabled on all TCP sessions. The Junos operating system (Junos OS) performs the following operations during TCP sessions:

  • Checks for SYN flags in the first packet of a session and rejects any TCP segments with non- SYN flags that attempt to initiate a session.

  • Validates the TCP sequence numbers during stateful inspection.

The TCP session check per-policy feature enables you to configure SYN and sequence checks for each policy. Currently, the TCP options flags, no-sequence-check and no-syn-check, are available at a global level to control the behavior of services gateways. To support per-policy TCP options, the following two options are available:

  • sequence-check-required: The sequence-check-required value overrides the global value no-sequence-check.

  • syn-check-required: The syn-check-required value overrides the global value no-syn-check.

To configure per-policy TCP options, you must turn off the respective global options; otherwise, the commit check will fail. If global TCP options are disabled and SYN flood protection permits the first packet, then the per-policy TCP options will control whether SYN and/or sequence checks are performed.

Note:

  • The per-policy syn-check-required option will not override the behavior of the set security flow tcp-session no-syn-check-in-tunnel CLI command.

  • Disabling the global SYN check reduces the effectiveness of the device In defending against packet flooding.

CAUTION:

Disabling the global SYN check and enforcing the SYN check after policy search will greatly impact the number of packets that the router can process. This in turn will result in intense CPU operations. When you disable global SYN check and enable per-policy SYN check enforcement, you should be aware of this performance impact.

Disabling TCP Packet Security Checks

On an SRX Series Firewall, you can disable security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations.

The no-sequence-check option disables TCP sequence checks. It also increases the throughput.

The set security flow tcp-session no-sequence-check command disables the TCP sequence checks on all TCP sessions in default or hash-based modes.

Example: Configuring TCP Packet Security Checks Per Policy

This example shows how to configure TCP packet security checks for each policy in the device.

Requirements

Before you begin, you must disable the tcp options, tcp-syn-check, and tcp-sequence-check that are configured at global level. .

Overview

The SYN and sequence check options are enabled by default on all TCP sessions. In environments that need to support large file transfers, or that run nonstandard applications, it might be necessary to configure sequence and sync checks differently for each policy. In this example, you configure sequence and sync check for policy pol1.

Configuration

Procedure

Step-by-Step Procedure

To configure TCP packet security checks at the policy level:

  1. Configure the checking for the TCP SYN bit before creating a session.

  2. Configure the checking for sequence numbers in TCP segments during stateful inspection.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify that the configuration is working properly, enter the show security policies detail command.

Example: Disabling TCP Packet Security Checks for SRX Series Services Gateways

This example shows how to disable TCP packet security checks in the device.

Requirements

Before you begin, understand the circumstances for disabling TCP packet security checks. .

Overview

Junos OS provides a mechanism for disabling security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations. During no-SYN-check the Junos OS does not look for the TCP SYN packet for session creation. No-sequence check disables TCP sequence checking validation. Also, increases throughput. SYN check and sequence check are enabled by default. The set security flow command disables TCP SYN checks and TCP sequence checks on all TCP sessions thus reduces security. This may be required in scenarios with customers like big transfer files, or with applications that do not correctly work with standards.

Configuration

Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To disable TCP packet security checks:

  1. Disable the checking of the TCP SYN bit before creating a session.

  2. Disable the checking of sequence numbers in TCP segments during stateful inspection.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security flow command.

Example: Setting the Maximum Segment Size for All TCP Sessions for SRX Series Firewalls

This example shows how to set the maximum segment size for all TCP sessions for SRX Series Firewalls.

Requirements

Before you begin, understand the circumstances for setting the maximum segment size.

Overview

You can terminate all TCP sessions by changing the TCP maximum segment size (TCP-MSS). To diminish the likelihood of fragmentation and to protect against packet loss, you can use the tcp-mss to specify a lower TCP MSS value. This applies to all TCP SYN packets traversing the router’s ingress interfaces whose MSS value is higher than the one you specify.

If the DF bit is set, it will not fragment the packet and Junos OS will send ICMP error type 3 code 4 packet to the application server (Destination Unreachable; Fragmentation Needed and DF set). This ICMP error message contains the correct MTU (as defined in tcp-mss) to be used by the application server, which should receive this message and adjust the packet size accordingly. This is specifically required with VPNs, as IPsec has added packet overhead; thus tcp-mss must be lowered appropriately.

Note:

When running SRX Series Firewalls in packet mode, you use the set system internet-options tcp-mss to adjust the TCP-MSS value. All ports are affected by the TCP-MSS configuration; you cannot exclude a particular port. When running SRX Series Firewalls in flow mode, although you can use the set system internet-options tcp-mss , we recommend using only the set security flow tcp-mss to adjust the TCP-MSS value. If both statements are configured, the lower of the two values will take effect.

Configuration

Procedure

Step-by-Step Procedure

To configure the maximum segment size for all TCP sessions:

  1. Set the TCP maximum segment size for all TCP sessions.

  2. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

Verification

To verify the configuration is working properly, enter the show configuration security flow command from operational mode.

TCP Out-of-State Packet Drop Logging Overview

Within any packet-switched network, when demand exceeds available capacity, the packets are queued up to hold the excess packets until the queue fills, and then the packets are dropped. When TCP operates across such a network, it takes any corrective actions to maintain error-free end-to-end communications.

Flow modules already support generating RTLOG for session-based events like session creation and session close. SRX Series Firewalls now support the generation of RTLOG for packet-based events like packet drop without a session existing.

SRX Series Firewalls support logging of unsynchronized TCP out-of-state packets that are dropped by the flow module.

The TCP out-of-state packet drop logging feature avoids any packet loss and enables packet recovery by logging the out-of-sync packets for error free communication, and prevents the database servers from going out of sync. This feature is built on top of the security log (RTLOG) facility.

TCP out-of-state packet drop logging supports capturing of TCP packet drop logs under the following conditions:

  • Session ages out—When there are cloud applications running on top of long TCP sessions, and when these applications do not refresh the TCP sessions after the session ages out, the TCP packets are dropped. This feature supports logging of these dropped TCP packets.

  • Unsynchronized first packets due to attacks or asymmetric routes—When you deploy SRX Series Firewalls at two sites , and when routing sometimes forces asymmetric traffic, the synchronization (SYN) packet is seen at one site but the synchronization acknowledgment (SYN_ACK) packets are seen at another site.

    This means that the SRX Series Firewall sees a TCP ACK packet for which it does not have a matching state table entry. This might occur because the connection was inactive for a period of time or the connections tables were flushed (for example, because of a policy installation or restart).

    The SYN_ACK packets that are seen at another site in this case were denied by the SRX Series Firewall but were not logged. This feature supports logging of the denied SYN_ACK packets.

  • Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)—When an SRX Series Firewall detects a sequence failure, if the device is in TCP four-way close state but receives SYN packets, or if there is a three-way handshake failure, the SRX Series Firewall drops the TCP packets and these dropped packets are logged.

Note:

The unsynchronized TCP out-of-state packet drop log is a packet-based log, not a session-based log.

TCP out-of-state packet drop logging is designed with a throttle mechanism to protect CPU from being attacked, and within each throttle interval some logs can be dropped.

Only TCP out-of-state packets dropped by Flow module are logged. TCP packets dropped by TCP-proxy and IDP are not logged.

Understanding TCP Out-of-State Packet Drop Logging

To understand the implementation of TCP out-of-state packet drop logging, consider that you deploy SRX Series Firewalls at two sites and that routing sometimes forces asymmetrical traffic, where the SYN packet is seen at one site but the SYN_ACK packet is seen at another site. The SYN_ACK packet in this case would be denied but not logged. The TCP out-of-state packet drop logging feature provides visibility into these unsynchronized packet drops.

Consider the scenario where databases within the data center keep their TCP sockets open, with no keepalives being sent. If no data is being transmitted, the SRX Series Firewall will timeout the sessions. Although the databases will send some data through that TCP socket, when the traffic reaches the SRX Series Firewall, the session is no longer there and the packet is dropped, but not logged. These out-of-state TCP packets that are dropped are now logged by the SRX Series Firewall.

Supported TCP Out-of-State Logging Features

TCP out-of-state logging supports the following features:

  • A packet filter component to filter target traffic.

  • A throttle component to protect CPU from being overloaded by log messages.

  • Flexibility to change the log generation rate.

Packet Filter Component

The logging filter leverages the current flow trace filter. It provides different ways to filter traffic. You must configure the filters to generate packet logs, otherwise logs will not be triggered.

This filter functionality avoids enabling logs unexpectedly. The maximum filters supported are 64.

Use the set security flow packet-log packet-filter <filter-name> command to enable the related filter components you want.

Throttle Component

Logging every TCP out-of-state packet can overload the device when traffic is heavy or when an attack occurs. If the CPU is idle and you want to log as many messages as possible, then this could lead to CPU overload.

The throttle mechanism allows you to configure the throttle interval from the CLI, so you can protect your CPU from being overloaded.

A hash table is introduced to map your logged data. The hash key is generated with the source-IP address, destination-IP address, source port, and destination port.

Within each throttle interval, only a limited number (more than one) of messages will be sent to RTLOG. The remaining log messages will be throttled.

The default throttle interval is 1 second. The throttle interval (at the millisecond level) needs to be configured as a power of two or zero (0, 1, 2, 4, 8, 16 … 2^N).

When the throttle interval is configured as 0, no throttle mechanism will be involved. This is suitable for scenarios where traffic is very light and you want to record all the packet drop logs.

Configuration of the throttle interval as 2^N makes the throttle mechanism lockless and provides good log capture performance.

Flexibility for Changing the Log Generation Rate

Based on the throttle interval set, the log generation rate can be modified and managed.

This means that within each 32-millisecond (ms) interval, a limited number of logs could be generated and the remaining could be dropped. We recommend that you configure the interval as (0, 1, 2, 4, 8, 16, 32 … 2^N).

If the input value is not aligned to 2^N, it will be aligned to 2^N automatically during flow processing. For example, if you configure a 10-ms interval it will be aligned to an 8-ms interval automatically.

Understanding How Preserving Incoming Fragmentation Characteristics Can Improve Throughput

This topic covers the benefits of using the SRX Series Firewall to preserve the characteristics of incoming packet fragments.

When data is sent from one host to another, it is transmitted as a series of packets. Performance is improved and network resources are conserved when packets of the largest size can transit the path from the source node to the destination node without being fragmented at any link in the datapath. When a packet must be fragmented into smaller packets to transit a link in the path because the packet is larger than that of the maximum transmission unit (MTU) established for that link, each of the resulting fragments must contain packet header information, in addition to the payload, or data. The increased overhead can lower throughput and degrade network performance. Also, the packet fragments must be reassembled at the destination node, which consumes additional network resources.

On the other hand, network resources are wasted when a host sends packets that are much smaller than the path MTU (path maximum transmission unit), resulting in suboptimal throughput. The path MTU discovery process works to discover the optimal MTU size for fragments that transit the datapath from the source node to the destination node for a session. The optimal packet size, then, is that of the path MTU. Fragmentation occurs when the size of a packet exceeds the path MTU.

If application-layer services are configured on the SRX Series Firewall, packet fragments at the ingress interface must be reassembled before the services can be applied and the content inspected. These reassembled packet fragments must be broken down again before the data is transmitted out the egress interface. Normally, it is the MTU size of the egress interface that determines the size of fragments transmitted out the SRX Series Firewall to the next link. It could be the case that the egress MTU size on the SRX Series Firewall is larger than the path MTU, which, again, would result in packet fragmentation in the datapath, reducing performance or causing packet drop. Packet fragments must be small enough to transit every link in the path from source to destination.

By default, the SRX Series Firewall uses the MTU size configured for the egress interface to determine the size for packet fragments it transmits. However, if you enable the feature for preserving incoming fragment characteristics, the SRX Series Firewall detects and saves the size of incoming packet fragments.

To diminish the likelihood of packet fragmentation in the datapath, the SRX Series Firewall keep track of and adjust the egress MTU for that flow. It identifies the maximum size of all incoming fragments. It uses that information in conjunction with the existing MTU of the egress interface to determine the correct MTU size for fragmented packets sent out the egress interface. The SRX Series Firewall compares the two numbers. It takes the smaller number and uses it for the egress interface MTU size.

Configure the device using the set security flow preserve-incoming-frag-size command to enable the feature that takes into account the size of incoming packet fragments.

Table 1 summarizes how the SRX Series egress MTU size is determined.

Table 1: How the Final Egress MTU Size for Fragments Exiting the SRX Series Firewall Is Determined

Incoming Fragment Size

Existing Egress MTU Size

Final Egress MTU Size

If the largest fragment is

smaller than the existing egress MTU size

largest incoming fragment size is used.

If the largest fragment is

larger than the existing egress MTU size

existing egress interface MTU is used.
Note:

This feature is supported on SRX Series Firewalls. It supports through-traffic and traffic exiting a tunnel. It is applies to both IPv4 and IPv6 traffic.

The following two considerations affect fragment size:

  • For stream-based applications, such as Content Security and ALG, the applications themselves could change or reassemble packets even if there were no fragments received. In this case, the existing egress interface MTU is used.

  • When a path MTU discovery packet is delivered to a session, the path MTU for that session is reset to the value established by the path MTU packet.

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-D100
Configure the device using the set security flow preserve-incoming-frag-size command to enable the feature that takes into account the size of incoming packet fragments.