Looking at the packets they are mostly (all?) some host on a private address trying to close a port 443 connection to something with a public address. These are probably from web connections that were never closed properly and have now timed out from the connection table, so the router doesnt know their state and are “invalid”.
This is a common question for the linux nf_conntrack machinery.
There is much discussion around how a TCP connection starts (the three-way handshake), but much less is said about how it ends. It ends with a FIN (can also be FIN ACK) packet from the side closing the connection, and a FIN, ACK is sent in reply by the other end as an acknowledgement.
The first of these (the FIN) is forwarded by your router, however seeing that it is a FIN packet, the conntrack entry is immediately evicted. So upon seeing the FIN,ACK reply, this is regarded as a new connection on the part of the conntrack machinery, and it recognizes (correctly) that a TCP connection may never be initiated or maintained (in case “loose TCP tracking” is enabled) by a packet with FIN set, and immediately regards it as invalid. To reiterate: a tcp packet with FIN set never creates a conntrack entry.
This is normal behavior that sometimes confuses people. There are other conntrack implementations (on other operating systems) that keep the entry around with some short timeout for this purpose. nf_conntrack famously does not. (One rationale being that the linux tcp stack also forgets about the entire connection once it sends a FIN, and just silently ignores any reply.)
I see that you want to understand what the firewall does in meticulous detail - and as you can see I am willing to help. But this question is answered hundreds of times on the web already. So don’t be afraid to use search
Most TCP stacks emit multiple FINs or RSTs … just to make sure that the connection peer gets the message that connection is being terminated even if one of these packets get dropped. And that is perfectly valid activity.
When it comes to MT’s connection tracking machinery (and I’ve been told it’s actually linux kernel nftables thingy), it notices the first occurence of such packet and marks connection as closed. The problem is that it also imediately removes that connection from connection tracking table (I’m not sure if that’s nftables thing as well). When second copy of same packet arrives at firewall, connection tracking machinery can’t find matching connection and since it’s not new donnection (due to combination of TCP flags), it’s marked as invalid. And dropped. And logged because @OP asked it to.
So basically it’s mostly useless to log dropped invalid packets because there are many of them (and most are not really invalid, they are just mis-labeled as such).
In principle such packets could be used to break other people’s TCP connections. So I wouldn’t add a rule which explicitly allows invalid packets.
My point is that seeing such drops is usually “nothing to be worried about” and one should simply stop logging it. It falls into same category as port scanners … there will always be port scanners, rule which drops packets from WAN does its job, no need to get upset about logs … just disable logging.
I don’t know why you would want to log these packets at all. For educational/testing, ok, sure. But this rule has been used like this in basically every Linux machine, cloud server, etc. forever, and no one got hurt.
You could log not-FIN invalid, as BartoszP suggested, but again: IP is not designed as a reliable transport, so protocols get into all sorts of incorrect/confused states regularly.
If you log these, you are only generating GBs of useless logs for yourself, just like the people who insist on logging every port scanning attempt, etc.
