Use of LocalMachine object

[Trevor_Bruss]

Is anyone using this object directly in their rulebase and is there any problems with its use? I noticed that it was used in implied rules. We want to create a rule for SNMP management of our systems and thought this could dynamically include any gateway that this policy is applied to.

What is the difference in using this object as opposed to creating a group with the gateway objects themselves? Does the gateway object only refer to the IPv4 Address on the general properties of the FW object, or is it smart enough to see all of its interfaces? 

[PhoneBoy · Accepted solution]

LocalMachine is an example of a Dynamic Object.
If you open the object, you'll notice that there is no IP address associated with it.
The IPs are locally defined on the gateway.
LocalMachine is one of the default ones the gateway updates on its own, which I believe only resolves to the external IP.
If you want all interface IPs, then use LocalMachine_All_Interfaces.
You can create arbitrary dynamic objects and update their definitions using the dynamic_objects CLI command on the gateway.

A couple small limitations with Dynamic Objects:
1. They can be used in Access Policy and NAT rules only.
2. In pre-R80.10 gateway releases, usage in the policy disables SecureXL templating for that rule and any rule after, leading to decreased performance (R80.10+ does not have this limitation).
3. Any Access Policy rule that uses a dynamic object must have an explicit "Install On" target, otherwise policy installation will fail.

[Trevor_Bruss]

Thanks for that information. The last part about using "Install On" probably explains the error I saw when trying to push the policy without doing that on the rule and just using *Policy Targets. I could likely produce the error again by setting up the rule again, but it was something along the lines of the DAIP configured on the members. In either case, for now I'm just targeting the GW objects as the source and leaving it at that.

So I guess that begs the question, if I can use the dynamic object but I still need to target it toward a specific gateway on the rule then do I gain any benefits from using that dynamic object over a simple group with the targeted gateway objects in it and "Install On" set to Policy Targets. Perhaps that was where I was trying to understand if the Checkpoint GW object "sees" all the interfaces and therefore it can match regardless of which interface it goes out/in.

Thank you again for the information!

[PhoneBoy]

Dynamic Objects can be updated without a policy installation, whereas if you manually put the group in a rule, if you update that group or any objects contained therein, it requires a policy installation to take effect.
Remember also that Dynamic Objects resolve locally on each gateway, so the rule has to make sense in the context of the gateway itself.
Which means, in this specific case, it would make sense as a destination in a rule, but not as a source.

[Gingerwerewolf]

Quick question, and sorry for thread necromancy here: But is this true of ALL Dynamic Objects? IE Security Zones and the like?

[PhoneBoy]

Yes, this is true for all the various "dynamic" objects:

• Classic Dynamic Objects
• Access Roles (relevant for Identity Awareness)
• Security Zones (adding/removing an interface from a Zone requires a policy install)
• Updatable Objects
• Generic Datacenter Objects (R81+)
• Network Feed Objects (R81.20+)

These can all be updated dynamically without a policy install.

[Gingerwerewolf]

Sorry what I meant was that they require the Policy Target column to be filled to work

[PhoneBoy]

No, that is only true of the classic Dynamic Objects.
SmartConsole will give you an error upon policy installation should you attempt to push a rule involving a Dynamic Object without setting the Install-On field.

[Dale_Lobb]

I read this thread a couple of weeks ago and had this great idea that I could build a simple policy for SMB devices that is very generic generic, based on the use of InternalZone, ExternalZone and LocalMachine and LocalMachine_All_Interfaces.   It turns out, however, that LocalMachine and LocalMachine_All_Interfaces can only be used in rules that apply only to DAIP gateways.  If the rule target is "Policy Targets" or includes a non-DAIP gateway, you get this message during policy installation:

--------------------------------------------------------------------------------
Gateway: XXXXXXXXXXXXXX
Policy: XXXXXXXXXXXXXX
Status: Failed
- Layer 'XXXXXXXXXXX Network': Rule 3: the "SOURCE" column contains the "LocalMachine" object therefore all installation targets of this rule must be DAIP modules in order to avoid conflicts
- Policy verification failed.
--------------------------------------------------------------------------------

The few posts, SK articles and docs that mention LocalMachine and LocalMachine_All_Interfaces never talk about this restriction.

[PhoneBoy]

What version/JHF did you find that?
I'm pretty sure you're pushing to an R80.20.x gateways based on past threads. 
In any case, that restriction doesn't make sense since non-SMB gateways (which are rarely DAIP) work with LocalMachine just fine.

[Dale_Lobb]

Yes, the SMB gateway is R80.20.50.

The management system is R80.40 take_180.

[PhoneBoy]

Curious if this is something we "fixed" in a later release.
Will have to possibly lab this up and see.

[Chris_Atkinson]

I saw this in a lab involving R81.20 and just put it down to the EA or standalone deployment at the time, definitely has wider use than just DAIP

[Dale_Lobb]

So, I should open a ticket about it?

[Chris_Atkinson]

I would yes. 

 @PhoneBoy  and I will enquire further also.

[Dale_Lobb]

Done!  Case #6-0003443572

[Dale_Lobb]

  Well, that was useful.  About 10 minutes after my last post, I got a call from TAC.  Basically, the person on the other end kept telling me that you cannot use LocalMachine in policy rules that refer to non-DAIP gateways, because, well, you can't; because LocalMachine is a dynamic object and only applies to DAIP gateways, and non-DAIP gateway have real objects in the policy and you are meant to use those instead of LocalMachine.  After several minutes of circular conversation, I informed the person that I would take it under advisement... 

  Here is what got posted to to the case:

As we discussed over call in reference to the error message provided, the source for Rule 3 is the gateway its self and is not dynamically assigned an IP address, along with the dynamic object "LocalMachine" that refers to the gateway but should only be used if it is dynamically assigned an IP is why the policy installation does not work. I would recommend to use the Gateway Object that is already generated as the source for Rule 3 and policy installation should work without any issues. Please feel free to reach out if you have any other questions.

  He never understood my argument that I was not questioning why I am getting the error, but rather arguing that LocalMachine should apply to more than just DAIP gateways.

[Chris_Atkinson]

Hi Dale, I'm following up internally and will update you.