ACL (Access Control List) rule order issue
-
@JonathanLee ok added some seps.. So when you move a rule, notice it should have its check mark set, and the color of the save button changes.
Once you hit save, the color changes and the apply button should show up.
I then edited a rule - and while the apply button shows up the save button does not change color.
I tried all kinds of edits, even adding rules - I can not get it to do what you are saying its doing.
-
@johnpoz could it be a 2100 thing? I wonder why it all the sudden started doing this for me.
-
@JonathanLee I would go over the rules with your mouse over them and make sure all the IDs are different.
Prob better yet, look at your /tmp/rules.debug with cat and see if any duplicate RID or IDs
edit: I don't see how it could be related to a specific appliance - that makes no sense at all..
-
@johnpoz I found the issue, as soon as I removed all the "Seperators" the order stays.
(Rule set before I have made changes to rule #3 no seperators)
(Rule set after I have made changes with no separators resulting in no mix ups)Why is the seperators causing this issue for my system?
-
@johnpoz I have also checked for duplicate tracking ids. I have none thankfully. It took longer than usual to apply after I removed the separators. Once the first apply was completed now it has no issues again. Weird right?
-
@JonathanLee if I had to guess, you were not saving after a move or something. Again in all the years I have been using pfsense, and all the years on this board. I have never seen this for sure, and do not recall ever seeing anyone reporting such an issue.
Maybe there is something weird with separators? I personally have never used them, other then testing then when they first came out. I believe lots of people do use them, so if there was some issue with them - you would think it would have been reported. Would have to go through redmine to see if such an issue has ever been reported.
Rule order is vital part of firewall, so if there was something that was re-ordering rules.. It would be of great concern.
-
@johnpoz So something got mixed up from a backup config or something and never was fully applied and stuck and bonked up, it is fixed now. Removing the separators did resolve my issues. Your right this was a one off for me too. I originally thought it had to do with the experimental layer 2 rules. You know how I test stuff and reapply the old config I saved all the time, I wonder if one was mid save and I reapplied it and the mid save was just in a half way point.
-
@JonathanLee maybe - I have not done anything with the new L2 rules as of yet, I have no use for them.. I don't see playing with them even until someone has a question about them that interests me enough to play with them ;)
-
@johnpoz they have an open Redmine for this issue, I think the layer 2 rules makes my rules get even more bonkered up.
https://redmine.pfsense.org/issues/14691
https://redmine.pfsense.org/issues/14619
Mine is duplicate of the other two
https://redmine.pfsense.org/issues/14705 -
@JonathanLee creating duplicate redmine isn't going to help anything - if you have info related to a redmine, you should add your details to the existing redmine vs creating another one.
-
@johnpoz I understand, but like you I didn't know any open ones existed. So I created one and learned they have a couple similar Redmines already open.
-
@JonathanLee said in ACL (Access Control List) rule order issue:
@johnpoz I found the issue, as soon as I removed all the "Seperators" the order stays.
I have a "Sepetator/Order issue too" , when i do a copy "rule" from on if to another.
See:
https://forum.netgate.com/topic/182063/when-copying-a-rule-from-one-if-to-another-it-seems-like-pfsense-is-reordering-the-rules-wrongSeems like this one addresses it ... But for 2.8.0 , and made 6 days ago.
https://redmine.pfsense.org/issues/14691My issue was reported to stephenw10 15 days ago
/Bingo
-
@JonathanLee said in ACL (Access Control List) rule order issue:
I restore the last config change and it goes back. I also noticed one day my separators some were all the sudden missing. Just weird
This is due to previous bugs (fixed in dev snaps) where the separator could end up with an out of range index. This is fixed with #14619.
Regarding the rules themselves changing order, I can only replicate that if I change the config while editing a rule. For example, start editing a rule on one browser tab, make rule order changes on another tab, then save the change in the original tab. This is known behavior that is due to the index being "cached" while an entry is being edited. There are other places in the GUI that behave like this, and supporting simultaneous changes to the config warrants a much broader code change. Until then, make sure that rules/aliases/etc are changed one at a time.
-
@marcosm said in ACL (Access Control List) rule order issue:
make sure that rules/aliases/etc are changed one at a time.
Great advice!
-
@marcosm thanks for the update and looking into this.
The only resolve for me was to just remove the separators for this. I am glad to see it has already been resolved in the next release.
-
johnpoz LAYER 8 Global Moderatorlast edited by johnpoz Aug 23, 2023, 11:57 PM Aug 23, 2023, 11:57 PM
@JonathanLee on a side note, why are you blocking multicast 224.0.0.0/4 and labeling it known infection source?
What on pfsense do you think would even be listening on multicast? And it sure wouldn't go any further than the local network.. Blocking it at pfsense doesn't stop it from reaching any other device on that network.. So if you honestly think it is used to spread some infection, blocking it at pfsense isn't doing anything.. Other then stopping pfsense from seeing the traffic, if there was something listening.. Which off the top of my head, I can't think of why pfsense would need or you would want pfsense to see any multicast traffic.. Unless you were doing something with avahi or something.
So its not really going to hurt anything. But the rule is pretty pointless..
-
@johnpoz we talked about this in the past, I do not use any iot devices or Amazon lightbulbs. I have zero multicast devices at my house however traffic was going to that weird I think it was 225.225.225.224 multicast address. Remember, a couple months ago you said you too blocked it at your switch. The notes on it is just wrong it should say multicast, but it's carried over from the wan bogon rule I made, again that is already built into the bogo rules I cloned it from wan into lan. I see it everyonce and a while block multicast traffic but not much.
There I fixed the description now that my rules stay in order
. I agree that should not say that on the LAN side only on wan side. -
@JonathanLee said in ACL (Access Control List) rule order issue:
Remember, a couple months ago you said you too blocked it at your switch
I do block it at the switch, but a switch is not pfsense. Blocking it at pfsense doesn't stop it from going to every device on the network. Its multicast.. It goes everywhere on that L2 network.. I block it at the switch because its NOISE, if your not using it.. I am not using it - so its noise.. If you do not want the noise, then you should stop it at the source, or on the switch.
Even if you block it at every device on the network - unless you stop the device that is sending it, its still noise on the wire.. I block it at the switch, so some device sending it.. I believe in my example it was stupid plex.. I couldn't turn it off at plex so I stop it at the switch port plex is connected too - so it can't go to every other device on the network. Its not a "infection" source its noise.
Again - like I said its not hurting anything, its just pretty pointless. Do you understand how multicast and broadcast traffic works? Blocking it at the router doesn't do anything about the noise, it just stops the router from seeing something it wouldn't do anything with anyway.
All the other devices on that network still going to see it, while in the big picture a few extra packets on the wire isn't a bit thing, but you multiple it by 10 devices or 100 devices all spewing noise it can amount to well a lot of noise ;)
Think of it this way, if you leave the TV on at a level that everyone in the house can hear. if you put in some earplugs you might not hear it, but everyone else in the house can still hear it. Blocking it at pfsense amounts pfsense just putting in some ear plugs that block multicast traffic - all the other devices on your network still going to see it ;)
When I block it at the switch, while I might not turn the tv off - I close the door to that room, now nobody else in the house can hear the tv noise.. Does that make sense?
This is what I block at the switch
The specific noise I do want going everywhere on the network.. That 239.255.255.250 is the specific plex ssdp. That 224.0.144.1 is something specific that off the top of my head I do not recall why I was blocking it, have to look to see what is sending it again. That broadcast 255.255.255.255 on port 6667 is noise my wifi lightbulbs send out.. There is no reason for it to leave the port the AP is connected to and go to every other device on my other AP, or my other devices that might happen to be on that same L2 network, which is used by all my iot devices..
edit: here this is a 12 second dump on my 1 AP, see the noise..
-
@johnpoz what about when running a pcie mini card for wifi inside of the pfSense? I was think I originally wondering why it was establishing a connection to it so I just blocked it to stop it. It stopped the connections so I moved on. That was a post some time ago you worked on with me.
-
I just noticed that the separators all saved for some reason in the config.xml file but they are not showing up
This is on 23.05.01 and they appear all the sudden on 23.09.01 again
I deleted them ages ago they still cause issues. The separators are not even showing up I deleted them ages ago, ghost separators
