"Check Point" does not recommend using global objects?

[George_Ellis]

I think I end up with this subject every 5 years.  We are an 11 domain shop.  We have 6 domains that cover our 2 main and the original data centers.  Others are all for the other regions, all which talk to the data centers.  Therefore, we moved to using global objects across all the domains because it seriously cuts down on work and errors creating network objects.  We do not use service objects as globals because the rule compiler does not handle shadowing well with a mix of global and local service objects.

So, "someone' has recommended that we curtail the use of global network objects (host, network, range).  Considering it is create once, share versus, create numerous increasing the chance for error.  Which is humorous in that I think the issue is the API application is including invalid characters.  My guess from the limited conversation assumes that an invalid global is created, pushed, and then there are errors in each domain.  Shoot, if they generated it wrong in the first place, they will do it wrong locally.

The philosophy has been maintain one object list, not many in X number of domains.  It reduces errors, and now 80.30 221+ will show unused global objects.

I have yet to see a compelling argument that would make me change my mind.

[_Val_]

I certainly understand where you are coming from. Indeed, at a first glance, using global objects seems to help simplifying policy administration.

However, there are certain, sometimes serious, implication.

• Global objects are pushed to the local domains from the global DB. As you mentioned yourself, an incorrectly configured global object, after being pushed, cause errors on the local level.
• When being pushed, the system does not check where the global objects are used in the local rules. If an object reconfigured, that may break policy logic.
• When you delete a local object, your DB check if it is being used in a policy. That does not happen for global objects. If the deleted global object was the last in a local rule, it is then replaced with Any, which may cause security concern.
• Among other things, you cannot detach or migrate a local domain if there are global objects used in it. 

The established, verified and generally good practice is not to use global objects in local policy rules and only use those as part of global policy.

That said, there is always another way, and you certainly can decide what is working or not. Just make sure none of the above happens to you 🙂

[Bob_Zimmerman]

One complication with this is that FQDN objects match based on the name of the object. Thus, it is impossible to have a global FQDN object and a local FQDN object which both match the same domain name. Local rules which grant more access to the domain than global rules must reference the global object.

Fortunately for me, the elimination of the global write lock and the addition of inline layers have basically eliminated the reason I have Provider-1 in my environment.

[George_Ellis]

On point 2, Check in Take 221 for R80.30.  I mentioned it before when it was released, but now the MDM knows where the objects are used in the domains.  

[_Val_]

Correct, not on the latest versions

[aheilmaier2]

in addition you can not migrate a domain away from MDS if global assignments are done.

found it out the hard way https://support.checkpoint.com/results/sk/sk156072

Migration of a Domain from a Multi-Domain Security Management Server to a Security Management is not supported if the Domain is assigned to the Global Domain.

[George_Ellis]

Here is where Show Package is your friend.  Well, that and MS Excel.  You can use Excel Power Query to convert the json files (ask Grok - it should remember - Data tab, Get Data, From File, From JSON - Convert Table with as default.  You look for the non-drop down icon in the titles to expand the list, use comma delimited).  You create a sheet for your Objects and for your Network (rules).  Issue:  Src, Dst, and Service are listed as UIDs.  On your policy page, assume Column A is Src.  Add a blank column after it (or anywhere really).  In the objects sheet, you rearrange Name to Column A and UID to column B.  On the policy sheet, paste this equation into the new column were you want the translated names:

=LET(
uidList,TRIM(TEXTSPLIT(A2,",")),
names,XLOOKUP(uidList,'FW_Policy_objects'!B:B,'FW_Policy_objects'!A:A,""),
valid,FILTER(names,names<>""),
TEXTJOIN(", ",TRUE,valid))

I know, a little abbreviated (well a lot).  But now you generate a CSV with the fields for a mgmt_api creation of FW rules.  Macros can be built to even give you the complete format.  You can also use the objects page and macros to find the used vs unused and only create the objects you need.

[Kaspars_Zibarts]

Can't agree more @George_Ellis ! We are in exactly the same boat - one organisation but 20 domains mostly to segregate global regions and business functions. But as any other big enterprise some services are truly global i.e. active directory etc, so the easiest way to handle those scenarios is by using global objects, else you ended up in total mess - in cases where local objects were used across multiple domains administrators often "forgot"to update odd group or port or rule here and there so after couple of years rulebases grew apart by miles and no one knew which one was totally correct. Having one central management for those has saved our day!

[Maarten_Sjouw]

Same here, we run a number of MDS's with in total about 180 domains and we use Global objects all over the place. This has bitten me is the a** when we needed to move domains from a R77.30 MDS to a R8x MDS as we needed to remove the globals before we could do an import.

But using global rules for monitoring, allowing dynamic routing and other generic rules like the drop rules, all have been moved into global rules and ie rfc1918 objects are also used all over the place.

[David_Evans]

We also heavily use Global Objects for most of the same reasons you list.    One 'compelling' argument currently against them is that a global policy push is one of the things that breaks ALL accelerated R81 to R81 policy installs.   So even if the 1 global object that changed in global push to the domain is only used  in 1 policy.   Every policy to every R81 firewall will not be able to utilize the accelerated push the first time after a new global change.
I really hope that this is something that is addressed.