Please see my post in forum: https://community.ipfire.org/t/ipfire-164-dev-build-empty-entries-in-fw-log/7255 Since the IPFire 164 Dev Build update, I can see quite some empty “Chain column” entries in the FW log. https://community.ipfire.org/uploads/default/original/2X/7/78805188768af971c864f3d3a322a21aeae22ec4.png Most of them are outgoing connections from green0 Here a few examples of the target IPs in those empty entries: 142.250.186.42 157.240.27.35 184.51.7.202 Here an example of an incoming connection with an empty entry: https://community.ipfire.org/uploads/default/original/2X/e/ea578a2b96a043cb3177c7a0411d7680404caf9d.png (Incoming IP: 2.19.244.28) My firewall options are the following: https://community.ipfire.org/uploads/default/original/2X/6/63d8f2d77f06793572afc8b257e6b2632c3583a8.png At first I was thinking that the empty entries are a result of the new “hostile network” feature (Nice feature - Many thanks for that!). However I can find “DROP_HOSTILE” entries on incoming ppp0 connections; so logging is working in general - I guess. I also do not have other Firewall rules: https://community.ipfire.org/uploads/default/optimized/2X/a/ae7589b2fd43cf0684c1a178df4ab3cddaba07de_2_690x411.png Question: Where do these empty “Chain column” entries come from? Why are they blocked? (or are they blocked?) Thanks for checking & Cheers!
Hi, this was accidentally introduced in commit 0e7bfb1343d28069acfbaacb957cd199f8ead099. While fixing this should not be a difficult task in technical term, two aspects prevent me from doing that: 1. Right now, LOG_DROP only logs things without any prefix. But since we don't know the direction of a packet conntrack marked as INVALID, we cannot easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it is wise to introduce _another_ log prefix - we have (too ?) many of these already. 2. It would be interesting to see why conntrack decided to flag these packets as INVALID. It is good to get such events _logged_, and I think that might clarify some firewall malfunctions we never figured out before. However, I cannot get rid of the feeling something is off at conntrack. Any opinions, especially to (1)? Thanks, and best regards, Peter Müller
(In reply to Peter Müller from comment #1) > 1. Right now, LOG_DROP only logs things without any prefix. But since we > don't know the direction of a packet conntrack marked as INVALID, we cannot > easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it > is wise to introduce _another_ log prefix - we have (too ?) many of these > already. Why not? If you want to know why something got dropped, you will have to log it.
Certainly, and I think it is good to have these packets logged. But what log prefix should we use? DROP_CONNTRACK?
(In reply to Peter Müller from comment #3) > But what log prefix should we use? DROP_CONNTRACK? Why not DROP_INVALID?
> Why not DROP_INVALID? Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP stuff? In a way, they can all be considered "invalid"...
(In reply to Peter Müller from comment #5) > > Why not DROP_INVALID? > > Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP > stuff? > In a way, they can all be considered "invalid"... Yes they would, but I wouldn't have mixed those things together. To be entirely clear you could go with DROP_CTINVALID
> To be entirely clear you could go with DROP_CTINVALID I like it. Patch sent: https://patchwork.ipfire.org/project/ipfire/patch/c9cdec8e-bec6-1793-2b8e-7a83e6f7d2d8@ipfire.org/
Nice! That’s what I call efficient :-D
Arne asked me to provide a switch to disable logging for such events anyway. It seems as conntrack drops a lot of (at the first glance legitimate) packets, which bloats the logs and makes more serious log events harder to spot. While I don't think logging for this should ever be disabled in production, his argumentation made sense to me. Therefore, I will apply the aforementioned patch to "next", add another one for toggling logging, and will request both patches to be cherry-picked into "master" when I'm done.
Done. Arne, kindly cherry-pick these commits from "next": - https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5ca74566b3404539b46c904aaec0ac7e4033657f - https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8269c8319ccb9e78c8c48a4218396621d5a156e3
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=5c1af49c835921232a0312819025fb08dddae4b3 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=926d840faeafe9528532f42aa12a0922188c1959
https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing
Hi, I just upgraded to Core Update 164 Development Build: master/3b45d956 My Log gets flooded with DROP_CTINVALID May be because of this change? Not a topic to this bug report... I just wanted to report that the upgrade to this version on XEN HVM client was successfull! (As Peter asked for testing on XEN.) have two findings: grep FATAL update-core-upgrade-164.log modprobe: FATAL: Module nf_log_ipv4 not found in directory /lib/modules/5.15.6-ipfire I think thats not Problem but may be resolved somehow. Console output during boot Creating Squid swap directories... [ OK ] Starting Squid Proxy Server... Unable to continue: /usr/sbin/squid is running [ WARN ] BUT Squid is down! I have this Problem for a long time ... maybe same as https://bugzilla.ipfire.org/show_bug.cgi?id=12623 Sorry for writing the update check outcome to this Bug report too ...
https://blog.ipfire.org/post/ipfire-2-27-core-update-164-released