- Products
- Learn
- Local User Groups
- Partners
- More
Stop Babysitting Rules.
Go Agentic
Step Into the Future of
AI-Powered Cyber Security
The State of Ransomware Q1 2026
Key Trends and Their Impact
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
CheckMates Go:
CheckMates Fest
I just setup a brand new ClusterXL security gateway. eth0 has a WAN facing ip as it's VIP, say X.X.X.X/30. It's a public /30, with the router ahead of me holding 1 of 2 other IPs. so the the non-virtual IPs on that interface are on 172.17.0.0/30.
Just trying to get some basic routing going.
When I ping X.X.X.X from the outside, I see it hit the FW. Be allowed but NAT'ed to 1 of the 172.17.0.0s and no reply is received by the remote end.
Outbound, if I ssh into one of the gateways, for starters I cannot ping -I X.X.X.X/30 8.8.8.8. It says cannot assign requested address. Maybe this is expected.
A regular attempt at a ping is also seen on the firewall but get's NAT'ed to the the Cluster VIP of my management network (Y.Y.Y.Y/24). No reply is seen on my end here either.
Both show up as NAT Rule Number 0.
eth0 is defined as the only external in topology
ICMP Requests in Global Properties are checked on.
Surely, NAT isn't required here when its meant for hosts BEHIND the gateway, no?
I feel like I'm missing something.
Well, for outbound access, it has to be natted, otherwise, clients wont be able to access the Internet with non-routable IP address. Now, for inbound, you need static NAT. Or am I missing totally whats not working here?
This is landing on the CP gateway itself (its WAN address) or in the 2nd ecample, direct from the CP gateway.
There is an option in the gateway object to hide behind the gateway IP.
Is that checked?
Yes i tried checking it but it made no difference. i also dont understand why NAT would be required from the CP gateway holding the IP in question itself.
K...can you please give us an example of EXACTLY what is not working? Either inbound or outbound? Basic network topology/diagram would also help.
Andy
I cannot ping the gateway ClusterXL VIP.
Diagram:
Traffic is seen in the firewall log as accepted, but no reply is received:
Output of: fw monitor -e 'accept(src=82.X.X.249 or dst=82.X.X.249);'
Pinging 82.X.X.249 from the security gateway itself using: ping -I eth0 82.X.X.249 DOES work.
Just run fw ctl zdebug + drop | grep x.x.x.x on the ssh and see what you get. Replace with proper IP address.
not seeing any drops for icmp.
Having tried a similar IP scheme with a PFSense Clone - i know it works.
Right so now I'm a little confused on how clustering is supposed to work.
This was enough to see some public TCP traffic arriving on the Checkpoint. But I was unable to ping outside-> inside or vice versa. I also saw a change in Gaia's "routing monitor" once this was configured in SmartConsole.
In a dire attempt, I added the 82.x.x8.250/30 to Gaia Web UI as an alias to eth0 on cp-gw-1 and it now appears to be working w/ cp-gw-2 shut down.
But this is a virtual IP in a /30 (meaning only 2 addresses, one of which is my default g/w). How could I possibly assign the same alias to cp-gw-2 w/out them clashing?
I'm trying to follow this to the letter now to workaround the issue: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
After setting scopelocal, I can ping the upstream gateway (82.x.x8.249) from internal clients, but can't reach past that. I get "IP routing failed (ipout routing failure)".
It appears that my default route isn't entering the route table:
Edit: after reading the SK and this thread: https://community.checkpoint.com/t5/Security-Gateways/ClusterXL-Different-Subnet-Configuration/td-p/...
I rebooted and things started working.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 23 | |
| 19 | |
| 9 | |
| 9 | |
| 8 | |
| 7 | |
| 7 | |
| 6 | |
| 4 | |
| 4 |
Fri 29 May 2026 @ 09:00 AM (EDT)
Caracas: Executive Breakfast: Innovación en Ciberseguridad – IA y Threat IntelligenceTue 02 Jun 2026 @ 06:00 PM (IDT)
Under the Hood | Check Point SASE: Identity Integration & Access Policy Design Best PracticesThu 04 Jun 2026 @ 02:00 PM (CEST)
Deep Dive Webinar: New CloudGuard GWLB Deployment Without NAT Gateways - EuropeTue 02 Jun 2026 @ 06:00 PM (IDT)
Under the Hood | Check Point SASE: Identity Integration & Access Policy Design Best PracticesThu 04 Jun 2026 @ 02:00 PM (CEST)
Deep Dive Webinar: New CloudGuard GWLB Deployment Without NAT Gateways - EuropeThu 04 Jun 2026 @ 07:00 PM (IDT)
Deep Dive Webinar: New CloudGuard GWLB Deployment Without NAT Gateways - AmericaFri 12 Jun 2026 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 47: Continuous Threat Exposure ManagementThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionFri 29 May 2026 @ 09:00 AM (EDT)
Caracas: Executive Breakfast: Innovación en Ciberseguridad – IA y Threat IntelligenceAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY