# DROP\_CT\_INVALID message since upgrading **URL:** \ **Category:** Network\ **Created:** [1 May 2022 09:52 UTC](https://community.ipfire.org/t/drop-ct-invalid-message-since-upgrading/7831 "2022-05-01T09:52:24Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![hellfire](https://community.ipfire.org/user_avatar/community.ipfire.org/hellfire/32/8454_2.png) [@hellfire](https://community.ipfire.org/u/hellfire)\ **Post date:** [1 May 2022 09:52 UTC](https://community.ipfire.org/t/drop-ct-invalid-message-since-upgrading/7831/1 "2022-05-01T09:52:24Z")
Hi! Since upgrading to core 167 today, I’m seeing many DROP\_CTINVALID messages on firewall log: ![grafik](https://community.ipfire.org/uploads/default/original/2X/6/6d192dadeb093cd1368ae69d4c9484c52d598b14.png) Raw format: ```auto 11:47:15 IN=red0 OUT= MAC=00:0d:b9:47:66:e9:74:42:7f:4a:e0:27:08:00 SRC=81.3.27.54 DST=172.17.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=853 DPT=47344 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x4000ca66 11:47:12 IN=red0 OUT= MAC=00:0d:b9:47:66:e9:74:42:7f:4a:e0:27:08:00 SRC=81.3.27.54 DST=172.17.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=853 DPT=47340 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x4000ca66 11:47:12 IN=red0 OUT= MAC=00:0d:b9:47:66:e9:74:42:7f:4a:e0:27:08:00 SRC=81.3.27.54 DST=172.17.0.2 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=853 DPT=47340 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x4000ca66 ``` I do not know the source oft those logs, the host behind those IP-address are e.g. anycast.censurfridns.dk or [recursor01.dns.lightningwirelabs.com](http://recursor01.dns.lightningwirelabs.com) and others. It seems log entries/IP-addresses are related to the DNS server settings in IPFire. Because amongst others, those two are configured as DNS resolvers there. OTH, I’ve location block active for almost all countries except to DE and AT. XD is inactive so far, if this matters. Spamhouse blocking is off, too in FW options. So, how can I get rid of those entries spamming my FW log? Michael ---
**Author:** ![hellfire](https://community.ipfire.org/user_avatar/community.ipfire.org/hellfire/32/8454_2.png) [@hellfire](https://community.ipfire.org/u/hellfire)\ **Post date:** [1 May 2022 11:12 UTC](https://community.ipfire.org/t/drop-ct-invalid-message-since-upgrading/7831/2 "2022-05-01T11:12:09Z")
Replying myself: possibly this option is responsible for those logs, correct me if I’m wrong. ![grafik](https://community.ipfire.org/uploads/default/original/2X/e/e560ac658fd176584a7349a6ebcb22492cbd20ad.png) OTH, why is a reboot of IPFire necessary to get this option to be active? ---
**Author:** ![pmueller](https://community.ipfire.org/user_avatar/community.ipfire.org/pmueller/32/9019_2.png) [@pmueller](https://community.ipfire.org/u/pmueller)\ **Post date:** [1 May 2022 13:08 UTC](https://community.ipfire.org/t/drop-ct-invalid-message-since-upgrading/7831/3 "2022-05-01T13:08:30Z")
Hi, > [@hellfire](#): > > Since upgrading to core 167 today, I’m seeing many DROP\_CTINVALID messages on firewall log: these are nothing to worry about, and IPFire has always dropped these packets - they just were never logged, which is a considerable disadvantage when it comes to troubleshooting and debugging. `DROP_CTINVALID` was introduced in [Core Update 164](https://blog.ipfire.org/post/ipfire-2-27-core-update-164-released) to overcome this, but it did not change anything on the firewall engines’ behaviour. > [@hellfire](#): > > possibly this option is responsible for those logs, correct me if I’m wrong. No, that switch is the correct one. > [@hellfire](#): > > OTH, why is a reboot of IPFire necessary to get this option to be active? Because reloading the firewall engine - which is what happens if firewall rules in the GUI are modified, and the “apply” button is pressed afterwards - does not restart it. Due to technical reasons, log setup is only performed during a restart of the firewall engine. Thanks, and best regards, Peter Müller