Bug 13854 - SYN Flood enabled ends up on a different firewall rule than defined
Summary: SYN Flood enabled ends up on a different firewall rule than defined
Status: NEW
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - - Unknown -
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-21 12:25 UTC by Adolf Belka
Modified: 2025-05-21 12:25 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.