I’m afraid that the issue is not a mismatch of the authentication and encryption alghoritms configured but your unusual test setup.
You’ve connected your iPhone to Mikrotik’s LAN and configured the L2TP/IPsec to contact the public IP of the Mikrotik. This means that the Mikrotik accepts the UDP connection and assumes the public address to be used for the IPsec security association, but it sends the response packets with its LAN address as source, so the client detects a NAT based on the difference between the actual source address and the peer address inside them:
08:46:18 ipsec,debug updating policy address because of NAT in transport mode
However, your peer configuration lacks the ****
nat-traversal
setting and the default value is
no
, so the process fails at this stage.
So first configure both your test clients to connect to ****
192.168.200.1
instead of
xxx.xxx.xxx.xxx
and try again. If it doesn’t work anyway, post a log again.
If it works, you can configure the clients back to ****
xxx.xxx.xxx.xxx
and add the
nat-traversal=yes
to
/ip ipsec peer
configuration, you’ll most likely need it anyway for practical deployment. In theory, the iPhone client should work this way but the Windows one will fail (with an error message which doesn’t give you the smallest clue what is the reason). This is because NAT-T supports NAT on either end of the connection (or even both) in general, but the Micorsoft implementation of the client has a mental problem with NAT at peer side. There are workarounds for this but you should not need them as normally the clients will be connecting to your Mikrotik from outside.
Also be aware that if you plan to connect more than a single L2TP/IPsec client from behind the same remote public address, you’ll need a workaround described here.