Bug 13854

Summary:	SYN Flood enabled ends up on a different firewall rule than defined
Product:	IPFire	Reporter:	Adolf Belka <adolf.belka>
Component:	---	Assignee:	Assigned to nobody - feel free to grab it and work on it <nobody>
Status:	NEW ---	QA Contact:
Severity:	- Unknown -
Priority:	- Unknown -
Version:	2
Hardware:	unspecified
OS:	Unspecified

Description Adolf Belka 2025-05-21 12:25:34 UTC

Back in December 2024 this issue was identified and it was suggested a bug should be raised. It wasn't and the issue came back again in Feb 2025 but again no bug was raised.

It has now come back again in May 2025, so I have raised a bug on this.

The following sequence of things is what I found to create the type of problem being described in the forum.

You have more than a few firewall rules, say 8, and all of them do not have the synflood protection enabled.

Then you create a new firewall rule with the synflood protection enabled, which you insert at rule 3, and then Apply the Changes.

Now go and look at the rule at position 3 that you just created, it will not have the synflood protection enabled.

Go down to the last rule, which will be 9 now, and you will find it now has the symflood protection enabled.

Now delete that rule 9 and you will find that rule 8 now has the symflood protection enabled on 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 that last rule just moves the synflood protection up to the new last rule.

If an existing rule at say number 3 out of 8 is edited to enable synflood protection then it is enabled on the correct rule. So the bug only occurs when synflood protection is enabled on a rule that is being newly created and inserted within the existing set of firewall rules. Then the synflood protection is enabled on the last rule in the list rather than on the rule that it was set on.

If a new rule is created with synflood protection enabled but the rule number left blank so the rule is added at the end of the existing set of rules then that rule has the synflood protection and if that rule is deleted then the new last rule in the list does not have the synflood protection enabled.

So it is a very specific sequence that has to be done to get this problem to occur.

All the above has been confirmed by me on my vm testbed system just now before submitting this bug, so nothing has changed with it since it was first highlighted in December 2024.