- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
I have a Checkpoint ClusterXL distributing a BGP range.
If I assign an interface to one of the IPs in that range, it will respond to ICMP (as ICMP requests are allowed in Global settings).
But since ClusterXL does not support aliases, how do I enable ping on the ENTIRE range without NAT'ing it to something behind the Checkpoint?
I thought about making ICMP request NAT rules but since it's not a TCP/UDP service, I can't use it in a NAT rule.
Proxy ARP alone doesn't seem to work either for this purpose.
I don't like the suggestion of creating a wide NAT rule to cover ALL and then excluding what I don't want in the firewall. It would get messy and confusing when I want real NATs on the same IP to actual servers behind the checkpoint in the future.
Is there another option?
Why is this configuration desirable unless there is actually an active host/hosts for those addresses?
Because I'm essentially terminating all the ips in that range on the checkpoint. No hosts behind the Checkpoint are being assigned these public IPs. The checkpoint will be NAT'ing to them.
I therefore want to be able to monitor all the IPs externally, whether or not they have real "interesting" traffic on them.
This is possible to do on your firewall, but I would not recommend it as it almost certainly not supported and may cause some unexpected behavior. First off, you'll need an Access Control rule permitting ICMP echo requests to a network object representing your BGP prefix/network. Let's assume it is 192.0.2.0/24. This will let the echo request traffic reach the IP driver in Gaia where we can employ some trickery with the loopback interface.
Now in Gaia you need to add a "local" static route via the loopback interface to the BGP network. From clish this command is accepted syntactically but does not actually add the needed loopback route to the live routing table because it is not added as a "local" route:
set static-route 192.0.2.0/24 nexthop gateway logical lo on
However from expert mode this command will successfully add the needed local route to the live routing table, and now the Gaia IP driver will respond to all pings bound for this subnet:
ip route add local 192.0.2.0/24 dev lo
Needless to say a route added in this way from expert mode will not "stick" across a reboot, and there doesn't seem to be any way to add a "local" route from clish that I can find. This local route loopback trick is handy on honeypot boxes that need to respond to all IP addresses on a network which is how I knew about it.
Wow, thanks for the explanation. The not surviving a reboot thing is problematic however.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 13 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY