For understanding the relation of a single security management server (SMS), managing multiple firewalls.
For understanding the use and relation of different Policy Packages, and policy install targets.
To clarify our practice of MSSP deployments, where a single SMS manages multiple firewalls.
IMPORTANT: Mishandling of multi-gateway deployments can easily cause hard down situations. For this reason the “Policy Install Targets” is a configuration that is reserved for engineering.
IMPORTANT: If you EVER get a warning on Policy Install that says “You are about to install policy <pkgX>, but <pkgY> is currently installed, are you sure you want to continue?” Then answer NO and revert all changes, load <pkgY>, and make changes there. Hint: “File” menu > “Installed policies…” will tell you what policy is currently installed on which firewall.
For Nexum MSSP deployments, in order to install policies to multiple firewalls:
1) Check the firewall’s portal page > management notes. There you will see a Managed by <SMS hostname> w/policy <policy pkg name>.
2) Go to <SMS hostname> portal page for “fwadmin” creds, and Check Point version.
3) From a MSSP terminal server, open the appropriate (same as SMS) version SmartDashboard.
4) Upon launching it will display the currently loaded policy package in the window title for the client (in R75.4x, you must get off the “Welcome” tab in order to see it). If it is not the correct policy package, go to “File” menu > “Open…” and select <policy pkg name>. If you are on the right one already, it will not be listed as an option in the open pop-up.
SmartDashboard’s window title will be “<SMS hostname or IP> – Check Point SmartDashboard <version> – <policy pkg name>”
5) After confirming correct policy is open, make changes
6) Install policy and make sure the correct device is listed as an install target.
a) IF IT IS NOT: i) confirm you have the correct policy package loaded (you can “Open…” a different policy then “Open…” again to confirm that way too, as the policy you were in should be listed now). ii) Use “File” menu > “Installed policies…” to confirm current policy installed on device is same as listed in portal.
b) If any item in 6-a looks suspect STOP RFC, revert changes, if emergency or greater than 24 hours since the RFC was submitted by customer, then contact on-call so it can be sorted out.
Further explanation follows:
Given the nature of Check Point distributed deployments (see SMART explained), an SMS can manage multiple firewalls; however, it can do so in multiple ways which can cause confusion…
There are three major components to the SMS that gets installed to a gateway when installing policy: objects and users databases (see faq Objects and Users Database explained), protections databases (if applicable– such as the IPS definitions and URL filtering database), and policy packages (firewall / NAT policy, QoS, etc).
Except in Provider-1 (Multi-Domain management, none currently under MSSP) environment, and except for the policy packages all of these components are shared by all firewalls managed by that SMS. For example if you create a new object in policy <pkgX>, that same object (and all of that Object’s properties to include automatic-NAT rules, ## so it is important that when defining NAT in the NAT tab of an object, you specify which gateway to install on, but I digress ##) exist in policy <pkgY>.
The Policy packages are the collections of all firewall / NAT rules. You can have multiple policy packages on one SMS. All normal “File” menu operations (as in “New…”, “Open…”, “Save…”, “Save as…”) all refer to the policy package. Each policy package has a set of defined “Policy Install Targets”, which is the firewalls that this policy package CAN be installed to.
So the first way (and the way that Nexum f*d uses for our MSSP deployments) is to have multiple policy packages, one for each firewall, and limiting the “Policy Install Targets” to just the one firewall per policy package (thus the reason the Policy Install Targets is L3+ config, not even a customer should ever request this to be changed).
The second way (not currently an MSSP practice or requirement), which is good in situations that you have a lot of firewalls that pretty much has the same rulebase, is by defining the install targets on a per rule basis. As you can imagine, that in situations were the firewall policies for different devices are completely different, this becomes a huge admin headache after a while.