“ordinary people” and IPsec do not fit together well regardless the router manufacturer. IPsec is very flexible in many aspects, and flexibility comes with complexity of setup.
It depends on the CPU power of your router and the bandwidth of your uplink. Fasttracking is a way to simplify the processing of the packets in the firewall, to spend less CPU per an average packet. So if /tool profile shows more than, say, 20 % CPU usage while a normal traffic load is experienced, putting that rule back may help a lot. But due to the order of actions in the firewall, fasttracking also prevents IPsec from working properly in particular setups, as it bypasses also matching of the packets by the IPsec policies’ traffic selectors. So to restrict fasttracking to non-IPsec traffic, you need the “action=accept ipsec-policy=in,ipsec” and “action=accept ipsec-policy=out,ipsec” rules before the action=fasttrack-connection connection-state=established,related one in chain=forward of /ip firewall filter. Without them, the non-IPsec traffic will be handled faster, but IPsec traffic will be handled much slower (because only one in many packets of the fasttracked connections is not fasttracked and thus can hit the policies’ traffic selectors and be delivered via the IPsec tunnel).
The only information is here, but it’s not really useful. So if the tunnel does work otherwise, these errors may be caused e.g. by slow establishment of the tunnel.