What exactly are 'invalid' connection states?

I see a lot of these in my firewall log:
Apparenlty these are mostly dropbox and box.com. An ACK,FIN packet is IMHO correct and valid..is the Miktorik implementation too fast in forgetting an active implementation when it sees the first FIN and does not allow the client to see the FIN/ACK?

grep dropINVALID ll.txt |cut -d">" -f2 | cut -d":" -f1 | sort | uniq -c | sort -nr | while read C A; do echo -n "$C "; host $A; done
70 148.167.160.108.in-addr.arpa domain name pointer d-6b.v.dropbox.com.
70 145.167.160.108.in-addr.arpa domain name pointer d-1.v.dropbox.com.
56 61.166.160.108.in-addr.arpa domain name pointer d-5b.sjc.dropbox.com.
56 189.165.160.108.in-addr.arpa domain name pointer d-6a.sjc.dropbox.com.
56 7.222.243.103.in-addr.arpa domain name pointer float.1440.bm-impbus.prod.sin1.adnexus.net.
42 61.222.243.103.in-addr.arpa domain name pointer float.1767.bm-impbus.prod.sin1.adnexus.net.
42 15.222.243.103.in-addr.arpa domain name pointer float.1207.bm-impbus.prod.sin1.adnexus.net.
36 189.166.160.108.in-addr.arpa domain name pointer d-5a.sjc.dropbox.com.
28 Host 182.185.112.74.in-addr.arpa. not found: 3(NXDOMAIN)
27 Host 85.184.112.74.in-addr.arpa. not found: 3(NXDOMAIN)
27 190.174.225.54.in-addr.arpa domain name pointer ec2-54-225-174-190.compute-1.amazonaws.com.
19 241.152.21.23.in-addr.arpa domain name pointer ec2-23-21-152-241.compute-1.amazonaws.com.
14 137.166.160.108.in-addr.arpa domain name pointer client-14b.v.dropbox.com.
14 10.165.160.108.in-addr.arpa domain name pointer client-11a.v.dropbox.com.
14 63.222.243.103.in-addr.arpa domain name pointer float.1178.bm-impbus.prod.sin1.adnexus.net.
14 41.222.243.103.in-addr.arpa domain name pointer float.1766.bm-impbus.prod.sin1.adnexus.net.
9 Host 100.68.125.74.in-addr.arpa. not found: 3(NXDOMAIN)
9 95.200.125.74.in-addr.arpa domain name pointer sa-in-f95.1e100.net.
9 87.200.7.103.in-addr.arpa domain name pointer cache.google.com.
9 123.200.7.103.in-addr.arpa domain name pointer cache.google.com.
9 121.200.7.103.in-addr.arpa domain name pointer cache.google.com.
8 165.191.251.54.in-addr.arpa domain name pointer ec2-54-251-191-165.ap-southeast-1.compute.amazonaws.com.
7 Host 49.18.239.54.in-addr.arpa. not found: 3(NXDOMAIN)
7 50.222.243.103.in-addr.arpa domain name pointer float.1177.bm-impbus.prod.sin1.adnexus.net.
4 65.42.234.77.in-addr.arpa domain name pointer r-065-042-234-077.ff.avast.com.
2 103.242.251.205.in-addr.arpa domain name pointer s3-console-us-standard.console.aws.amazon.com.
1 Host 58.215.21.72.in-addr.arpa. not found: 3(NXDOMAIN)
1 Host 233.195.21.72.in-addr.arpa. not found: 3(NXDOMAIN)
1 Host 87.194.21.72.in-addr.arpa. not found: 3(NXDOMAIN)
1 76.8.17.216.in-addr.arpa is an alias for 76.0/24.8.17.216.in-addr.arpa.
76.0/24.8.17.216.in-addr.arpa domain name pointer central.crashplan.com.
1 253.162.171.207.in-addr.arpa domain name pointer 162-253.amazon.com.
1 116.73.233.205.in-addr.arpa domain name pointer www.tunnelblick.org.
1 Host 181.101.238.191.in-addr.arpa. not found: 3(NXDOMAIN)
1 Host 12.216.60.185.in-addr.arpa. not found: 3(NXDOMAIN)
1 Host 228.100.32.176.in-addr.arpa. not found: 3(NXDOMAIN)
1 217.218.252.125.in-addr.arpa domain name pointer a125-252-218-217.deploy.akamaitechnologies.com.
1 9.166.160.108.in-addr.arpa domain name pointer client-17a.v.dropbox.com.
1 83.165.160.108.in-addr.arpa domain name pointer client-8a.v.dropbox.com.
1 212.165.160.108.in-addr.arpa domain name pointer client-9b.v.dropbox.com.

If it's not new, established or related, it's invalid.
Which means it's not part of a known tcp connection and is not opening a new one.
That may be because of some attack on a flow or because the conntrack table is full.

I am mostly confused by this graphic from 'RouterOs by Example' (and the accompanying text), which
indicates that an 'Invalid' packet inside a connection 'breaks' the connection so that it has to be estabklished again.

(sorry, it seems rotation info gets lost when attaching. Not sure how to fix that)

That seems to not make sense.

a) If the packet can not be attributed to a connection, then how can it break this connection?
b) If it can (same src address/port and dst address/port), what makes it 'invalid'? It cannot be spurious retransmits, or TCP won't work at all over slow links, every one would break tracking and TCP would have to re-establish.

So I am still wondering what makes a packet invalid.
(and why FIN/ACKs seem to be seen as such...)

I had some invalid packets (SYN, ACK) because of the following:

The Mikrotik is 192.168.0.1 and default gateway for 192.168.0.0/25. The router is connected to the network via switch attached to ether3. Inside this network is a server running OpenVPN (IP 192.168.0.x), which hands out addresses in the network 172.24.254.0/24 to its clients. The Mikrotik has a default route to its uplink and a static route for 172.24.254.0/24 to the OpenVPN server.

If a VPN client host (with an IP 172.24.254.y) tries to establish a connection to another host within the 192.168.0.0/25 network (e.g. 192.168.0.z), the SYN packet is directly send to that host, without passing the router. The host at 192.168.0.z now sends its SYN,ACK reply to its default gateway (the router), because the destination network and the origination network are different. The router has not seen the SYN packet, thus has not an entry in the connection table, marks the packet as INVALID and drops it.

Side question: I have added a new firewall-rule
before
which obviously solved the problem, but is there another (more elegant) way to do this?

Best Regards,

Jan

Nothing that complicated happening here.

My MT is 192.168.0.1 and the gatway to the world, with nothing else.

These seem to all be the final throes of a genuine connection that existed but is now dead.
As can be seen some of these 'invalid' ACK/FIN' etc originate locally (presumably at the PC
accessing the web). So for those packets to be invalid

a) the MT already declared the connection invalid on the incoming FIN
b) these are retransmits (unlikely)?

Again, I am alsi unsure about that claim from the book that an 'invalid' packet (connection?)
can 'break' a valid one. That just does not make sense.

if the invalic packet could be attributed to a connection, so that it can break it, why is it invalid then?

if it cannot be attributed to a connection, then how can it 'break' a connection?