Create and Install a Security Policy on a Check Point Gateway (R81.x)

Before you run this

This guide builds an Access Control policy in SmartConsole and installs it onto a Check Point Security Gateway. Building the policy touches only the management database; installing it is the moment that changes how the gateway forwards traffic. A policy that ends in the implicit cleanup drop, or one that removes the rule you rely on, can cut production traffic and lock you out of management in one push.

You need SmartConsole connected to the Security Management Server with an administrator account that has read/write permissions on the relevant policy package. No local root on your workstation is required; the equivalent CLI path (mgmt_cli) runs on the management server and needs a management admin login.

Treat this as a production change:

• Keep out-of-band access open. Have a serial console or a separate SSH session to Gaia on the gateway that does not depend on the traffic path you are about to change.
• Back up before you install. Every publish creates a database revision, but take a deliberate one: publish a clean baseline first, and take a Gaia snapshot of the gateway (add snapshot <name> in Gaia clish) and of the management server. Snapshots and revisions are your rollback.
• Do it in a maintenance window, and on a lab gateway or a non-production management domain first if you have one. Read every rule before you install — the order of rules and the cleanup rule decide what gets dropped.
• Rollback path: revert the database to a previous revision in SmartConsole and reinstall, or install a previously saved policy version. In a lockout emergency, fw unloadlocal in expert mode on the gateway removes the enforced policy and lets traffic pass — it is a security hole, so use it only to regain access, then reinstall a good policy.

Assumptions for this guide: R81.20, a distributed deployment (separate Security Management Server and Security Gateway), and SmartConsole running on a Windows admin workstation. A standalone deployment works the same way in SmartConsole; only the "Install On" target differs. Do not paste the CLI commands blind — confirm object and package names against your own environment first.

Step 1 — Connect and take a baseline

1. Open SmartConsole and log in to the management server.
2. Go to Manage & Settings > Revisions and confirm you have a recent, known-good revision. If not, click Publish once with no pending changes to mark a clean baseline you can return to.
3. Note the exact policy package name (top-left policy selector) and the exact gateway object name you will install to. You will need both.

Step 2 — Create the objects your rules reference

Rules reference network objects, not raw IPs, so create those first. In SmartConsole:

1. Open the Object Explorer (or the Objects pane on the right).
2. New > Host for a single server, or New > Network for a subnet. Give it a clear name and its address.
3. Repeat for each source, destination, and any custom service you need. Check Point ships most common services (HTTP, HTTPS, DNS, SSH, etc.) as built-in objects — reuse those rather than inventing duplicates.

Creating objects changes nothing on the gateway yet.

Step 3 — Add rules to the Access Control policy

With your policy package open on the Security Policies > Access Control > Policy view:

1. Select the rule above where the new rule should sit, then Add Rule Below (right-click, or the toolbar). Rule order matters — the first matching rule wins.
2. Fill the columns:
   • Name — describe the intent, e.g. "Allow web to DMZ".
   • Source / Destination — drag in the objects from Step 2, or leave Any.
   • Services & Applications — the service objects, e.g. https.
   • Action — Accept, Drop, or Reject.
   • Track — set to Log so you can see the rule matching later. This is how you verify the policy works.
   • Install On — leave Policy Targets unless you deliberately scope a rule to one gateway.
3. Confirm the cleanup rule at the bottom (Any/Any/Drop, tracked as Log) is present. If it is not, the implicit cleanup still drops unmatched traffic, but an explicit logged cleanup rule is standard practice so you can see what is being dropped.

Do not disable the built-in "control connections" implied rules (under Global Properties > Firewall) unless you know exactly why — they are what keep SmartConsole and the gateway talking during an install.

Step 4 — Publish

Click Publish. This saves your session to the database and creates a revision. Publishing does not enforce anything on the gateway — it is safe, and it gives you the restore point you will want if the install goes wrong.

Step 5 — Install the policy

1. Click Install Policy (top toolbar).
2. Confirm the policy package and tick the target gateway(s).
3. Under the install options, confirm Access Control is selected (leave Threat Prevention alone unless you manage it here).
4. Choose Install on each selected gateway independently for a single gateway; the "install on all or fail" option matters mainly for clusters.
5. Click Install and watch the progress. A green result means the policy is compiled, transferred, and enforced.

If the install fails verification, SmartConsole tells you which rule or object is the problem and does not push a broken policy. Fix it and re-install.

The CLI alternative (mgmt_cli)

If you script this from the management server, the mainstream tool is mgmt_cli. Verify object and package names against your environment before running — these are illustrative:

# Log in and save the session id to a file
mgmt_cli login user admin password 'REPLACE_ME' > id.txt

# Create a host object
mgmt_cli add host name "web-server" ip-address 192.0.2.10 -s id.txt

# Add an accept rule at the top of the "Network" layer
mgmt_cli add access-rule layer "Network" position top \
  name "Allow web to DMZ" source "web-server" destination "Any" \
  service "https" action "Accept" track "Log" -s id.txt

# Save to the database (creates a revision)
mgmt_cli publish -s id.txt

# Install the Access Control policy to the gateway
mgmt_cli install-policy policy-package "Standard" targets "gw-name" access true -s id.txt

mgmt_cli logout -s id.txt

Replace Standard, Network, and gw-name with your real package, layer, and gateway object names. For the full field list, see the Check Point Management API Reference for add access-rule and install-policy.

Step 6 — Verify

• In SmartConsole: open Gateways & Servers, select the gateway, and confirm the installed policy name and timestamp match what you just pushed.
• On the gateway (expert mode):

fw stat

This shows the enforced policy name, the install date, and the interfaces it is bound to. A stale name or date means your install did not land where you expected.

• Watch the logs: in Logs & Monitor, generate a test connection that should match your new rule and confirm it hits the right rule number with the expected action. This is the real proof the policy behaves as intended.

Undo / rollback

• Revert the database: SmartConsole > Manage & Settings > Revisions, select the pre-change revision, and revert, then re-install to push the previous rules back to the gateway.
• Gaia snapshot: if a change destabilised the gateway itself, revert the snapshot you took in "Before you run this" (see the Gaia Administration Guide for the exact set snapshot/revert syntax for your build — confirm it there rather than guessing).
• Emergency lockout only: on the gateway in expert mode, fw unloadlocal removes the enforced policy so traffic and management pass again. It leaves the gateway open — reinstall a known-good policy immediately afterward.

For anything you are unsure about — API fields, snapshot syntax, or install options — the R81.20 Security Management Administration Guide and the Management API Reference on Check Point's support site are the authoritative sources.