Interesting results. Here’s what I found:
17:25:23, DROP_CTINVALID, green0, TCP, x.x.x.249->23.216.149.141, 56997->443(HTTPS)
17:25:23, DROP_CTINVALID, green0, TCP, x.x.x.249->104.70.1.233, 53671->443(HTTPS)
17:25:25, DROP_CTINVALID, green0, TCP, x.x.x.249->44.241.245.42, 56144->10901
17:25:26, DROP_CTINVALID, green0, TCP, x.x.x.249->23.216.149.78, 56706->443(HTTPS)
17:25:26, DROP_CTINVALID, green0, TCP, x.x.x.249->23.216.149.78, 60136->443(HTTPS)
Where x.x.x.249 is the private IP address of the PS5 on the internal (green) network. A google search led me to this IPFire forum post: 2.27 cu 164 Testing release - Hostile & CTInvalid logging - #6 by pmueller … @pmueller, I don’t mean to impose and without asking you to solve my problem, do you think this fits the symptoms of the same problem? Most of the destination IPs are Akamai, and in your comment you mention:
a decent amount of them are FIN-ACKs sent very late by the peer (especially observed in conjunction with Cloudflare and Akamai - perhaps they run their own customised network stack?).
I don’t want to bang my head against the wall if this is a known issue; that said in the meantime I’ll see if there are any rules I can (and want to) change to hopefully fix this issue. Thanks for the help so far! I really appreciate it and it is getting me much more familiar with IPFire’s interface (which I pretty much love so far).