- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Packet replying does not match initial connection ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Packet replying does not match initial connection (R80.10)
Hello ,
I have a problem about checkpoint R80.10 like this:
I create a rule like below:
From IP_SOURCE to IP_DST, service : TCP_8082
But when I search log drop from DST to SRC, I saw that replying packet get dropped because CP does not see it as a replying packet; (Checkpoint think this is new connection from DST to SRC and simply drop it by cleanup rule)
So please let me know why or any step to troubleshoot it?
Thank a lot!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The firewall is dropping this reply probably because it has no record of it in the state table.
For the screenshot you provided, can you find the earlier log entry for this particular connection showing when the connection started (Accept action)? Source port will be 36366 and destination port will be 8082 for the connection start. To get more visibility into how these connections are starting and ending enable Accounting on the rule in the Track column which will show you how long the connection lasted and when it ended, standard logging of a connection only shows when the connection started.
For even more info about connection state transitions see sk101221: TCP state logging.
Exclusively at CPX 2025 Las Vegas Tuesday Feb 25th @ 1:00pm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank for reply Hall,
I search log from SRC to DST with port 8082,36366
=> see that the time is same as the time of dropped packet of replying direction(1:46:53PM) . So maybe the initial connection was closed right after it was established, then replying packet was dropped because of no connection exist.
=> Do you agree with my guess?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the logs are from two different FWs: DC-Internet-Fw-01 and DC-Internet-Fw-02
may be Async Routing, misconfigured VRRP etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Haas,
In my situation, 2 FWs are cluster with each other(using load sharing mode). How can I adjust for replying packet to go through DC-Internet-Fw-02 (same as intial direction) ?
or any solutions for this dropping?
(Now I am having to add a explicit rule to allow replying packet (from DST to SRC , service: tcp-high-port))
Thanks!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
just curious: is the packet droped because of "out of state" or just by the cleanup rule ?
or did you disable to drop out of state packets:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It is dropped by cleanup rule (as pic in #1 my post)
Here is my screen (already disable drop out of state)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can enable the Sticky Decision Function, but be careful, this will disable SecureXL.
