TCP package with RST flag with NAT

I have an issue with CCR1072-1G-8S+ running RouterOS 7.4.1 (6.4.* 7.5 as well) and I need some ideas what can be wrong.

CCR have one active WAN interface sfp-sfpplus1-wan with public IP (lets say 4.3.2.1) and one LAN interface sfp-sfpplus5 with address/subnet 10.10.0.1/24. CCR acts as a router for 10.10.0.0/24 network and NAT traffic from this network. When client (lets say 10.10.0.2) from private network downloads large files (larger than ~8MB) using HTTP protocol from server (lets’s say 1.2.3.4) on public network TCP connection is collapsing sometimes. It seems that possibility depend on data download rate: if download speed higher that ~100MBytes/s connection collapses pretty often (each 10th download attempt for 16MB file). Big enough file (1024MB) almost impossible to download.

Debug shows that connection collapse begins from the RouterOS iteslf: in the middle connection it sends TCP package with RST flag to the server. After that server sends RST to client. I think that NAT is the root of problem: same client easily download file of any size from the same server using IPv6 protocol.

NAT config:

[admin@testbench] > /ip/firewall/nat/print
Flags: X - disabled, I - invalid; D - dynamic
 0    chain=srcnat action=masquerade out-interface=sfp-sfpplus1-wan

[admin@testbench] > /ip/firewall/filter/print
Flags: X - disabled, I - invalid; D - dynamic
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough

 1    chain=input action=accept connection-state=established,related,untracked

 2    chain=input action=accept src-address-list=Trusted

 3    chain=input action=accept protocol=icmp

 4    chain=input action=drop

 5    chain=forward action=log connection-state=new

 6    chain=forward action=log tcp-flags=rst protocol=tcp

 7    chain=forward action=accept connection-state=established,related,untracked

 8    chain=forward action=drop connection-state=invalid

 9    chain=forward action=drop in-interface=sfp-sfpplus1-wan

10    chain=forward action=accept in-interface=sfp-sfpplus5

11    chain=forward action=drop

12    chain=output action=log tcp-flags=rst protocol=tcp

What I see in logs during connection collapse:

[admin@testbench] > /log/print follow
...
10:50:09 firewall,info forward: in:sfp-sfpplus5 out:sfp-sfpplus1-wan, connection-state:new src-mac b4:2e:99:58:60:40, proto TCP (SYN), 10.10.0.2:59272->1.2.3.4:80, len 60
10:50:09 firewall,info output: in:(unknown 0) out:sfp-sfpplus1-wan, connection-state:invalid proto TCP (RST), 4.3.2.1:59272->1.2.3.4:80, len 40
10:50:09 firewall,info forward: in:sfp-sfpplus1-wan out:sfp-sfpplus5, connection-state:established,snat src-mac 40:ee:dd:d3:4b:02, proto TCP (RST), 1.2.3.4:80->10.10.0.2:59272, NAT 1.2.3.4:80->(4.3.2.1:59272->10.10.0.2:59272), len 40
...

What could cause this TCP (RST packge sent by RouterOS?

I’ve tried to add following rule:

 /ip/firewall/filter/add chain=output action=drop protocol=tcp tcp-flags=rst

to output chain and issue completely disappeared. Is there any chance that there is a bug in routeros’s NAT and/or connection tracking code?