- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Hi Team,
We are facing issue where reverse https traffic from destination to source is being dropped.
Below example FYI
*****Forward Traffic******
Source:10.10.10.10 (source is behind gateway 1)
Source port: Random (52437)
Destination: 20.20.20.20 (Destination is behind gateway 2)
Destination port: 443
Traffic is getting allowed on both Gateway
*****Reverse Traffic******
Source: 20.20.20.20 (Destination is behind gateway 2)
Source port: 443
Destination: 10.10.10.10 (source is behind gateway 1)
Destination port: Random (52437) --->Same Random Port which observed in forward traffic
Traffic is getting dropped on gateway 2
**********************
This is unexpected behavior in stateful firewall,
Any thoughts on why this is happening , and what could be solution?
What does the drop log say?
For TCP 443 you do not need two rules, one should be enough. Also, what about NAT?
Hello _Val_
Thanks for reply.
Zdebug Drop logs says "dropped by fw_send_log_drop Reason: Rulebase drop". Same observed in smartconsole logs, traffic is getting dropped by default cleanup rule.
Nating is not enabled for both source and destination.
Do you see accept logs for forward traffic on both gateways, and which gateway is logging the drop?
Hello emmap,
Yes can see accept logs for forward traffic on both gateways.
Drop log is observed on first gateway of return traffic (gateway 2 as explain in question)
This does not make much sense. Check for asymmetric routing.
Please provide screenshots of both the accept and drop logs (masking sensitive data).
Please provide the full log card for each log entry.
I’m not seeing the “origin” field on these log entries (I.e. the gateway that is actually logging these packets).
Have you confirmed the same gateway that is allowing the traffic is actually blocking it?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 66 | |
| 19 | |
| 13 | |
| 12 | |
| 11 | |
| 10 | |
| 9 | |
| 7 | |
| 7 | |
| 7 |
Tue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY