At the switch where the green network of the ipfire is connected, both VLANs were set up as trunk ports. Where the WLAN AP is connected to the switch, only VLAN 6 was set up as a trunk port.
BlueAccess was defused for the static area. DHCP assigns dynamic addresses, otherwise everything with a MAC address is assigned statically.
This works as it should for some time, but at some point, drop forward messages start appearing in the log, even though the rule should enable the data transfer. When I then check the configuration of the rule, the box for âEnable SYN Flood Protection (TCP only)â is checked and I have already corrected this several times.
Why is this set automatically and how can I prevent it? This is slowly becoming a lot of work because it feels like it happens with every rule I create. Anyone have an idea?
I have just checked my two physical systems which have 7 and 5 firewall rules in place respectively and run 24/7 and none of the rules have the Synflood protection enabled.
The only thing I can suggest is to look in the logs and find out at which time the change is made.
Do you have any scripts that get run that change or add firewall, rules at certain times or in certain circumstances?
EDIT:
Also just checked my vm system that has 8 firewall rules defined but does not run 24/7 and none of those firewall rules have the Synflood protection enabled either.
Which Core Update are you having the problem with? All of my systems are currently on Core Update 190 Testing.
A thing that comes to mind is if you are running with CU189 or earlier then if you every selected the Synflood protection then when you deselected the Synflood option there was a bug that the feature was not flushed properly. That has been fixed in CU190 Testing and is mentioned in the Blog Post
Formerly, firewall rules that use the new SYN Flood Protection feature were not flushed on changes. This has now been fixed.
I have turned the synflood protection on, on one of my physical systems firewall rules, saved the changes and then turned it off again. However as that system is running with CU190 Testing it may not show anything.
I will do the same test on a CU189 vm that I have and see what happens, although those systems do not run 24/7.
When you deselect the synflood protection on a rule how long approximately is it before you see it selected again?
After clicking the Update button, are you also restarting the firewall? There should be a notification at the top of the firewall page that says the firewall needs to be restarted for the changes to take affect.
Since I stopped adjusting the rules, things have been quiet. I suspect it has something to do with the error mentioned. I will certainly have activated it in a rule and copied it several times and when saving, the rules will have changed again and again automatically.
I will update to CU190 and hope that it wonât happen again.
Thank you very much!
I have had my CU189 running for a few hours now after I had selected the synflood protection and saved the changes and then changed it back and saved the changes again.
From your comment that it seemed to change back after doing changes, I have been trying to do a range of changes to the firewall rule in question but in no situation have I ended up with the synflood protection checkbox enabled again.
The bug that was fixed was that when the synflood protection checkbox was disabled the actual synflood protection iptable changes were not flushed back out.
I think your best option, as you have indicated, is to run with Core Update 190 (now with Testing phase or when it is full released) and hopefully it does solve the problem that you have been experiencing.
Bad news,
after I updated to CU190 I checked all firewall rules, even the deactivted on (which has all the checkbox active). And today all rules with the exception of one single (made with CU190) have the checkbox again active.
Timing matches (with the block messages in the log) with the wireless config changed message, but it could not be reproduced.
I will continue my research.
So that eliminates the not flushing of the synflood rules.
If you pick up any potential clues as to what might be linked with it occurring let us know.
I can then try and reproduce it.
If we can do that then more people can look at what the root cause for the problem could be.
Ok something strange, as I wrote, all rules were again with an active checkbox, with the exception of the rule I created under CU190.
So I wanted to create each rule again and started to do so, after a few successful entries the error message âThis rule already exists.â appeared. As a note, I did not use the blue pencil this time but always used the ânew ruleâ button,
Shouldnât this happen for all duplicate entries?
Duplicate entries are still possible, even triple entries are possible. With a few exceptions, where the error message still prevents the duplicate entry.
At least I am now waiting to see if all rules are affected again, only the older ones or if it occurs again at all.
Ah, you were using the blue pencil. Everything I did with regard to going in to look at existing rules or do some changes was done via the yellow pencil.
I will do some activities with the blue pencil to see what happens.
I am not totally sure that I understand what you did here. Are you saying that withy the blue pencil you can create 100% duplicate firewall rules but not with the New Rule button?
EDIT:
I just tried using the blue pencil and the new rule button to make a 100% copy of another rule already in place and I got the âThis rule already existsâ in both cases.
The only way I could make a new rule get saved was to make one of the actual entry steps, such as NAT or Source IP different. So just changing the remark different or changing the logging setting would not allow the rule to be accepted.
I think you need to show some exact details of existing rule and the new rule that you created that was the same and was accepted.
With what I have done so far, I always get the âThis rule already existsâ message when the rules are the same irrespective if I have done it via the New Rule or the blue pencil option.
No, I had previously created many of the rules with the blue pen in version CU189. So I copied rules, changed them and saved them.
Now under CU190 I have deliberately only used the ânew ruleâ button and I noticed that most of my rules can be created twice and only a few rules cannot be created twice.
I will have to go back and test on my CU189 system.
I just tried it on my CU190 Testing system and it didnât allow a duplicate rule.
@mumpitz has said that he is still getting the issues on his CU190 system as well.
I took an existing rule, checked the synflood option and saved the rule and applied the changes. Then I copied the rule with the blue pencil and only unchecked the synflood and pressed the Add button and I got the "This rule already existsâ message.
Maybe something gets carried across from rules that were created or in place with CU189 and had the synflood button pressed at some time.
However, then if you disabled all the firewall rules, pressed Apply Changes and then re-enabled all the firewall rules again, I would expect that the synflood rule flushing would then occur.
I have the same behavior.
It doesnât matter whether the rule âEnable SYN Flood Protection (TCP only)â was set or not, because all rules have activated the checkbox even though they were deactivated.
My concern when creating the rules was whether I may have copied the error with the blue pen and therefore all rules are affected.
The additional question I have now is, if I should not create duplicate rules, why is this still possible with the new rule button?
And i didnât get that when i tried with CU190.
I am creating a CU189 clone so i can test it with that approach and also see if the checkbox autonatically gets filled again after some time when it is unchecked.
Rule that can be saved duplicated with new rule button but not with blue pen
Source: Host (IP from blue DHCP server of device blue0p1, static with MAC)
Destination: Default network red
Protocol: Service: Create by me
I hadnât paid attention to it before, I was aware of it, and when I created rules with the blue pen, it was only to modify them and save them.
Edit:
Rule that can be saved as a duplicate if I use the new rule button or blue pen
Source: Host (IP from DHCP server on green0, static via MAC)
Destination: Standard network red
Protocol: Service group created by me
But at the same time:
There are no longer any rules that I can no longer create twice.
I created the rules, that I could not duplicate before, slightly different, then I deleted the old rule (from CU189) and then changed the new created rule (CU190) to what it should be and saved it.
