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

# sk181525 - Cleanup rule/Stealth rule drops SIP response packets

| Property | Value |
|----------|-------|
| Solution ID | sk181525 |
| Date Created | 2023-10-06 |
| Last Modified | 2024-06-05 |
| Technical Level | General |
| Products | Security Gateway, Spark Firewall (Locally Managed), Scalable Platforms |
| Versions | R81.20, R81.10.X, R81 (EOS), R81.20 |
| OS | Gaia |

## Symptoms

- * The Cleanup rule or the Stealth rule drops returning traffic for SIP. This occurs when Hide Nat is involved in the connection.

  For example, if the internal client/server sends REGISTER to the external server, the Security Gateway drops the response for this packet (401 or 200 ok, for example).

  The same occurs when an INVITE packet goes through the Security Gateway. The response to this packet is dropped.
* Drops on the Security Gateway (fw ctl zdebug + drop) show a high UDP port, while the tcpdump on the interface shows port 5060.

* The SIP handler (built-in SIP service) is used in the policy in general (meaning that even if the specific connection uses a custom SIP service, as long as there is the built-in SIP service in the policy in the other rules, it continues to enforce SIP inspection).

* Early NAT is used (verifed in kernel debugs or fw monitor in 'I' and 'o' chains).
  Early NAT "rolls" a high port in the internal chains and reverts to port 5060 on the post- outbound chain.

* Rules for the SIP connection are one-directional.

## Cause

The Security Gateway cannot find the connection in the connection table (even though the symbolic links were created), "rolls" a new early NAT port, and tries to match the "new" connection against the rulebase.  

Because the rulebase was configured as one-directional, the traffic (the response) is in a different direction and does not match the same rule, possibly matching a clean-up rule.  

**Note** : When you use hide NAT, the returning traffic sends the traffic towards the IP address of the Security Gateway. As a result, it hits a stealth rule.

<br />

## Solution

This problem was fixed. The fix is included in:

* [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 54
* [Jumbo Hotfix Accumulator for R81.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) starting from Take 141
* [Jumbo Hotfix Accumulator for R81](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81/Default.htm) starting from Take 99
* [Jumbo Hotfix Accumulator for R80.40](https://sc1.checkpoint.com/documents/Jumbo_HFA/R80.40/Default.htm) starting from Take 211

If you choose not to upgrade, as a **workaround**, reconfigure the rule to be bidirectional. Make sure this rule is above the drop rule.

---

# 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