2.1 Policy Packages

What a Policy Package Is

In Check Point R82, a policy package is the unit of distribution between the Security Management Server and one or more Security Gateways. Instead of pushing individual rulebases, the management server compiles a package that bundles the relevant policy layers — Access Control, Threat Prevention (IPS, Application Control, URL Filtering, Anti-Bot, Anti-Virus, Threat Emulation/Extraction), NAT, HTTPS Inspection, and Mobile Access — and installs the whole package onto the target gateways in one operation. The package is compiled on the management server, transferred over the Secure Internal Communication (SIC) channel, and activated on each gateway by the Firewall Worker process.

A common mental model is to treat the policy package as a container with two parts: the layer contents (the rules, their order, and the objects they reference) and the installation targets (the list of gateways that should receive it). When you click Install Policy in SmartConsole, you select a policy package, the management server compiles it for every targeted gateway, and each gateway loads the compiled policy into kernel memory for enforcement.

The Default Policy Package

When a Security Management Server is first initialized, Check Point creates a default policy package named Standard. The Standard package contains an Access Control policy with the default Network layer, plus empty Threat Prevention and NAT layers ready for customization. Most small and midsize deployments use only the Standard package for their entire rulebase. The default package is not magical — it can be renamed, removed (if unused), or augmented with additional packages, but you should never delete the only remaining policy package on a management server without first creating a replacement, because gateways cannot enforce an empty policy slot.

Layer Types Inside a Package

A policy package can include several layer types:

• Access Control layers — ordered layers and inline layers that enforce the firewall rulebase, the core of every package.
• Threat Prevention layers — IPS, Application Control, URL Filtering, Anti-Bot, Anti-Virus, Threat Emulation, and Threat Extraction. These layers are typically shared across gateways through a single Threat Prevention profile.
• NAT layer — one NAT layer per package, holding Automatic and Manual NAT rules.
• HTTPS Inspection layer — defines outbound HTTPS inspection policy.
• Mobile Access layer — used by Mobile Access Software Blades on the gateway.

Each layer is edited in its own SmartConsole tab, but all are installed together when the policy package is installed.

Sharing and Multiple Packages

R82 supports creating multiple policy packages on the same management server. Reasons to use multiple packages include:

• Per-gateway specialization: a branch gateway may need a different rulebase from the data-center gateway, but both are managed centrally.
• Compliance isolation: a PCI-scoped gateway may require its own rulebase that change-controlled separately from the general rulebase.
• Multi-tenant management: Managed Security Service Providers (MSSPs) use Domain Partitioning with separate packages per tenant.

A package can target one gateway, a subset, or all gateways. When the same package is installed on multiple gateways, the rulebase is shared: every gateway gets the same rules, but rules can use gateway-specific object behavior (for example, a rule referencing the gateway's own external interface resolves differently per gateway). Use inline layers or per-gateway enable/disable settings on individual rules to create exceptions without fragmenting the package.

Installation Behavior

Installing a policy package is non-disruptive for established connections by default — R82 preserves the connection table so in-memory flows continue under the new policy. New connections are evaluated against the freshly installed rules from the moment the gateway activates the package. If a rule change must affect existing connections (for example, dropping a now-forbidden flow), administrators can enable Reset on Policy Install for the relevant rule or run fw unloadlocal on a gateway to clear its connections — but this is exceptional, not the default.

Failed installations are visible in SmartConsole's Install Policy dialog and in the install logs. A common cause is a SIC trust failure between the management server and the gateway, which must be re-established before the package can be pushed.

Policy Package Best Practices

• One package per logical administrative domain. Avoid creating dozens of packages for minor variations; use inline layers and per-gateway enable flags instead.
• Version control via snapshots. Before a major rule change, take a management database snapshot so a rollback is one restore away.
• Name packages meaningfully. Names like Standard, Branch-Edge, PCI-DMZ are easier to audit than Package1 and Package2.
• Use the Install Policy dialog's Preview option. It shows which gateways will receive the package and flags compilation errors before the actual push.
• Schedule after-hours for large rulebase changes. Even though policy install preserves connections, the validation and compile step can briefly increase management CPU load.

Exam Framing

For the CCSA R82 exam, treat policy packages as the delivery vehicle for policy layers. Know that the default package is named Standard, that one gateway enforces one Access Control policy at a time, that packages can be shared across gateways for consistency, and that install preserves the connection table by default. These facts show up in questions about multi-gateway deployments, package naming, and the behavior of install versus uninstall (fw uninstalllocal removes the policy from a gateway entirely).