Skip to content

Check Point: CLI (mgmt_cli)

Apply the same changes as the GUI (SmartConsole) guide using mgmt_cli, the command-line client for the Check Point Management API. It runs on the Security Management Server (Gaia shell) and edits the same management database SmartConsole does: nothing takes effect until you publish the session and install the policy.

Before you start

Review the Check Point overview. You will need:

  • SSH access to the Security Management Server (or Multi-Domain Server)
  • An administrator account with permission to edit and install policy
  • The names of your policy package, target gateway(s), and the Access Control layer that carries Application Control (find them with the show commands below)

HTTPS Inspection rules need R81 or later

The add https-rule API family was introduced with the R81 Management API (v1.6). On R80.x, step 3 below fails with an unknown-command error: add the bypass in SmartConsole instead (see HTTPS Inspection bypass) and script the rest here.

1. Open an API session

Log in once and reuse the session file for every command; mgmt_cli prompts for the password:

mgmt_cli login user <API_USER> > id.txt

All commands below reference this session with -s id.txt. Append --format json to any command for machine-readable output.

2. Create the destination object

Create a Domain object for the endpoint FQDN. The API names Domain objects as the FQDN itself with a leading dot (this object plays the role of the rta-connect-endpoint object in the GUI guide):

mgmt_cli -s id.txt add dns-domain name ".connect.remotetesting.secureworks.com" is-sub-domain false

is-sub-domain false matches the exact FQDN only, which is what you want here.

If you prefer an IP-based rule, create host objects for the two static headend IPs instead:

mgmt_cli -s id.txt add host name rta-connect-ip-1 ip-address 3.33.194.251
mgmt_cli -s id.txt add host name rta-connect-ip-2 ip-address 15.197.255.2

3. HTTPS Inspection bypass (R81+)

List the HTTPS Inspection layers to confirm the layer name (a default installation has one layer named Default Layer):

mgmt_cli -s id.txt show https-layers

Add the bypass at the top of the layer so it sits above any catch-all inspect rule:

mgmt_cli -s id.txt add https-rule layer "Default Layer" position "top" name "RTA OpenVPN bypass" destination.1 ".connect.remotetesting.secureworks.com" service.1 "https" action "Bypass"

Warning

As in the GUI, the bypass only helps if no higher rule inspects or drops TCP/443 to this destination first. position "top" handles that in the common case; adjust the position if your rulebase pins other rules above it.

4. Application Control allow rule

List the Access Control layers and identify the one that carries Application Control & URL Filtering in your policy package:

mgmt_cli -s id.txt show access-layers

Add an explicit allow above any rule that blocks anonymizers or unrecognized applications. On an Application Control layer, the Services & Applications column is addressed through the rule's service field, so the OpenVPN application object from the Check Point application library goes there:

mgmt_cli -s id.txt add access-rule layer "<APP_LAYER>" position "top" name "Allow RTA OpenVPN" destination.1 ".connect.remotetesting.secureworks.com" service.1 "OpenVPN" action "Accept"

If the OpenVPN application object is not in your library, create the custom application described in the GUI guide's Application Control step (the API equivalent is add application-site) and reference that object name in service.1 instead.

5. IPS exception (if IPS blade is active)

A Threat Prevention exception hangs off a rule in your Threat Prevention layer, so first find the layer and the rule number:

mgmt_cli -s id.txt show threat-layers
mgmt_cli -s id.txt show threat-rulebase name "<THREAT_LAYER>"

Then add the exception, mirroring the GUI guide (Destination = the RTA endpoint, Protection = Tunneling Protocols, Action = Inactive):

mgmt_cli -s id.txt add threat-exception layer "<THREAT_LAYER>" rule-number <RULE_NUMBER> position 1 name "RTA tunneling exception" destination.1 ".connect.remotetesting.secureworks.com" protection-or-site.1 "Tunneling Protocols" action "Inactive"

If logs showed a specific triggered protection, use that protection name in protection-or-site.1 instead.

6. Publish and install the policy

Publish the session, then push the policy to the gateway. Find the package and gateway names first if you do not know them:

mgmt_cli -s id.txt publish
mgmt_cli -s id.txt show packages
mgmt_cli -s id.txt show gateways-and-servers
mgmt_cli -s id.txt install-policy policy-package "<POLICY_PACKAGE>" access true threat-prevention true targets.1 "<GATEWAY>"
mgmt_cli -s id.txt logout

Confirm the installation completes without errors before testing.

Verify

From a host on the same network segment as the RTA appliance, confirm the port is reachable:

nc -vz connect.remotetesting.secureworks.com 443

Expected output:

Connection to connect.remotetesting.secureworks.com port 443 [tcp/https] succeeded!

After the RTA is powered on and the policy is installed, allow 60 to 90 seconds for the OpenVPN tunnel to negotiate. To confirm the traffic is being accepted and bypassed (or to see which blade is still dropping it), check the logs as described in the GUI guide's Logs & Monitor section.