> Source: [sk39259](https://support.checkpoint.com/results/sk/sk39259)

# sk39259 - Security Server does not allow RFC 1644 compliant TCP connections

| Property | Value |
|----------|-------|
| Solution ID | sk39259 |
| Date Created | 2009-04-14 |
| Last Modified | 2023-03-21 |
| Technical Level | General |

## Symptoms

- It appears that the Security Server implementation in FW-1 NG FP3 HF2is not compliant with T/TCP connections. This appears to be for all Security Servers (WWW, SMTP, FTP). The solution to this issue is to disable RFC 1644 support at the IPSO level.

<br />

<br />

This issue is typially manifested as an inability of the firewall to pass particular types of traffic, while occasionally producing the following errors in ahttpd.elg:

<br />

<br />

Error : handle_write_error : sn = 1571000, sock = 254, buf_len = 210, len = -1 : failed to write headers: Broken pipe

<br />

Occasionally, this error is produced simply by a client breaking a connection prematurely. However, in this case, this error is coupled by a *specific* web or ftp or smtp address being unavailable, on a continuous basis  

This issue has been confirmed in the FP3 HF2 release of FW-1, and most likely exists in all 4.1 and NG releases of FW-1. The issue has not been tested in NGAI.

## Solution

Generally speaking, RFC 1644 is designed to reduce overhead with TCP connections by essentially allowing "partial close" connection states. These states are denoted by special flag bit combinations in the SYN packets of a TCP connection. Essentially, multiple TCP sessions are embedded within a single three-way handshake.

When an RFC 1644-compliant originator send one of these "embedded" sessions within an already-established TCP session, the packets are tagged with a "CC" identifier in the TCP options field. IPSO's TCP stack comprehends these flags, and thus does not drop the RFC 1644-compliant packets when they arrive. However, when these packets are run through the INSPECT engine, and arrive at the SmartDefense module, they are killed by the security server processes.

By disabling RFC 1644 support in IPSO, these packets are dropped before they ever arrive at the SmartDefense module. Because IPSO never negotiates the T/TCP connection with the originating client, the client will not attempt to embed secondary sessions within the primary "3-way handshake" session.

To disable RFC 1644 support in IPSO, please use the command:

nokia\[admin\]# **ipsctl -w net:ip:tcp:enable_rfc1644 0**

To re-enable it, use:

**nokia\[admin\]# ipsctl -w net:ip:tcp:enable_rfc1644 1**

Please note that this change will need to be performed on all members of a VRRP pair or IPSO Cluster. To make this change permanent, add the command to the /var/etc/rc.local file.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content