# Conntrack troubles **URL:** \ **Category:** Firewall Rules\ **Created:** [15 March 2022 21:14 UTC](https://community.ipfire.org/t/conntrack-troubles/7458 "2022-03-15T21:14:47Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![pygr](https://community.ipfire.org/user_avatar/community.ipfire.org/pygr/32/15379_2.png) [@pygr](https://community.ipfire.org/u/pygr)\ **Post date:** [15 March 2022 21:14 UTC](https://community.ipfire.org/t/conntrack-troubles/7458/1 "2022-03-15T21:14:48Z")
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? ---
**Author:** ![cfusco](https://community.ipfire.org/user_avatar/community.ipfire.org/cfusco/32/9213_2.png) [@cfusco](https://community.ipfire.org/u/cfusco)\ **Post date:** [16 March 2022 06:50 UTC](https://community.ipfire.org/t/conntrack-troubles/7458/2 "2022-03-16T06:50:04Z")
Could it be some weird race issue similar to the one described [here](https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts) for kubernetes? ---
**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:** [16 March 2022 20:14 UTC](https://community.ipfire.org/t/conntrack-troubles/7458/3 "2022-03-16T20:14:21Z")
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](https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0e7bfb1343d28069acfbaacb957cd199f8ead099). 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](https://community.ipfire.org/t/dns-queries-for-arduino-cc-are-dropped-by-ips/6565/39) for an example. If these are all related to `DROP_CTINVALID` indeed, please try to [change the DNS servers](https://wiki.ipfire.org/configuration/network/dns-server) 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