- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hello Mates!
I'm having a strange problem in a client's environment. It's a Cluster in HA R81.10 Take 94.
When I install policies, the gateways lose communication with the internet, there's no ping to the outside, but the machines behind the gateway navigate normally.
When I apply an fwunloadlocal to the gateways, they start responding to ping from the internet again, but the machines stop browsing.
No drops are shown in zdebug, the policies rules seems to be ok too.
fw monitor show like this when I try to ping external address:
the IP 172.31.1.3 is the gateway interface. I just see the request, not reply
In the same moment that a machine behind the gateway shown me request/reply normally:
What could be causing this?
Hello friends @the_rock @Blason_R
Thank you very much for all your help and dedication so far!
The problem has been solved with a NO NAT rule on the Check Point.
As I mentioned before, this Check Point appliance didn't perform NAT, the NATs were configured on the F5, and it has worked like this since deployment.
I believe something was changed on the F5, and out of curiosity, I created rules for the members' IPs and the cluster's VIP, and after creating the rules, the appliances navigated normally.
However, I didn't understand why it worked without the policies. Was there something implicit that made it work?
Do you have any idea of what could have made the appliances' navigation work without the policies installed?
Thank you all!
I had this happen with customers before and 9 times out of 10, either its something with topology (anti spoofing) and/or routing/nat.
Here is an easy thing to try...in both situations, run ip r g 8.8.8.8 from gateway and compare the output, that should give a clue.
HTH @Bernardes
Andy
hello @the_rock !
This was the result before and after fw unloadlocal:
I try to disable anti-spoofing, but it doesn't work.
Any changes in Implied rules? Did you disable anything?
Hello @Blason_R ! The implied rules are default, no changes.
Ok so what does fw stat shows if policy push is successful?
Do you get ping to 8.8.8.8 or 9.9.9.9
Do you get arp of your default gateway (arp -an | grep <DG_IP_Address>)
What is cphaprob -a if says?
cphaprob stat shows any PNOTES?
@Blason_Rlook at the output results for these commands:
Ok, so thats the same...can you tell if nat takes place when issue occurs? What does zdebug show?
Andy
@the_rockthe NAT occurs on an F5 appliance in front of Check Point. This Security Gateway is not doing NAT in this case.
In zdebug output not is showing nothing fot this traffic, apparently theres no drop
@Bernardes Since I like to think about anything in life the logical way, lets recap this situation.
Sooo...IF you do fw unloadlocal and everything works fine, that tells me logically that SOMETHING in the policy is causing the problem. Can you do zdebug BEFORE you unload the policy and see if it gives anything?
Andy
@the_rockThis zdebug output above is when the policies were applied, but after the fw unloadlocal the result is the same, aparently there's no drops before or after the policies are applied.
Ok...if you are 100% sure and you have verified routing/natting, then only other thing I could think of is anti-spoofing. Please ensure thats accurate, because if wrong, it can definitely cause issues like this one.
Take care.
Andy
Hello friends @the_rock @Blason_R
Thank you very much for all your help and dedication so far!
The problem has been solved with a NO NAT rule on the Check Point.
As I mentioned before, this Check Point appliance didn't perform NAT, the NATs were configured on the F5, and it has worked like this since deployment.
I believe something was changed on the F5, and out of curiosity, I created rules for the members' IPs and the cluster's VIP, and after creating the rules, the appliances navigated normally.
However, I didn't understand why it worked without the policies. Was there something implicit that made it work?
Do you have any idea of what could have made the appliances' navigation work without the policies installed?
Thank you all!
That nice to know that but still looks odd to be honest. The traffic originating from gateway does get hide or folded behind VIP and shouldn't matter if those are natted or not provided what is the sequence kept in global properties for "Traffic originating from Gateway" <LAST|First| Before LASt>
And without policy the appliance does not route the connection or no connection can traverse through the appliance for security reason else it will perform just like normal server.
I tend to agree with @Blason_R . Good job by the way in doing those rules, since F5 is handling the NAT. But, having said that, by default, CP firewall will not do any nat, as out of the box, nat is not enabled and plus, there is no default nat rule inside the policy that would nat all outgoing traffic, so one either need to be created OR you can check option to nat all internal networks behind the firewall external IP.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
18 | |
12 | |
6 | |
6 | |
6 | |
5 | |
4 | |
4 | |
4 | |
4 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY