Fix Checkpoint Logs Confusion: 'Drop' to 'Warning' for URG Flags – New Insights on Ports 1524 & 1525

[Chinmaya_Naik]

Hello Checkpoint Community,

I’m thrilled to share more findings from my ongoing research on Checkpoint firewall logs!

I’ve been investigating a confusing issue with the "Drop" label in logs when the firewall handles URG flags

I’ve found something that confuses users like someone who are new to this

I’ll explain my findings step by step, share my analysis, and propose a new improvement for Checkpoint to make logs easier to understand. I hope you’ll join me in discussing this!

What I’m Seeing in the Logs:

TCP Flags

I have a log for traffic on port 1525 (service "sqlnet2-1525") from a computer (1x.x.x.x) to a server (y.y.y.y). The log says:

• "sqlnet2-1525 Traffic Dropped from x.x.x.x:63470 to y.y.y.y due to TCP segment with urgent pointer. Urgent data indication was stripped. Please refer to sk36869."
• It also mentions "Streaming Engine: TCP Urgent Data Enforcement" and says the severity is "Informational."
• Due to TCP segment with urgent pointer. Urgent data indication was stripped. Please refer to sk36869."

Drop and accept

With lots of "Log" and "Connection" entries. Some of these are about port 1525 so some are accept connection and some are drop logs.

The fw ctl zdebug + drop command, showing drops at the kernel level. It mentions drops due to rule 93 in the "Firewall Policy Network" layer, involving my server (y.y.y.y) and a other IP address (z.z.z.z) but not also specifically for port 1525.

My Step-by-Step Research Process:

Understanding the Basics:

• A TCP segment is a small package of data, and the URG flag is like a "rush" sticker telling the server to handle some data quickly.
• Log says the firewall removed the "rush" sticker (stripped the URG flag) for port 1525 and let the rest of the package go to the server.

Checking the Log Details:

• But the log description says "Traffic Dropped," which confused me. Does this mean the whole package was blocked, or just the "rush" sticker was removed?

Reading sk36869:

• I read the Checkpoint knowledge article sk36869, which explains that the default behavior for most ports (like 1525, not 21, 23, or 513) is to strip the URG flag, not drop the traffic. Ports 21 (FTP), 23 (TELNET), and 513 (RLOGIN) allow the URG flag by default.

Running fw ctl zdebug + drop:

• To see if the firewall was dropping traffic at a deeper level, I ran fw ctl zdebug + drop. The output showed drops due to rule 93, like "y.y.y.y:1866 -> z.z.z.z:8746 dropped by fw_send_log_drop Reason: Rulebase drop - on layer 'Firewall Policy Network' rule 93."
• These drops involved my server (y.y.y.y), but they weren’t for port 1525 or URG flags—they were due to a different rule.

No URG-Specific Drops:

• There’s no indication in the zdebug output that the firewall is dropping traffic on port 1525 specifically because of the URG flag (e.g., via "URGENT_DATA_RESET"). May be the stripping action in the log is handled at a higher level (by the Streaming Engine), not necessarily reflected as a kernel-level drop.

Putting It All Together:

• Firewall is stripping the URG flag on port 1525 (default behavior), not dropping the whole traffic, 
• "URGENT_DATA_RESET" (which would drop URG-flagged traffic) isn’t enabled by default, as my log shows stripping, not dropping, and zdebug doesn’t mention URG-related drops.
• The source (x.x.x.x) is sending URG flags often, and the firewall logs each time it strips them.

Testing Another Port (1524):

• I added the Trinoo service on port 1524 and checked the logs. I saw the same URG flag stripping issue, with both "Accept" and "Drop" actions, confirming the problem isn’t just for port 1525.

Why This Matters for Everyone:

This issue isn’t just about my firewall—it could affect many Checkpoint users. If the firewall strips URG flags on ports like 1524 and 1525 and calls it "Traffic Dropped," users might think their traffic is blocked when it’s not. This could lead to:

• Wasted time troubleshooting: Someone spent hours figuring out the traffic wasn’t really dropped.
• Misdiagnosis: Someone might think their app (like "signet2" or "Trinoo") is failing due to a block, when it’s just the URG flag being removed.
• Security risks: If users ignore these logs thinking they’re harmless, they might miss real issues, like why the source is sending so many URG flags.

My Proposed Improvement: Replace "Drop" with "Warning"

I’ve noticed a big problem with the logs, and I have an idea to make them better:

The Problem: The log says "Traffic Dropped," but the action is only stripping the URG flag, not blocking the whole traffic. The "Informational" severity also doesn’t match "Dropped," which makes me think the package was stopped when it wasn’t. This is confusing, especially for new users like me who might panic or misunderstand what’s happening.

My Suggestion: I think Checkpoint should change the log description from "Traffic Dropped" to "Traffic Warning" or "URG Flag Stripped Warning" when the firewall is just removing the URG flag. "Warning" sounds gentler and matches the "Informational" severity, letting me know it’s not a full block but something to watch.

Why It’s Better: A "Warning" label would be clearer and less scary. It would tell me the firewall is handling the "rush" sticker safely without stopping the package, so I don’t worry about my "signet2" app failing. This small change could help everyone understand logs better and save time troubleshooting.

I came up with this idea after studying my logs, reading sk36869, and running fw ctl zdebug + drop. I think it’s a breakthrough because it addresses a real confusion point, and I’d love to see Checkpoint consider it!

Please  Share Your Thoughts and correct me if I am wrong!

Regards

@Chinmaya_Naik 

[PhoneBoy]

While I see your point in terms of the logs being confusing (similar to CPNotEnoughDataForRulebaseMatch described in https://support.checkpoint.com/results/sk/sk113479), this highlights a key thing with troubleshooting in general: trust but verify.
That means using multiple methods to verify your assumptions/conclusions based on logs. 
In fact, tcpdump/fw monitor/Wireshark is usually the first thing I break out before I start diving into more detailed debugs.

Nice analysis in any case.

[Chinmaya_Naik]

Hello @PhoneBoy ,

Thank you so much for your reply and for appreciating my analysis! I’m @Chinmaya_Naik , so your feedback means a lot to me. I agree with your point about "trust but verify" and using tools like tcpdump, fw monitor, or Wireshark to double-check what the logs say. I’ll try running tcpdump to capture traffic on ports 1524 and 1525 to confirm that the URG flag is stripped but the traffic still goes through, as you suggested.

I also see the similarity with sk113479, where logs say "Connection terminated" due to insufficient data, even when it’s not a big problem. It’s great to know this is a known pattern, but I think it shows we need better logs to avoid confusion. While verifying with tools is a good practice, I believe Checkpoint could make things easier for beginners like me by improving the log messages.

For example, in my case, the log says "Traffic Dropped" for ports 1524 (Trinoo) and 1525 (sqlnet2-1525) when the firewall only strips the URG flag, not blocks the traffic. This made me worry that my apps were failing, and I spent a lot of time investigating. I still think changing "Drop" to "Traffic Warning" or "URG Flag Stripped Warning" would be clearer and match the "Informational" severity. This would help new users understand what’s happening without needing to run extra tools, saving time and reducing confusion.

I’d love to hear your thoughts on this improvement idea, and if other community members have seen similar issues with log wording. Thanks again for your guidance!

@Chinmaya_Naik 

[the_rock]

Very good analysis indeed...EXCELLENT job!

Andy

[PhoneBoy]

I am all for improving the clarity of logs where it's needed.