- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi Team.
After fetching the topology ,i am trying to change the topology settings, of newly created interfaces by using set simple gateway command but its removing all the existing interfaces.
is there any way to change topology settings of interfaces ,without affecting existing interfaces , all things we are doing api/mgmt cli commands.
Regards
Aathi
Version/JHF level?
A precise example might help also.
@Omer_Kleinstern
Actually, not necessary as it appears this is documented, expected behavior.
”When a gateway is updated with a new interfaces, the existing interfaces are removed.”
See: https://sc1.checkpoint.com/documents/latest/APIs/#cli/set-simple-gateway~v1.8
Which means if you use the API to change the setting on one interface, you need to define the settings for all of the ones you want to keep.
Whether this should be the behavior is a separate question, of course.
As @PhoneBoy already mentioned, you always have to specify all interfaces at once. IMHO you have two possibilities now:
1. You can use the API endpoint get-interfaces, which does pretty the same as the "Get interfaces" button in the GUI and use the "use-defined-by-routes" parameter in addition, which tells the firewall to define the topology according to the routing table (which is in most cases a good idea). This happens dynamically every second.
2. You always set the complete list of interfaces the gateway has. You can do that for example through the api. First, you fetch the interfaces object of the gateway object with show-simple-gateway:
mgmt_cli -r true show-simple-gateway name <object-name> --format json | jq '.interfaces'Now you can edit the necessary parameters and push back the changes with set-simple-gateway. Unfortunately it is not possible to push back the complete object as you get it from the API, as there are several parameters, which set-simple-gateway does not accept (or ignore).
You also can use an automation tool like Ansible to define your objects, but believe me: This can be really painful, as there is really much room for improvement for the Check Point Ansible collection, as well as for the API itself.
Cheers,
Thomas
Hi @Thomas-Marko and @PhoneBoy ,
i have tried the first option ,still getting error while installing the policy. please find the attached error and hotfix details.
we are not willing to use option 2 as its risky and we need to run it on production env.
Security Zones require topology to be defined, as described here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Which means you either don't use Zones or you define the interface topology.
Which brings us back to actually making set-interfaces work the way you want.
Unfortunately, if you use the API to set the settings for one interface, you have to set them all, as stated in the documentation.
While @Thomas-Marko makes an excellent point about set-simple-gateway not returning everything about the gateway object (particularly the parts that don't have API support), I believe everything related to the interfaces does have API support.
That means the approach should work in this case.
And yes, I understand your concerns about using this in production, but this is why you test your code on something that is not your production environment first.
You can use the Demo Mode servers for this, so no need to spin up your own VM: https://community.checkpoint.com/t5/API-CLI-Discussion/Using-SmartConsole-Demo-Mode-Server-for-API-t...
Is there any other way to resolve this issue.
in our env we are having 50+ interfaces,we cant recreate using set-simple gateway command.
why the first option is not working which Thomas mentioned.
Please use the API call gateways-and-servers with details-level full which will give you all information about all gateways and servers. Set format in JSON, and them slice and dice as you wish. Ping if you need any help.
Please provide a screenshot of the gateway object interface settings where you’ve attempted to defined the topology by routes and are getting the originally referenced policy installation error.
Hi,
hmm, maybe I do not understand the question correctly, but to achieve what you request as far as I understand it, you can simply do the following:
1. Read the existing object by issuing a POST request to the endpoint show-simple-gateway. You will get the data for your existing object. One part of this data is the "interfaces" array.
For example:
"interfaces": [
{
"name": "eth0",
"ipv4-address": "192.168.201.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"icon": "NetworkObjects/network",
"topology": "automatic",
"topology-automatic-calculation": "internal",
"topology-settings": {
"ip-address-behind-this-interface": "not defined",
"interface-leads-to-dmz": false
},
"anti-spoofing": false,
"security-zone": false
},
{
"name": "eth1",
"ipv4-address": "192.168.200.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"icon": "NetworkObjects/network",
"topology": "automatic",
"topology-automatic-calculation": "internal",
"topology-settings": {
"ip-address-behind-this-interface": "not defined",
"interface-leads-to-dmz": false
},
"anti-spoofing": false,
"security-zone": false
}
]
2. Add a new interface if needed or make your changes to the existing ones and remove the "icon" and "topology-automatic-calculation" properties from the existing objects as they are not accepted by the api (@checkpoint: Can you please just ignore such properties? It would make life much easier, when working with api result objects).
In my example I made some changes and added a new interface to my existing gateway and sent a POST to the endpoint set-simple-gateway with the following data:
{
"uid": "6e39115e-c236-41c6-b768-b56ccd056014",
"interfaces": [
{
"name": "eth0",
"ipv4-address": "192.168.201.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"topology": "automatic",
"topology-settings": {
"ip-address-behind-this-interface": "network defined by the interface ip and net mask",
"interface-leads-to-dmz": true
},
"anti-spoofing": true,
"security-zone": true,
"security-zone-settings": {
"specific-zone": "DMZZone"
}
},
{
"name": "eth1",
"ipv4-address": "192.168.200.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"topology": "automatic",
"topology-settings": {
"ip-address-behind-this-interface": "not defined",
"interface-leads-to-dmz": false
},
"anti-spoofing": false,
"security-zone": false
},
{
"name": "eth2",
"ipv4-address": "192.168.203.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"topology": "external",
"anti-spoofing": true,
"security-zone": true,
"security-zone-settings": {
"specific-zone": "ExternalZone"
}
}
]
}
And I got back an http/200 with all my changes applied:
{
"uid": "6e39115e-c236-41c6-b768-b56ccd056014",
---SNIP---
"interfaces": [
{
"name": "eth0",
"ipv4-address": "192.168.201.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"icon": "NetworkObjects/network",
"topology": "automatic",
"topology-automatic-calculation": "internal",
"topology-settings": {
"ip-address-behind-this-interface": "not defined",
"interface-leads-to-dmz": false
},
"anti-spoofing": true,
"anti-spoofing-settings": {
"action": "prevent"
},
"security-zone": true,
"security-zone-settings": {
"auto-calculated": false,
"specific-zone": "DMZZone"
}
},
{
"name": "eth1",
"ipv4-address": "192.168.200.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"icon": "NetworkObjects/network",
"topology": "automatic",
"topology-automatic-calculation": "internal",
"topology-settings": {
"ip-address-behind-this-interface": "not defined",
"interface-leads-to-dmz": false
},
"anti-spoofing": false,
"security-zone": false
},
{
"name": "eth2",
"ipv4-address": "192.168.203.2",
"ipv4-network-mask": "255.255.255.0",
"ipv4-mask-length": 24,
"ipv6-address": "",
"comments": "",
"color": "black",
"icon": "NetworkObjects/network",
"topology": "external",
"anti-spoofing": true,
"anti-spoofing-settings": {
"action": "prevent"
},
"security-zone": true,
"security-zone-settings": {
"auto-calculated": false,
"specific-zone": "ExternalZone"
}
}
],
--- SNIP ---
}
So I think that's that what you want to achieve, right?
Cheers,
Thomas
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 5 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Fri 14 Nov 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Veriti, Threat Exposure ManagementWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERFri 14 Nov 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Veriti, Threat Exposure ManagementWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY