Create and Manage Address Objects and Groups on Check Point R81.x

Before you run this

This guide creates and manages network objects — hosts, networks, address ranges — and gathers them into network groups in the Check Point management database. Those objects are the reusable building blocks you later reference in access rules and NAT. Creating an object by itself changes nothing on the gateway: the object does nothing until it is used in a rule and you Install Policy. The real risk is downstream — a wrong object dropped into an existing rule, or a policy install, can cut production traffic.

Privileges. You need a SmartConsole administrator with read/write permission on the management server. For the CLI (mgmt_cli), run it in expert mode on the Security Management Server, or from a remote host that has the API tools and a management admin credential. The Management API must be enabled and accepting calls (SmartConsole → Manage & Settings → Blades → Management API, then api restart on the server).

Assumptions. A standalone Security Management Server on Gaia, R81.20, SmartConsole R81.20, single-domain (not Multi-Domain). Menu paths and API keywords move between versions — confirm anything unfamiliar against the Check Point Management API Reference for your exact version.

Test first. Try this on a lab management server or a throwaended test object before you touch production naming. Read any script before pasting it. Object creation is reversible (you can delete or discard), but a published change becomes the live database.

Firewall safety, non-negotiable:

• Keep a separate console / SSH session to the management server open so a mistake in one session does not lock you out.
• Back up first: take a Gaia snapshot and/or export the management database (migrate_server export on R81.x), and note the current database revision.
• Make changes in a maintenance window, especially the Install Policy step.
• Rollback paths: before you publish, discard reverts all unsaved changes in your session. After you publish, use SmartConsole database revisions (Manage & Settings → Revisions) to revert, or restore the Gaia snapshot / exported database. Deleting an object that is still used in a rule will be refused until you clear the reference.

---

The GUI way (SmartConsole)

For a handful of objects, SmartConsole is the normal path.

1. Open SmartConsole and connect to the management server.
2. Open the Objects pane on the right (or Objects menu → Object Explorer).
3. Click New, then choose the object type:
   • Host — a single IP. Give it a name and the IP address.
   • Network — a subnet. Enter the network address and the mask (length or dotted).
   • Address Range — enter the first and last IP.
4. Click OK to save the object into your session.
5. To group them: New → Network Group. Name it, then use the + inside the group dialog to add existing objects as members. A network group can contain hosts, networks, ranges, and even other groups.
6. When your objects are correct, click Publish at the top to commit them to the database.

Nothing reaches the gateway yet. That only happens when you use these objects in a policy and run Install Policy.

The API way (mgmt_cli)

For bulk work, the Management API is the standard scriptable path. The flow is always login → make changes → publish → logout. All changes are held in your session until you publish.

# Log in and store the session id in a file.
# Password on the command line is visible in history/ps — prefer letting it prompt,
# or run this from the SMS as root (see note below).
mgmt_cli login user "admin" password "CHANGE_ME" > id.txt

# id.txt now holds the session token; pass it with -s to every following call.

Create individual objects:

# A single host
mgmt_cli add host name "web01" ip-address "192.0.2.10" -s id.txt

# A subnet (mask given in dotted form)
mgmt_cli add network name "net-dmz" subnet "192.0.2.0" subnet-mask "255.255.255.0" -s id.txt

# An address range
mgmt_cli add address-range name "pool-guests" \
  ip-address-first "198.51.100.10" ip-address-last "198.51.100.50" -s id.txt

Create a group and add members. You can add members when you create the group, or set them afterwards:

# Create an empty group
mgmt_cli add group name "grp-dmz-servers" -s id.txt

# Add existing objects to it
mgmt_cli set group name "grp-dmz-servers" members.add "web01" -s id.txt
mgmt_cli set group name "grp-dmz-servers" members.add "net-dmz" -s id.txt

Commit and log out:

mgmt_cli publish -s id.txt      # writes your session changes to the database
mgmt_cli logout  -s id.txt
rm -f id.txt

If you decide the session is wrong before committing, run mgmt_cli discard -s id.txt instead of publish — every unpublished change in that session is dropped.

Running locally on the management server as root, Check Point supports authenticating with the local root credentials instead of a password (the -r true option). If you use it, confirm the exact syntax in the API reference for your version before scripting it.

A small, safe batch script

Replace the placeholder names and IPs. This reads a simple CSV (name,ip) and creates hosts, then publishes once at the end. It stops on the first error so a bad line does not leave a half-done batch.

#!/bin/bash
set -euo pipefail

CSV="/path/to/hosts.csv"     # lines like:  web01,192.0.2.10
SESSION="id.txt"

mgmt_cli login user "admin" password "CHANGE_ME" > "$SESSION"

# Read name,ip and create each host
while IFS=, read -r name ip; do
  [ -z "$name" ] && continue           # skip blank lines
  echo "Adding $name -> $ip"
  mgmt_cli add host name "$name" ip-address "$ip" -s "$SESSION"
done < "$CSV"

mgmt_cli publish -s "$SESSION"
mgmt_cli logout  -s "$SESSION"
rm -f "$SESSION"

Run it once against two or three test rows before you feed it a full list. Nothing here installs policy, so it will not move production traffic on its own.

Verify it worked

From the CLI, read the objects back:

mgmt_cli login user "admin" password "CHANGE_ME" > id.txt

mgmt_cli show host  name "web01" -s id.txt
mgmt_cli show group name "grp-dmz-servers" -s id.txt   # lists members

mgmt_cli logout -s id.txt
rm -f id.txt

show group returns the group with its members array — confirm the objects you expect are listed. In SmartConsole, the same objects appear in the Objects pane; open the group to see its members. Add --format json to any show if you want to parse the output.

Undo and cleanup

Before you delete anything, check what references it — deleting an in-use object is refused. In SmartConsole, right-click the object and choose Where Used. The API exposes an equivalent lookup; confirm its exact command name in the API reference before scripting it.

Remove a member from a group, or delete objects:

mgmt_cli login user "admin" password "CHANGE_ME" > id.txt

# Take one object out of a group
mgmt_cli set group name "grp-dmz-servers" members.remove "web01" -s id.txt

# Delete objects (order: clear references first, then the objects, then the group)
mgmt_cli delete host  name "web01" -s id.txt
mgmt_cli delete group name "grp-dmz-servers" -s id.txt

mgmt_cli publish -s id.txt
mgmt_cli logout  -s id.txt
rm -f id.txt

If you have not published yet, the cleanest undo is simply mgmt_cli discard -s id.txt (or Discard in SmartConsole), which throws away every unsaved change. If you have already published and need to step back, revert with a database revision (Manage & Settings → Revisions) or restore the Gaia snapshot / exported database you took before you started.

For anything you are unsure about — a mask keyword, the where-used command, or the root-login option — stop and check the Check Point Management API Reference and the R81.20 Security Management Administration Guide rather than guessing a keyword into a production database.