DROP_NEWNOTSYN fills up my logs and from what i read in wiki and on web, it is pretty much a bad implementation in iptables and pretty much irrelevant.
If the web-wisdom is correct, then why is it still on for logging by default installing ipfire. ?
Or did it somehow become useful again recently ?
It really messes up logs, and I see no purpose for it according to what I read on the web.
You can disable the logging. It is NOT a bad implementation in iptables and it is NOT necessarily irrelevant as it can be a way to attack the firewall, therefore a default “on” settings is justified, given also the possibility to set it off if you want. All you need to know is in the wiki page that I linked.
That was not the question. i obviously know I can disable it, which is clear if you read my initial post. I said why “default on” if it is known to be benign and a bad implementation.
My question was : Why is it on by default after installation, knowing that it is not of much use.
Re your answer that it can be used to attack the firewall:
Since you have information you rely on to make this claim;
Please show the examples how this have been used succesfully to breach ipfire and what methods are used.
I have to ask as there is a wall of evidence opposite to what you claim, online.
Disclosing this information would help to get to the truth.
@cfusco , @zimbodel ,
you both haven’t disclosed your information!
‘The wall of evidence online’ isn’t a proof. There are many statements in the web about many things.
If the ‘DROP_NEWNOTSYN’ is in fact a known ‘bad implementation in iptables’, this issue will be corrected sometimes. Logging in IPFire can be used as a measure of the state of this problem. This implies you know the false-positives.
This was seemingly implemented to allow several redundant firewalls, for failure fallover.
For a user with only one firewall, this entire boondoggle might become irrelevant.
It should just be blocked by default.
For single firewalls without fallover, Just reject a new state without a syn bit set.
Why should I have to know that a packet with a “New” state without a “Syn” bit set is attempted…if the Syn bit issue has been set hard by a rule in ipfire that is not really relevant to my use of a firewall as a non-failover firewall user?
It’s a message that IPFire has recieved a tcp packet with no matching connection and it has no SYN flag to open a new connection. This packet cannot correct forwarded so it should dropped to save bandwich.
My former post wasn’t mainly about the meaning of DROP_NEWNOTSYN, but about the discussion whether the implementation is bad. @zimbodel stated this according to the ‘web-wisdom’. 
Thanks arne,
I know that, as is clear from my responses.
Since this is by default blocked, else without syn set, it may pass through the firewall undetected with a new state packet. that part I understand, but there are literally 10 folds of firewall rules with the same level of severity that is not in the log option. So my question was, why then pick to log this one. All I want is the reason to add this particular one above others ?
That s all
I just switch the newnotsyn logging off, unless I want to look at the DMZ.
The only use I found for it was to monitor an external firewalled DMZ (not ipfire native).
I found it alarming what commercial firewalls let through and that is what made me switch to ipfire in the first place.
fair enough, this is mine. The link is coming from a previous thread on the subject. According to what I read there, I disagree with @zimbodel and I think this has merit to be set on by default (speaking about the logging), even just considering the benefit of seeing the log and doing some research to understand the issue and learning something more about configuring firewalls. I also disagree with the statement that this issue is originated by (quoting OP) a bad implementation in iptables. The post I linked criticized a bad documentation and that has definitely more merit than bad implementation, from my point of view, of course.
EDIT: I forgot to add that the argument @zimbodel presents concerning logging by default is well informed and it is sensible, I just happen to disagree with the conclusion, but I definitely agree with the premise.