- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Use of LocalMachine object
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Use of LocalMachine object
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?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick question, and sorry for thread necromancy here: But is this true of ALL Dynamic Objects? IE Security Zones and the like?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry what I meant was that they require the Policy Target column to be filled to work
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the SMB gateway is R80.20.50.
The management system is R80.40 take_180.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Curious if this is something we "fixed" in a later release.
Will have to possibly lab this up and see.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, I should open a ticket about it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Done! Case #6-0003443572
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dale, I'm following up internally and will update you.
