- Products
- Learn
- Local User Groups
- Partners
- More
The State of Ransomware Q1 2026
Key Trends and Their Impact
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
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
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 |
|---|---|
| 34 | |
| 10 | |
| 10 | |
| 10 | |
| 10 | |
| 8 | |
| 7 | |
| 6 | |
| 6 | |
| 6 |
Tue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceWed 13 May 2026 @ 11:00 AM (EDT)
TechTalk: The State of Ransomware Q1 2026: Key Trends and Their ImpactThu 14 May 2026 @ 07:00 PM (EEST)
Under the Hood: Presentando Check Point Cloud Firewall como ServicioTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY