Same Rule ID for multiple Interfaces

bingo600

I think i saw some issue , if you used some new pfSense function of MultiEdit/Clone new rules.

I'm quite sure it was @JeGr that had the issue.
Maybe he could tell a bit more.

I also think i saw some possible pfSense bugfix, by adding a 1ms delay in between creating each new rule, might be in next release.

And i seem to remember a "workaround" of : "Editing" the rules w. same ID , and just press save , should create a new ID.

/Bingo

michmoor

@bingo600
This might be related to https://redmine.pfsense.org/issues/13507

But ultimately the problem is a Rule ID activated on several interfaces with the same source IP which doesn’t make sense.

bingo600

@michmoor
Sorry ... I obviously missed the essence of your post.
I was so focused on the "Same ID rules".

I'we never encountered issues like that, so i'm not of much help.

/Bingo

stephenw10

What is that rule? Is in on an interface group that contains all of those interfaces?
Check /tmp/rules.debug or pfctl -sr

Does that switch exist on all those interfaces/vlans?

Steve

michmoor

@stephenw10 I only have floating rules and Interface rules.

@stephenw10 said in Same Rule ID for multiple Interfaces:

Does that switch exist on all those interfaces/vlans?

Not sure what you mean. The firewall does use a trunked interface going down to the switch for several vlans [SLEEPY,WORK]and there are some untagged vlans on separate interfaces on the firewall that go down to the switch [LAN] and [DMZ].
The topology is NetGate6100 ---> Unifi L2 switch ---> LANs

What is interesting is that the only traffic type that this is capturing is IGMP. I would think that the Source IP would be blocked [192.168.50.200] as it appears on different interfaces with different L3 boundaries on the firewall
I ran the pfcts -sr command and now the output on the firewall logs are different -- traffic is getting blocked which you can tell is different from my original screenshot.

stephenw10

Right, the antispoof rule is what you'd expect to block that since that subnet is LAN and traffic is arriving on other interfaces.

That's not the rule that was passing it earlier.

I still wouldn't expect to see that traffic arriving on other interfaces though. It looks like either the switch is just sending it on all interfaces it has access to or it's leaking between them. But if it doesn't have access to STORAGE it may be something else.

Steve

michmoor

@stephenw10 The rule passing was a rule for the IoT vlan i have.
/root: more /tmp/rules.debug | grep 1661061805
pass in log quick on $SLEEPY_WLAN inet from 192.168.14.0/24 to ! $RFC1918 ridentifier 1661061805 keep state label "USER_RULE: Permit to Internet" label "id:1661061805"

Hard to say what the Unifi switch is doing as I have a Juniper switch that does not do this behavior. My guess is that the Unifi switch sends out IGMP Queries using its Management Address out each VLAN. Assuming that is true, why was the RuleID present on each Interface and permitting the traffic. Thats the bigger mystery and concern.

stephenw10

There no way that rule could have matched that so it has likely changed since then. The rule ID could have been referencing a different rule at that time.
Do you have any interface groups?

Do you have the IGMP proxy enabled? Or UPnP?

michmoor

@stephenw10
I do not have Interface Groups.
I do not have IGMP proxy enabled.
I do have UPnP enabled only on one vlan and thats Sleepy(IoT) - 192.168.14.0/24 you see above.
Because of the anti-spoofing rule i agree the rule wouldve never matched so not sure why the firewall GUI was showing something completely different.

stephenw10

The firewall logs pull up the rule description from the current running ruleset based on the identifier. But the ruleset that was running when that log entry was created may have been different. Thus what shows there as the 'Permit to Internet' rule may have been something different at the time. And that seems likely because there is no way that rule could have matched that traffic. Unless it was far more open previously.
However any single rule that could match all those entries would have to be something that applied to all interfaces. When you look at the ruleset directly that would be a rule without an interface specified.

Steve