Okay, Following @bbitsch sequence (and once I realised it was using the New Rule approach) then I have reproduced what he and @mumpitz have experienced. I used my CU189 vm clone for this.
I the ran the update to CU190 Testing and repeated the test and exactly the same thing occurs so the problem is separate from anything to do with the not flushing the rules problem as that was fixed in CU190.
I think this should be raised as a bug.
Good news.
None of the rules have changed. I will now activate the newly created ones and delete the old ones, and hope it stays that way.
But that still doesnât explain why duplicate entries are no longer prevented.
Maybe, the test for duplicates has some problem.
I remember in testing the issue, there was a dependancy on rule number.
but it works okay via the blue pencil so it can be done. Just need to find out the difference between the two approaches.
EDIT:
There are two places in the firewall rules where that error message is shown. Those will be the New rule approach and the use of the blue pencil.
I havenât figured out which is which yet from the code but one of them is missing the check if SYN_FLOOD_PROTECTION has been set and also misses out checking for the rule remark or if logging has been enabled, when compared to the other set.
Okay, this confirms my suspicion.
If this produces two identical rules at two places, the SYN flood protection can be also identical.
That I canât say yet.
What I can say is that there are two places where it is checked if the firewall rule is identical and the two checks are not identical.
However the two checks are within about 5 to 10 lines of code of each other and I am still trying to figure out what the two of them do.
I am trying to compare the path taken by using the blue pencil compared to using the New rule button to see how they get checked differently.
It might be that the original intention was to have those two checks different with one not checking the status of the log checkbox or the rule remark box. So those might be supposed to be different but then when the synflood protection was added it was only addeds to the end of one of the two checks.
I will test out if it is added to the end of the other check code does that stop being able to have two rules with everything identical except for the synflood protection os do we also have to look elsewhere in the code.
EDIT:
When you press the blue pencil then it sets a variable
$fwdfwsettings{'copyfwrule'}='on';
to on and then it goes to the newrule subroutine exactly the same as when you press the New rule button, so the difference has to be related to where the code does something different with that variable value.
The problem is with which rule the synflood protection gets applied to when you save it.
If you edit the last rule to disable the synflood protection then as far as I can tell at this time, it stops making the last rule have the synflood enabled.
So once you have the synflood enabled in the last rule then deleting it just moves the synflood protection up to the new last rule.
Would be good @bbitsch if you can test the sequence I described and see if you get the same problem.
EDIT:
It gets even more interesting if you create another new rule, also with synflood protection enabled and insert at rule 3 again in the sequence above.
That new rule 3 will again not have synflood enabled but now the previous rule that was added that should have had the synflood enabled but didnât now does.
Also every rule from 4 to the end now has the synflood protection enabled.
If I have understood correctly, a check routine runs during creation, which produces an error that changes an existing rule.
I donât know if it wouldnât be easier to remove this routine and give a hint that double entries affect this or that.
Are duplicate entries really harmful? Normally you wouldnât write a rule twice or is it absolutely necessary to prevent this?
If you look at the new options for creating rules, this check routine has a few more points to check now.
What I also wanted to mention when I created the new rules with CU190 with new rule button, I always wrote the position number of the rule which to be duplicated, deactivated it and selected Apply rules after each rule.
Do these rules stay clean now or can the error still occur?
The problem is not in that check routine. It is somewhere else.
There is a separate question that the two check routines donât look for the same things to define if it is duplicate and hence a different result via the New rule or the blue pencil routes for creating a new rule.
Even if that check routine was not there or both made the same the problem of the synflood enabled being applied to the wrong rule number would still occurr.
I have found another way to cause strange behavior.
There is a restriction on the number of ports for service groups.
So if you have reached the maximum number of a group and change some used services from a port to a port range, it is still possible to save the rule.
The faulty behavior in my case is blocked connections even though the rule is enabled.