- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Hi everyone.
We're having an issue with traffic that I don't know how to pinpoint the cause of. We have an office in China which has a PBX server on the DMZ. Yesterday and today our users haven't been able to connect to it externally for a period of about 45 minutes. Looking at the logs for the time that it's unavailable (it's accessible from within the office), I can see HTTPS and webRTC traffic hitting the firewall and the PBX looks to send responses but external users are still unable to connect; no drop log entries exist. Essentially things seem ok and there aren't really any gaps in the logs to suggest that there are connectivity issues.
Apart from having a look at the logs after the fact, is there anything else we can do to determine why this is happening? There haven't been any policy changes nor any ISP failover so I don't know how we can prove whether it's a carrier issue or an issue with the firewall.
Happy to answer any questions. Thanks in advance.
Unfortunately given the geographic country involved here, it is likely that a "greater" firewall outside your control is messing with your traffic. The only real way to determine the cause is to obtain a simultaneous packet capture with tcpdump/cppcap on both sides while the issue is occurring; regrettably Check Point does not support the notion of "triggered" packet captures that automatically start when a certain condition is met.
That said, there are three features mentioned in my book that you can enable to provide some extra log visibility and perhaps help give you a better idea of what is going on:
1) sk101221: TCP state logging
2) Possibly disable Session Logging on the relevant rules matching the problematic traffic and set only "Connection Logging", which will produce more granular connection-based logs but there will be many more of them. For the difference see my CPX 2022 presentation Max Gander: The Hidden World of Log Generation & Suppression on Check Point.
3) Enable "Accounting" on the relevant rules matching the problematic traffic:
You'd have to take packet captures while this is happening to get an idea of whether the traffic is symmetrically passing through the gateway or not.
It may not tell you where the issue is exactly, but you can at least rule out the firewall that way.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY