@Mimiko
My post that explains why wireguards has this idiosyncrasy in its design (right here on this thread):
http://forum.mikrotik.com/t/routeros-blatantly-ignores-pref-src-can-this-really-be-a-bug/180360/15
And the one that explains the source address assignment in detail: (You should probably scroll though the entire thread)
http://forum.mikrotik.com/t/mangle-policy-based-routing/181586/6
@anav
I don’t know if the question in the +++ / +++ was addressed to me, but: The workaround presented both by sindy and me rely on the same way of using dst-nat to achieve connection tracking. Mine is of course better (obviously 
) in that sindy’s fails if:
- the wan1 interface goes down (the address we dst-nat to is lost)
- the default route’s pref src changes (for example because of wan1 going down)
My not-exactly-“s” works around these by: (1) dst-natting to a local address that can’t go down and (2) using the input src-nat ensuring that wg underlay output packets are addressed to the (in some ways virtual) 192.168.222.2 address, the route to which (and its pref-src) cannot change.
Of course sindy’s method preserves the source address, which is nicer. On the other hand in VRF-heavy scenarios input src-nat does wonders for overloaded source IPs (in fact conntrack cannot be correctly maintained without it).