Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Kurpeus
Contributor
Contributor
Jump to solution

Programatically disable Extended Cluster Anti-Spoofing

Hi Checkmates

Does anyone know how to programatically disable Extended Cluster Anti SPoofing  either via API or CLI commands ? I'm trying to put together a zero touch demo environment (IaC + full Check Point Terraform config) on GCP, but the management traffic is being dropped by the cluster

@;193343.618;[vs_0];[tid_0];[fw4_0];fw_log_drop_ex: Packet proto=6 10.254.1.2:18191 -> 10.254.1.4:38596 dropped by fw_cluster_ttl_anti_spoofing Reason: ttl check drop;

From Smart Console it is possible to disable Extended Cluster Anti Spoofing but i can't see a way to do this via a command. The gateways are on R81.20 and Mgmt R82. 

Thanks

 

 

0 Kudos
1 Solution

Accepted Solutions
Kurpeus
Contributor
Contributor

Ok I've managed to do it via dbedit.  cluster is called "gcp-southhub-fw-cluster"

On the management server I've created a script called dbedit.script

dbedit.script:

print network_objects gcp-southhub-fw-cluster
modify network_objects gcp-southhub-fw-cluster cluster_anti_spoofing false
update_all
print network_objects gcp-southhub-fw-cluster
quit -n

I run the command as follow:

[Expert@chkp-fwm:0]# dbedit -local -f dbedit.script | grep cluster_anti_spoofing

 

Screenshot 2025-05-13 131255.jpg

 

Now i just need to create a null_resource remote provisioner  type and get it to run the script as part of the workflow

 

View solution in original post

10 Replies
the_rock
Legend
Legend

Let me try figure it out in my cluster, but I know below used to work in older versions, but does not seem its doable in R81.20...

Andy

set cluster member <member_id> advanced-settings extended-anti-spoofing off
save config

0 Kudos
the_rock
Legend
Legend

Though, when I ran your question through AI copilot, says cannot be done viia clish, not supported, but I would still double check that info.

Andy

0 Kudos
Kurpeus
Contributor
Contributor

Thanks. I think the way to go it to use dbedit in command line. I'm trying to figure out the syntax. Never used it this way before. Always GUI

 

0 Kudos
the_rock
Legend
Legend

I will keep trying, its very interesting challenge.

Andy

0 Kudos
Kurpeus
Contributor
Contributor

Ok I've managed to do it via dbedit.  cluster is called "gcp-southhub-fw-cluster"

On the management server I've created a script called dbedit.script

dbedit.script:

print network_objects gcp-southhub-fw-cluster
modify network_objects gcp-southhub-fw-cluster cluster_anti_spoofing false
update_all
print network_objects gcp-southhub-fw-cluster
quit -n

I run the command as follow:

[Expert@chkp-fwm:0]# dbedit -local -f dbedit.script | grep cluster_anti_spoofing

 

Screenshot 2025-05-13 131255.jpg

 

Now i just need to create a null_resource remote provisioner  type and get it to run the script as part of the workflow

 

the_rock
Legend
Legend

Great job!

Andy

0 Kudos
Duane_Toler
Advisor

You can (and should) use the management API:

 

https://sc1.checkpoint.com/documents/latest/APIs/#cli/set-simple-cluster~v1.9.1%20

Screenshot 2025-05-13 at 3.53.05 PM.png

 Although, the better choice is to fix the issue causing the anti-spoofing error in the first place.  Anti-spoofing errors mean you have a problem with your configuration.

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
Kurpeus
Contributor
Contributor

This is not about interface anti spoofing. This can indeed be configured via API (and it is disabled anyway as per Check Point / GCP best practices.).  This is about extended cluster anti spoofing setting  (cluster properties -> network Management -> Advanced -> Enable Extended Cluster Anti-Spoofing) which is enabled by default. 

I have little/no control of the overlay network (GCP). The management server sits on the same L3 network (= directly connected)  as the firewall sync (eth1). Both are on the same region but different zone.  Somehow the cluster is not happy with the TTL value of packets from the management and drops the traffic. 

 

0 Kudos
Duane_Toler
Advisor

Ohh!  I see the problem.

 

Management server is on the same network.  Move that to its own VPC and network.  You wouldn't want management in the same network when the future comes and you need to delete the gateways VPC and re-deploy (upgrades, problem-fixing, whatever).  It'll also keep your configuration more clean, with distinct separation of duties.

CloudGuard management is meant to be on its own entirely, anyway.  The same applies for Azure deployments, too (of which I do a lot these days for customers).

 

--
Ansible for Check Point APIs series: https://www.youtube.com/@EdgeCaseScenario and Substack
0 Kudos
Kurpeus
Contributor
Contributor

Thank you.. It is already the case. The firewalls have a leg in the management VPC, not the other way around.   I was following Checkpoint deployment guide for GCP  link here 


  • Each gateway has a network interface in a subnetwork in the Management VPC. This is the network that manages the gateways.

 

To be fair I'm also doing that in a trial account which comes with lot of restrictions from GCP. 

  • Limited in the number of VPC per project
  • Limited in the number of project per billing account
  • Trial credits can only be used with one billing account
  • Limited in the number of CPUs per region
  • and the list goes on ... 

So they give you $300 credits but then you can't really use it meaningfully 😄

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events