Policy Manager rules applied to all devices

[FredMcfly]

I am using tags to setup rules in the Policy Manager. But for some reason the rules are being applied to all devices, even if the tag is not applied to a device.



For example,

Device A is tagged with "Internet", "Sunday", "NightTime", and "Dinner"
Device B is tagged with "Internet"

When the time of day is 17:00, then both devices have internet.
When the time of day is 17:30, then both devices have no internet (undesired behavior). Even though Device B doesn't have the "Dinner" tag. I would have expected Device A to have no internet but Device B has internet (desired behavior).


Can anyone explain to me why this is the case?
Can anyone explain to me how to setup the rules properly?

[gravenscroft]

Tags are unreliable for most purposes involving things like routing, Policy Manager selection, &c. They're really only useful for organization purposes. It's much more effective to use IP addresses.

The reason for tags' unreliability is that it takes the NG Firewall a tiny bit longer to 'notice' the presence of a tag. That time is very short, but it's still long enough that in some cases, the traffic will already have been processed as though the tag didn't exist. It's sort of like handing someone an object and only then noticing that they're not the person you meant to hand it to: they've already got the object in their hands.

[FredMcfly]

Thanks for the reply and really good information to know. I assume that since I had similar issues with the Username field that it has the same issue. Correct?

So basically, for NG Firewall the correct/best way to handle routing rules in Policy Manager is to use IP addresses?

[gravenscroft]

Usernames are more reliable in every case I've seen; there are many deployments that are integrated with Active Directory and rely on username associations to work correctly. It can depend on how you're using them. For example, the operator is not will only take a single value, so something like Username is not john,mary,david won't work.

It looks like your rules are ordered properly, which is another common gotcha in NG Firewall: any list of rules which can be reordered is read from the top down and only the first matching rule is fired.

[FredMcfly]

I have used this rule set in the past with the same behavior as the tags (in this setting Default was internet access).

In this case, all devices, including those with Parent username, had no internet at 23:00. Even though Parent is not part of the No Internet-Nightime rule. (You can ignore the "Tagged" portion of the rules, it was an attempt to fix the issue, but it didn't work.)




I guess I should ask, can multiple devices have the same Username?
I haven't read anything that says they can't, but maybe I am using Username incorrectly.

[FredMcfly]

From your previous comment, I do understand that the rule "No Internet - New Devices" won't work.

Does this mean that the operator is will only take a single value, so something like Username is john,mary,david won't work?

[Update]
The firewall syntax page states that john,mary,david will work fine for 'is' rules, but will not work for 'is not' rules.

https://wiki.edge.arista.com/index.p...ll_Rule_Syntax

[FredMcfly]

So I have tried using Username where each rule has a single Username.
I have tried using Tags.
I have even tried assigning all devices a static IP address and then creating rules (see below).

But no matter what I do the rules apply to ALL of the devices. I would really appreciate some help. What am I doing wrong?





For example, a device with IP address 192.168.2.10 will have no internet between the hours of 23:00-07:00, even though no Internet blocking rules should be applied to it.

[gravenscroft]

The firewall syntax page states that john,mary,david will work fine

No, it doesn't. It gives examples of conditions that can be used, with the implied operator being is.

The operator is not will only take one value. You're welcome to specify any number you like, but the rule will not work if there is more than one value in that field.

For example, a device with IP address 192.168.2.10 will have no internet between the hours of 23:00-07:00, even though no Internet blocking rules should be applied to it.

Rule order: only the first matching rule is triggered. In your screenshot, 192.168.2.10 is included in your very first rule, 'Parent'. This means that 192.168.2.10 always falls into your 'Internet' policy. More-specific rules go towards the top of the list, with less-specific rules placed below.

[FredMcfly]

No, it doesn't. It gives examples of conditions that can be used, with the implied operator being is.

The operator is not will only take one value. You're welcome to specify any number you like, but the rule will not work if there is more than one value in that field.

Thanks for clarifying this, very helpful

Rule order: only the first matching rule is triggered. In your screenshot, 192.168.2.10 is included in your very first rule, 'Parent'. This means that 192.168.2.10 always falls into your 'Internet' policy. More-specific rules go towards the top of the list, with less-specific rules placed below.

That was my understanding, but it doesn't appear to work this way.

I want 'Parent' to always use the 'Internet' policy, which is why I put it at the top. But if any of the other rules are enabled (for example, 'Games - Dinner time') then 192.168.2.10 somehow falls into the 'No Internet' policy.

So even though the 'Parent' rule is first, a device with IP address 192.168.2.10 is somehow applied to 'Games - Dinner time' rule.

I have had the same behavior in all of my attempts to create these rules. Which is why I am so confused.

If a device has IP address 192.168.2.10, then why does it seem to fail the 'Parent' rule and match the 'Games - Dinner time' rule?

[FredMcfly]

Can anyone explain to me why a device that has IP address 192.168.2.10 fails the 'Parent' rule but matches the 'Games - Dinner time' rule?

[gravenscroft]

A rule has to have all its conditions met in order to trigger. If the device isn't subject to a particular rule, then it doesn't meet the conditions. Sounds like the device doesn't actually have .2.10; it has something in the .2.51-.2.70 range.

[FredMcfly]

I assigned the device a static IP address and verified on the device that it actually has the .2.10 IP address.

I have done this to all devices connected to the network and all have this same behavior. Even for devices that I have verified that they have the correct static IP address.


The frustrating thing is that the this behavior also existed when I was using Username. Rules would fail to trigger even though they should have.

For example, I would have devices with the Username 'Parent' and the first rule would check if the Username was 'Parent' and be assigned the policy of 'Internet'.
The second rule would be for bedtime. It would check if the Username was 'Kids', if the time was 23:00, and if the source address was LAN and be assigned the policy of 'No Internet'

But at exactly at 23:00 then all 'Parent' devices would lose internet access. So for whatever reason it was failing the first rule and the second rule was being applied.

But it shouldn't have failed the first rule.



Are there logs that I can see that tell me what rule is being applied to a device and what the parameters are? So I can see why a rule is failing.

For example something like this,:

23:00 Device MAC address 34:56:ae:53:24, username: Parent, IP address: 192.168.2.10, Source address: LAN, Target Policy: No Internet

[FredMcfly]

For all those who follow after me, I was never able to solve the problem.

And after months of fighting with schedules I gave up and moved to a completely different firewall management system where the scheduling rules work for me.

[JBHorner]

This thread was unfortunate to read. This firewall solution does not support aliases. The general view I found during research was that tags could be used instead. Tags aren't as elegant as aliases, but if they worked it would still serve the same purpose. (In a Cisco world Aliases would best correspond to object-groups.)

For all that do not know what aliases are, they are a way of grouping like objects into a group name, and using that name in rules (ACLs in Cisco). For example, one might have a desire that any member of a group might be blocked (or allowed) to do something across subnets. Absent a group, a rule must be created for EACH member of a group. Tags would have been helpful if they worked. (I found they didn't in the filter rules.) Now, if I want to have an exception to a rule, I would have to create separate rules for each device's MAC address. That is beyond inefficient.

I'm glad I found this out now, as it cuts short an evaluation I was doing on behalf of a client. I'm finding way too many problems that the client would have to work around. This seems like a solid product on the surface, but only for very simple implementations. Unfortunately, this one won't make the shortlist for this particular client. I hope that this product evolves quickly and incorporates what many now would consider table stakes.

[JBHorner]

The frustrating thing is that the this behavior also existed when I was using Username. Rules would fail to trigger even though they should have.

This is actually dangerous. Someone has written rules expecting that they'll work, only to find out they didn't. It's a bad actor's dream...