DROP_CT_INVALID message since upgrading

Networking
1

Hi!

Since upgrading to core 167 today, I’m seeing many DROP_CTINVALID messages on firewall log:

grafik
grafik1131×335 16.1 KB

Raw format:

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 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

2

Replying myself: possibly this option is responsible for those logs, correct me if I’m wrong.

grafik
grafik895×92 8.81 KB

OTH, why is a reboot of IPFire necessary to get this option to be active?

1 Like
3

Hi,

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 to overcome this, but it did not change anything on the firewall engines’ behaviour.

No, that switch is the correct one.

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

3 Likes