DROP_CTINVALID for response packets

Hi there,
currently I ran into a strange problem I haven’t seen before and ATM I have no clue what the reason could be:

I created a DNAT rule for packets coming from a specific alias IP on port 443 to be forwarded to an internal IP. This works as expected.

Now suddenly the response packets from that host accepting the SYN request fail, because they are somehow detected as CTINVALID:

May 10 08:17:01 ipfire-xxxx kernel: DROP_CTINVALID IN=orange0 OUT=red0 MAC=00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=192.168.100.xxx DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=443 DPT=10282 WINDOW=64240 RES=0x00 ACK SYN URGP=0 MARK=0x80000000

This makes no sense from my understanding. What could be the reason? Could this feature be configured somewhere?


I think I found the reason. It must be related to the issue described here: Renew error: Timeout during connect (using IPFire) - #6 by MikeMcQ - Help - Let's Encrypt Community Support

Strange is, after rebooting the affected host, it works again.

What I don’t understand is why it suddenly occured even though I did not change anything meanwhile?
Any thought what could have triggered this?

Based on the provided log message, it is likely the issue was caused by an out-of-sequence SYN/ACK packet that did not have a corresponding entry in the conntrack (connection tracking) table of the IPFire firewall. The log message shows “DROP_CTINVALID,” indicating that the firewall dropped a packet deemed as invalid in the context of the existing connection tracking entries.

An out-of-sequence SYN/ACK packet might be the result of a few network latency or packet reordering or failure of some component of the network stack of the host machine: possibly some network conditions could have caused packets to be delayed or arrive out of order. In such situations, the firewall’s conntrack table may not have the expected entry for the incoming SYN/ACK packet, leading to the packet being dropped.

I do not think what happened has anything to do with the thread you linked, which I opened in the LE forum. That thread is about an hypothesis that I am not sure at all is correct, concerning the renewal of LE certificates when reverse path filtering is set to strict in the kernel. That is a setting that prevents forwarding of packets to interfaces that have no reason to receive that traffic.

At the time I supposed this was the reason LE servers would not receive an answer from my web server in the orange network, because when I dropped the strict flag it worked. However since then I researched the details of what that setting really means, and I could not find a reason to explain how this could happen. It could have been just a coincidence. I am waiting to test this next time my certificate is due for renewal.