Conntrack troubles

[pygr (Glenn R)]

In “Firewall Logs” I’m seeing a lot of DROP_CTINVALID entries involving non hostile external servers (e.g. Google, Akamai, my ISP). This behavior manifests itself on one of my Apple desktop computers when I try to send out email using Apple’s “Mail” MUA. Outgoing mail fails to be sent right away, but then for some unknown reason, minutes later, succeeds. It’s not just outgoing connections, it’s incoming ones also.

Some ports involved are 53, 80, 443, 995.

Another example is DNS replies from one of my ISP’s servers. pings to that server succeed with 0% packet loss.

I didn’t used to see DROP_CTINVALID. How should I start to track it down?

[cfusco]

Could it be some weird race issue similar to the one described here for kubernetes?

[pmueller (Peter Müller)]

Hi,

@pygr

I didn’t used to see DROP_CTINVALID.

yes, this is because logging of packets being dropped by conntrack as invalid was only implemented recently. These packets were always dropped, but earlier versions of IPFire did not log them, which made things hard to debug and troubleshoot.

So, has mail submission via the Apple client ever worked? If so, the DROP_CTINVALID could not have made the difference, since it is only about logging; nothing additional gets dropped.

From some other threads and my own system, I observed sometimes FIN-ACKs get dropped by conntrack, most commonly they originate from large CDNs such as Akamai or Cloudflare indeed. I guess they run a non-standard TCP stack, and conntrack mistakenly (or rightfully?) drops such packets.

However, since they are only FIN-ACKs, the TCP connection belonging to them was already closed, and just the final packet does not make it through. Oh well, I don’t think that is something to worry about, although it is certainly ugly to see.

@pygr

Another example is DNS replies from one of my ISP’s servers.

Do you have the IPS enabled? If so, some rules flag (and subsequently drop) certain DNS requests - see this thread for an example.

If these are all related to DROP_CTINVALID indeed, please try to change the DNS servers for once. If possible, use servers supporting DNS over TLS.

@pygr

It’s not just outgoing connections, it’s incoming ones also.

Yes, that would be, for example, true for the FIN-ACKs I mentioned above. In this case, the source IP address belongs to a CDN, while the destination IP is your IPFire’s RED interface. However, these are only incoming packets, not connections, since the connection was actually established by a client located behind IPFire. Otherwise, the packet would have been blocked as NEWNOTSYN.

Thanks, and best regards,
Peter Müller