FIrst a better network map:
Yes, that's considerably different, so you can disregard a fair bit of what I wrote before based on the prior diagram.
The task is reaching in SSH any mikrotic connected to the main wireguard server.
Have you tried a 2-level SSH from the machine in the upper right corner of your new diagram? Using OpenSSH commands, it'd be:
me@local$ ssh myserver.com
me@myserver$ ssh -p 2201 admin@10.66.66.3
The first command presumes that you have the user name and port set up in ~/.ssh/config for myserver.com. I put them on the second command since you gave them above, but you haven't for myserver.com, so it's up to you to manage that detail.
The WG tunnel should have created a route that allows the second command to succeed, and for the reply from first MT box to come back to myserver.com. If so, you're logged into the first MT box via SSH, as you wanted.
here the NAT will move to the mikrotic device with a FORWARDING iptables:
It seems you're trying to "snap" that double SSH link to present the MT box's SSH server on a public IP. I'm not in a good position to help you with that. I simply wouldn't bother with this step. If you had to have it debugged, it's off-topic here.
From my perspective, the address translations on myserver.com cause needless confusion and fail to add a compelling level of functionality over what you have without them. I can see that it'd be nice to have, but it isn't essential, so why fight it until you get the simpler case working?
if the request arrived from the Wireguard tunner SSH doesn't answer.
Is that still true with all the myserver.com NAT stuff out of the way and with the "ssh 10.66.66.3" command above?
If that also fails,
then you have a case where you're on-topic with debugging MikroTik's implementation of WireGuard.
If it succeeds, then as far as I'm concerned, you've got a solution, since the two commands above can be collapsed to a single command:
me@local$ ssh -t myserver.com ssh -p 2201 admin@10.66.66.3
That will bounce you through myserver.com to the SSH server on the MT box at WireGuard IP 10.66.66.3.
As for my suggestion to use "ssh -R" above, that requires a copy of OpenSSH on the LAN side with the MT boxes, which you don't show. If you have such a thing, it allows a direct connection without the "ssh -t" relay trick, but I'm not going to detail it if it doesn't apply to your situation.
One further thought: what you diagram now looks like a better use case for ZeroTier than WireGuard. WG is point-to-point, but what you're showing now is a cloud of devices across the Internet that need to behave as if they were all on a single LAN. That's what ZeroTier does.
I'm not saying you need to get rid of your WG + SSH setup, just that some of your pain is coming from choosing that over ZeroTier.