My case is CCR1036 to CCR1036. 0ms latency (10ft ethernet between ether10 on each). I had clamp-tcp-mss already set on the tunnel, I was using iperf3 with MTU flag set to 1300, all tests are affected (smb, iperf, http, etc).
I tried changing the MTU to 2000 and L2MTU to 3000 in my lab setup between physical interfaces (ether10) and turned off clamp-tcp-mss on GRE tunnel since all other interfaces involved are now below the GRE tunnel MTU (1926). I still see 25% more packet loss with UDP test and my SMB still drops 10x from 750Mbps (with encryption turned off) to 75Mbps (with it on).
No core when testing exceeds 20% load. Profile shows 90+% idle and no process using more than 3%.
At least in my case, I am pretty confident I am not hitting the limit of the CPU or the hardware encryption.
While mrz says it could be the driver (http://forum.mikrotik.com/t/high-speed-vpn-100mbps/75714/1 http://forum.mikrotik.com/t/gre-over-ipsec-ccr-very-slow/76641/1 http://forum.mikrotik.com/t/solved-ccr-ipsec-rekey-problem/91042/1), Maris via support email tells me “Driver is already improved. You need to avoid fragmentation. If it is UDP traffic you need to send smaller packets like 1450 or less. If it is TCP you need to reduce MSS, it could be done with change-mss mangle rules.”