FastTrack makes TCP supet-slow for some devices, but not UDP. Is there a reason for that?
One of the possible causes is that you have mangle mark-routing rules that put packets of a connection in a routing table other than “main”, but did not try to exclude those connection from the fasttrack rule.
Why guess??.. ask the op for his config and then you can give accurate advice…
You must really enjoy whackamole 
It is written everywhere in the Mikrotik docs, that fasttrack only works on main routing table. But then why the default firewall filter rule look like this:
/ip firewall filter add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
Could this resolved by simply adding “routing-mark=main”?
/ip firewall filter add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes routing-mark=main
Anyone ever tried? I tried, but it does not work as I expected. I guess routing marks must be applied by a mangle rule to make this work.
I have no MANGLE rules (except for default/factory ones, if such exist), no VPN, one WAN, and one routing table. I have very granular per-IP, per-port, per-protocol, per-interface, per-VLAN, per-MAC rules for each client for outbound forwarding. Each of those rules has a corresponding inbound forwarding rule that mostly mirrors related outbound rule, but with FastTrack enabled, reduced granularity, and only related + established connections allowed. New and untracked connections are not allowed for inbound forwarding. With described setup, UDP works great, but TCP bandwidth is at some 5KB/sec, not usable. Only some clients are affected.
What is interesting is that default/factory configuration also uses FastTrack, but TCP works fine, and yet, my granular configuration I describe earlier gets excellent TCP bandwidth as soon as I replace FastTrack with simple ACCEPT.
I researched and found some threads with similar complaints, but no explanation as to why FastTrack caused this.
Sorry, not saying your incorrect but evidence and facts speak for themselves, human interpretation is often flawed.
Reason is most likely an error in your configuration.
It’s compatible when connections are put into routing tables other than “main” too, but that must be done with routing rules, not with mangle rules.
I’ve redone it multiple times from scratch. Its not complicated…
Sorry, be we dont work on a belief system…, if its not peer reviewed, its a hypothesis at best.
A guess…
You do need to keep the accept rule after the fasttrack rule.
Based on the posted configuration, I would say this is a configuration issue.
Yes, but why? The default set of rules suggests that MikroTik tries to use hardware offload with partial packet inspection, but if something is off and it cannot use hardware offload, then full packet inspection takes place without hardware offload. That works for me. Keeping that accept rule resolves my issue, but why? Why only affect TCP? UPD can use hardware offload exclusively without issues, but not TCP.
Only on some high-end CCR/CRS models is fasttrack hardware offloaded. On most MikroTik’s devices, including cheaper CRS and anything <= CCR2004, it’s a software mechanism.
As for why the accept rule is needed: It’s explained in the docs: https://help.mikrotik.com/docs/spaces/ROS/pages/328227/Packet+Flow+in+RouterOS#PacketFlowinRouterOS-FastTrack
to maintain connection tracking entries some random packets will still be sent to a slow path. This must be taken into consideration when designing firewalls with enabled “fasttrack”.
and
Notice that the first rule marks established/related connections as fast-tracked, the second rule is still required to accept packets belonging to those connections. The reason for this is that, as was mentioned earlier, some random packets from fast-tracked connections are still sent the slow pathway and only UDP and TCP are fast-tracked, but we still want to accept packets for other protocols.
Connection tracking for TCP has many more data to maintain, like sequence, MSS, window size, last ACK. Most importantly, if the conntrack information is lost (because conntrack discards the entry when it sees no action for a long time), the connection must be reestablished with a full 3-way handshake. Just seeing some random packet is not enough.
For UDP only the source/dest addr/port and NAT mapping need to be remembered. And these data are remembered by fasttrack already. Assuming that you forgot to add the accept rule, which means conntrack doesn’t see the packets and remove the entry after “UDP timeout”, that is not a problem because any of the next UDP packets of the connection that arrive in the right direction is enough to recreate the connection tracking entry. At most some packets coming from the wrong direction maybe lost (filtered by the incoming rules), but most applications using UDP already assumed it’s unreliable and have mechanisms to retry / resend the packets, as part of the normal handling of packet losses. There is no need for a new 3-way handshake like with TCP. Which means the loss of the conntrack entry can be quickly recovered.