ACL (Access Control List) rule order issue
-
@johnpoz "apply" I must have gotten mixed up with the verbage. Why does my rule set order get mixed up directly after?
Make sure to upvote
-
@JonathanLee have no idea - have never seen that ever happen, ever..
Are these rules copied rules, there was a thing before that when copied a rule it would reuse the RID.. Maybe something like that could happen.. maybe you actually had the rule order changed, and never "saved" it and then when you apply rules it puts them back to the original order?
I don't use seps for rules - I could add them and try and duplicate your issue. But again in all my years with working with pfsense, I have never seen that ever happen.
I would look at your rules. Save the order, then edit some rule - could be as something as editing the description - then hit apply.. Does your order change?
You might want to remove your separators, and try again - do your rules reorder without those? I will add some seps to my rules and see if I can duplicate.
-
@johnpoz some of the rules I have created from the copy icon next to the original rule. I can attest to the fact one time I was missing my separators that might point to some issues with them as you don't use them.
Make sure to upvote
-
@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..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@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?
Make sure to upvote
-
@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.
-
@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.
