Keen to bump this one.
I am experiencing the same problem using a similar setup and client type. When using auth-method=eap-radius, the identity is not found for for the peer DER DN - and as far as I can tell no requests are sent to the RADIUS server. Curiously when I use auth-method=digital-signature and specify individual clients and their matching certificates, my connections are established. But I think I can point to the setting that makes it work.
Sindy recently solved this one:
http://forum.mikrotik.com/t/issue-with-ios-strongswan-roadwarrior-clients-ikev2-eap-radius/156282/1
But the key difference is the clients authenticated using username and password, hence their identity was matched by remote ID and passed to RADIUS.
And Sindy again here back in 2020:
http://forum.mikrotik.com/t/ipsec-ikev2-indentities-ids-not-match-but-connected/138064/1
The answer is the > match-by=certificate > setting in the > /ip ipsec identity rows> . With this setting, the 'Tik acting as IPsec responder uses the received certificate to match through the rows of the identity table and ignores the ID_I field from the IPsec initiator.
But in this case the Mikrotik handled the EAP side locally - no RADIUS server was used.
The trouble is, when using auth-method=eap-radius, we cannot specify match-by=certificate. Makes sense, we don’t even point to a client certificate to match in the identity since we expect it to be passed to and handled by the RADIUS server. But IPSec still tries to match to something!!! I am seriously wondering if we are looking at a bug. I would love to be proven wrong.
In the meantime if you’re willing to export all of your certificates over to the Mikrotik and build individual identities, this post gives config that works without the use of a RADIUS server. Just sub in your own certs.
http://forum.mikrotik.com/t/ipsec-ike2-with-certificates-vpn-server-guide-for-remote-access/149434/1