Unsticky separators still an issue
-
pfSense+ 23.09.1 install. On the firewall rules of an interface group, I have 56 rules with 8 separators which breaks it up into 8 logical areas of configuration.
Whether I click to add a new rule to the bottom or to the top, it always adds to the top. When I check the separators after adding the new rule - they are now all one spot above where they were prior. I therefor have to then drag all 8 separators down one by one, by one spot, then save that.
[Edit: Further testing in the lab shows that it's a bit more nuanced than this. Clicking the green up arrow when adding is fine. Clicking the green down arrow is not fine though, and the behavior mimicks what was previously reported in redmine #14691 and closed off as fixed, but it's not fixed. See my more detailed testing notes further down]
Likewise if I delete a rule, for all the separators below the rule I deleted, they will be off by one spot, and I then have to drag each affected separator up by one spot, and then save that.
I found an old post where this was happening previously:
https://forum.netgate.com/topic/94732/unsticky-separators?_=1702361182327I tested on two different pfSense+ 23.09.1 installs where I have rules on an interface group, and it is happening on both. I tested on my lab firewall running pfSense CE 2.7.2 where I have rules on a regular interface (not an interface group), and it doesn't happen there.
I am at a loss to say why it is happening. I only just upgraded to 23.09.1 from 23.09, and prior to adding any new rules on 23.09.1 I noticed that all the separators were already out of place, so feel that it's not a new issue but it has been in 23.09 and perhaps earlier versions.
Can someone from Netgate please check this out? Let me know if you would like me to do further tests here and I'll happily oblige. Thanks.
-
Are you running pfBlockerNG?
if the rules are auto generated, the separators will appear to move every time the rules are recreated,
However if you use Alias types and create the rules manually, they won't move. and once you place them where you want
add the separators where you want and they won't move.without showing the actual rules, the rules are white and separators are the blue, and the order hasn't moved in months.
read the info section on the settings on each of these
-
@jrey hi there. I'm not using pfBlockerNG. I'll keep that in mind if I ever use it in future thanks.
-
@Gcon said in Unsticky separators still an issue:
Whether I click to add a new rule to the bottom or to the top, it always adds to the top
I've created rules outside of pfB and they still stay where they are placed.
if you select (highlight) the last rule in the table, and then click add with the arrow pointing down, the rule would be created under that last rule. (at the end of the list)
Then drag it where you like. Does that work ?using add up or add down when any other rule is selected As far as I recall as always added to the top or bottom of list and not above or below the rule selected.
I've got into the habit of alway adding rule, selecting last rule, adding below, dragging to place..
I thought there was a redmine issue for this, but haven't been able to locate it this morning. (it's still early)
-
-
@jrey said in Unsticky separators still an issue:
if you select (highlight) the last rule in the table, and then click add with the arrow pointing down, the rule would be created under that last rule. (at the end of the list)
Then drag it where you like. Does that work ?I select the very last rule, then click the green "<down arrow> Add", the rule I subsequently save (pass TCP port 179), gets added to the second item from the top - just below the separator that is at the top. All the separators after the first one are now all moved up 1 spot up from where they should be.
If I repeat but this time using the green "<up arrow> , the rule goes to the very top (above the initial separator), and all the separators are still in the correct position.
So Up arrow = good. Down arrow = bad.
Rule deletion is still a problem. When I delete a rule, the separators below the rule I delete are all down 1 spot from where they should be.
=====
I worked out to work around these problems, I can do 2 things:- When doing a rule addition - always use the Up Arrow, and then drag it to where it needs to go, then save and apply.
- When doing a rule deletion, always drag it to the very bottom, save, delete then apply.
I shouldn't have to do this though. Hopefully Netgate can fix this up.
-
@jrey said in Unsticky separators still an issue:
https://redmine.pfsense.org/issues/14705
https://redmine.pfsense.org/issues/14691For #14705 - I am not using any Ethernet rules, and that bug talks about randomisation. The issue of where the rule gets added (top or second from the top) is repeatable, and the movement of the separators is also repeatable. All the other rules don't get messed up, so there's no randomisation. Interesting, none the less.
For #14691 - YES! That is the same thing I am seeing. In that ticket, Filip Bengtsson posted this:
Example result Rules and separator on target interface before copying: Separator A Rule A1 Rule A2 Separator B Rule B1 Rule B2 After copying, I get: Separator A New rule Rule A1 Separator B Rule A2 Rule B1 Rule B2That is exactly what I am seeing in my "green <down arrow> Add" example I posted above. Where the new rule goes in underneath "Separator A", and subsequent separators are moved up by 1 from where they should be.
So even though #14691 ticket is set to resolved, this issue is far from resolved. Then we have the deletion issue as well. Sigh.
Where do we go from there?
-
@Gcon said in Unsticky separators still an issue:
For #14691 -
I can't recreate this on either 2.7.2 or 23.09.1
or the delete issue.
I tired several adds / drag to new location, and deletes yesterday and the other rules/ headers stayed put. (I've always used the method I described and not noticed the issue.)
The rm was specifically "when copying firewall rules between interfaces" but it appears that's not what you are doing, but the problem as you see it is the same.
You could search and see if there are other redmine items covering this, I really only took a quick look.
You might have to create a redmine,
but also
Maybe @stephenw10 can suggest something for you to try?
-
@jrey Just one thing quickly about trying to replicate the bug. I only get this bug on an Interface group.
My CORP_GRP is a local corporate data network, plus an additional OpenVPN tunnel interface from a remote site network, which requires the same firewalling rules.
If I test the bug on Interface Group "CORP_GRP" I get the issue every time. If I test against one of the group member interfaces, like "GT_CCR_FW" (local network - VLAN interface on a trunk port), then "up arrow" adds, "down arrow" adds, and deletions are all fine.
I think we are getting somewhere here - bug scope seems limited to Interface Groups.
-
Yes, sorry I didn't test it on a group, just on FLOAT, WAN and LAN pages
One would have thought all the pages should behave the same.. Clearly when it is a group interface and I just tested that specifically now - it is acting as you say.
I just tested specifically this on 2.7.2 test box. Seems like a bug.
Still odd though, would have thought all the pages would behave the same, since they all calling the same page. with a parameter
https://10.168.1.1/firewall_rules.php?if=FloatingRuleshttps://10.168.1.1/firewall_rules.php?if=Testhttps://10.168.1.1/firewall_rules.php?if=wanhttps://10.168.1.1/firewall_rules.php?if=lanbut clearly 1 of these things is not like the other 3.
interesting enough that using the add below button, on any of the 3 still puts the rule at the bottom, on the "test" as you describe to the top it goes..
I vaguely recall from an issue that might be similar, in that the "index" of the rule you were attempting to add or delete wasn't the same as what appeared on the screen. Let me see if I can track that down
And as I'm typing this the light went on (flickering candle really)- that issue was regarding Alias lists rm 14015- - this isn't an alias list but maybe somewhere in the code a group is using different method of loading/sorting/displaying the information.
Something for someone to track down.
Create a redmine issue is the only thing I can suggest for you. I'm not seeing an open one specifically.