+1-866-488-6691 Contact Us checkpoint.

com CheckMates FAQs Blog M

PRODUCTS SOLUTION SUPPORT & SERVICES PARTNERS RESOURCES

Support Center > Search Results > SecureKnowledge Details

Search Support Center

"Smart Connection Reuse" feature modifies some SYN packets

Rate This My Favorites

Solution ID sk24960
Technical Level
Product Security Gateway, ClusterXL, Cluster - 3rd party, VSX
Version All
Platform / Model All
Date Created 06-feb-2004
Last Modified 07-jul-2020

Symptoms
"SYN packet on established connection" log in SmartView Tracker.
FW Monitor shows that Security Gateway modifies a TCP [SYN] packet to a TCP [ACK] packet - between Pre-Inbound (small "i") and Post-Inbound (capital "I").

Cause
This behavior is caused by a feature that has been introduced in NG with AI R54, called "Smart Connection Reuse" that solves the connectivity problems related to the TCP [
are caused by a connection-reuse attempt.
Background:
Connection reuse can happen when the state of connection in the Security Gateway's Connections table (id 8158) does not match the actual connection state known to the C
connection using the same source IP address, source port, destination IP address, and destination port fail. This can happen in one of the two following cases:
The connection was not closed by the Client or Server
The connection was closed by the Client by sending a TCP [RST] packet that did not reach the Security Gateway

Solution
Background
In some cases, Security Gateway may encounter a TCP [SYN] packet that belongs to an already established TCP connection. This often happens when the state of the Secur
Client's real state, and Client attempts to reuse the same TCP port for a new TCP connection.
Security Gateway's Stateful Inspection includes a mechanism that attempts to maintain connectivity in TCP connection-reuse situations, by trying to probe the participating
Gateway's Connections table (id 8158), instead of dropping the TCP [SYN] packet and disrupting connectivity.
When "Smart Connection Reuse" feature is enabled (it is by default), and such a TCP [SYN] packet is encountered, Security Gateway changes it into a TCP [ACK] packet, forw
If the Server replies with a TCP [RST] packet, it means the Server is not familiar with such an existing TCP connection. Meaning, Client's TCP [SYN] packet was valid a
connection's entry, and the Client's TCP [SYN] retransmission will then start a new TCP connection.
The TCP connection is reused.
If the Server replies with a TCP [ACK] packet, it means the Server is in the middle of an established TCP connection (Server "agrees" with Security Gateway). In this c
the Client. If the original TCP [SYN] was not spoofed (i.e., Client sent it), the Client will send TCP [RST] packet followed by a new TCP [SYN] packet, and TCP connectio
The TCP connection is not reused.

This "Smart Connection Reuse" behavior is controlled by the kernel parameter fwconn_smart_conn_reuse:

Value of kernel parameter Behavior of Security Gateway

"Smart Connection Reuse" is enabled (default):

TCP [SYN] packets on established connections are converted to TCP [ACK]
fwconn_smart_conn_reuse=1
When kernel debug is enabled 'fw ctl debug -m fw + conn', the following line will be printed:
fwconn_syn_on_estab: SYN on established connection. Modifying TCP flags from SYN to ACK

"Smart Connection Reuse" is disabled:

TCP [SYN] packets on established connections are treated as out of state

"SYN packet on established connection" log is generated (in SmartView Tracker / SmartLog).
Example:
fwconn_smart_conn_reuse=0
Type: Log
Action: Drop
Protocol: tcp
Information: TCP packet out of state: SYN packet on established connection
tcp_flags: SYN

These dropped packets do not reset the idle-timer. Only legitimate packets belonging to the exist
 

Procedure
It is possible to disable the "Smart Connection Reuse" behavior on Security Gateway and treat TCP [SYN] packets on established connections as out of state.
Important Note: In topologies with a proxy server(s) behind the Security Gateway, which are chained, and there is heavy port reuse, disabling the "Smart Connection Reuse"
possibly impact the performance on the upstream Security Gateway due to multiple failed connections.
Note: In cluster environment, this procedure must be performed on all members of the cluster.

A temporary method (will only work until the next reboot, or next 'cpstop;cpstart')
1. Connect to the command line on the Security Gateway.
2. Log in to the Expert mode.
3. Disable the "Smart Connection Reuse" on-the-fly:

[Expert@HostName]# fw ctl set int fwconn_smart_conn_reuse 0

4. Verify that the new value was set:
[Expert@HostName]# fw ctl get int fwconn_smart_conn_reuse
Notes:
The change affects only new TCP connections.
The current existing connections in the Security Gateway's Connections table will continue with their original behavior until they expire from the Connections t
If an application is reusing ports at a fast enough rate, you need to implement the permanent solution below.
This temporary method does not persist after a reboot, nor after 'cpstop;cpstart' commands.

A permanent method (survives reboot and 'cpstop;cpstart')

Follow sk26202 - Changing the kernel global parameters for Check Point Security Gateway.
For Gaia / SecurePlatform OS:
1. Connect to the command line on the Security Gateway.
2. Log in to the Expert mode.

3. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not already exit):

[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf
4. Edit the $FWDIR/boot/modules/fwkern.conf file in Vi editor:
[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf
5. Add the following line (spaces and comments are not allowed):
fwconn_smart_conn_reuse=0
6. Save the changes and exit from Vi editor.
7. Check the contents of the $FWDIR/boot/modules/fwkern.conf file:

[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf

8. Reboot the Security Gateway.

9. Verify that the new value was set:

[Expert@HostName]# fw ctl get int fwconn_smart_conn_reuse

 

Additional related kernel parameters

Default
Kernel Parameter Accepted Values Value Description

fw_log_syn_on_estab
0 0 When TCP [SYN] is encountered on an established connection and "Smart Connection Reuse" is enabled, S
the Client's TCP [SYN] was out of state.
or However, the Client's TCP [SYN] was not necessarily a malicious action.
It may have been, for instance, a client application recovering from reboot.
1
This kernel parameter fw_log_syn_on_estab determines whether Security Gateway should log the previous
If fw_log_syn_on_estab=0, then such log is not generated (this is the default)

If fw_log_syn_on_estab=1, then such log is generated

Prerequisites:

fwconn_smart_conn_reuse=1 (this is the default value)

fw_log_out_of_state_tcp_syn=1 (this is the default value)
Example of a log:

Type: Log
Action: Drop
Protocol: tcp
Information: TCP packet out of state: SYN packet on established con

If "Smart Connection Reuse" is disabled, then TCP [SYN] on established connection will be dropped.
The log will be generated regardless of the value of this kernel parameter fw_log_syn_on_estab.

C [S ] C
fw_reuse_established_conn -2 -2 This is another solution for the problem of TCP [SYN] packet that matches an established TCP connection.
(0xFFFFFFFE) It is not recommended to activate the feature, because "Smart Connection Reuse" feature solves the proble

or As opposed to "Smart Connection Reuse" feature, this solution is very simple:

-1 Whenever a TCP [SYN] packet is encountered on an already established TCP connection, Security Gateway
new TCP connection entry, based on the new TCP [SYN] packet.
(0xFFFFFFFF)
When this solution is enabled, it is relatively easy for a malicious person to cut an existing TCP connection,
or destination IP address and TCP ports (no need to guess TCP sequences), and Security Gateway immediatel
data.
<Decimal_integer>
This kernel parameter fw_reuse_established_conn specifies a destination TCP port number, on which reus

Notes:
If fw_reuse_established_conn=-2, then TCP [SYN] on established connection never reuses the conne

If fw_reuse_established_conn=-1, then TCP [SYN] on established connection always reuses the conn
This is a huge security hole, but may serve as workaround for abnormal connectivity problems

When kernel debug is enabled 'fw ctl debug -m fw + conn', the following line will be p
fw_tcp_state_verification: allow_conn_reuse on established connection
If fw_reuse_established_conn=<Decimal_dest_port_number>, then TCP [SYN] on established conne
destination TCP port

It is not possible to specify more than one port number at a time

When kernel debug is enabled 'fw ctl debug -m fw + conn', the following line will be p
fw_tcp_state_verification: allow_conn_reuse on established connection

fw_accept_syn_rst -2 -2 In certain TCP stacks, a TCP [SYN-RST] packet may serve as a "hard reset" for the Server, enabling all Clie
(0xFFFFFFFE) configurations, Clients always use the same source TCP ports, until at some stage the Server stops replyin
is reached, the Client sends a TCP [SYN-RST] packet, releases the Server's "stuck" TCP connection, and is
or
This kernel parameter fw_accept_syn_rst specifies a destination TCP port, on which TCP [SYN-RST] packe
-1 Where it is allowed, previous TCP connection is deleted (if existed), and a new TCP connection is always rec
with state BOTH_FIN and without TCP sequence verification.
(0xFFFFFFFF)
Notes:
or
According to the TCP RFC, a TCP [SYN-RST] packet should be considered a regular TCP [RST]. Howe
<Decimal_integer> - TCP [SYN-RST] packet does not need to have a matching TCP sequence number.
This creates vulnerability, since a malicious person does not have to know the TCP sequence numbe
Security Gateway does not expect a TCP [SYN-ACK] to return as a reply to a TCP [SYN-RST]. If such a
message will be generated.
If fw_accept_syn_rst=-2, then TCP [SYN-RST] is not accepted

If fw_accept_syn_rst=-1, then TCP [SYN-RST] is accepted on all destination TCP ports

When kernel debug is enabled 'fw ctl debug -m fw + conn', the following line will be p
fw_tcp_state_verification: allow_conn_reuse due to SYN-RST

When kernel debug is enabled 'fw ctl debug -m fw + packval', the following line will b
asm_stateless_verifier: SYN-RST packet is accepted
If fw_accept_syn_rst=<Decimal_dest_port_number>, then TCP [SYN-RST] is accepted only on the de

It is not possible to specify more than one port number at a time

When kernel debug is enabled 'fw ctl debug -m fw + conn', the following line will be p
fw_tcp_state_verification: allow_conn_reuse due to SYN-RST

When kernel debug is enabled 'fw ctl debug -m fw + packval', the following line will b
asm_stateless_verifier: SYN-RST packet is accepted

Give us Feedback Please rate this document [1=Worst,5=Best]

Enter your comment here

Comment 

 
©1994-2020 Check Point Software Technologies Ltd. All rights reserved.
Copyright | Privacy Policy