Sounds logical but don’t mix up correlation with implication. It could also be that the PPPoE itself is not the problem here but the fact that those of your Mikrotiks which have a PPPoE client on themselves also have a public IP address on themselves (on the PPPoE interface of course), so the remote end may be so “surprised” by a client which does not come from behind a NAT that is doesn’t know how to treat it properly. I.e. if the 'Tik would have a public IP on other than PPPoE interface, the VPN server might have the same issue.
So far I only have encountered a double-reverse problem, where a Windows 10 native client was unable to cope with the server being behind a NAT.
For this case, where the IPsec connection is initiated from the Mikrotik side, it is not exactly trivial to make the IPsec stack bind to some private address and then get NATed to the public one, which is essential to make the server think that the client connects from behind a NAT. Let me think a while, I’ll come back once I conclude whether it is possible to find an easier solution than the brain-frying one described here.
If you have a possibility to check that using a 'Tik which receives a public IP from the ISP in a different way than via PPPoE, let me know ASAP to avoid the process above 