iPhone IKEv2 to RouterOS: Which Identifier Goes Where
Four separate claims decide an iOS IKEv2 tunnel: the dialled address, the expected server identity, the claimed client identity and certificate material.
Reaching the MikroTik gateway settles the transport half of an IKEv2 deployment and nothing else. Four separate claims then decide whether the tunnel forms: the address the phone dials, the server identity it expects, the identity it claims for itself, and the certificate material that backs that claim. Check them in that order, and stop at the first one that disagrees with what the gateway presents. Each one is editable in a different place, which is why a wrong edit usually moves the failure rather than fixing it.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Check the profile fields in the order the exchange uses them
The Remote Address is the destination for the first IKE packet and nothing more. The Remote Identifier is what the phone expects the gateway to prove it is, and it is a name, not a route. Populating both with the same hostname works when the gateway certificate carries that hostname, and fails in a way that looks like a routing problem when it does not. Read the profile as a sequence of claims rather than a list of fields to fill in.
The Local Identifier is the phone's own claim, and it has to be a name the RouterOS identity entry accepts for the client certificate the phone presents. If the two disagree, the gateway rejects the connection after the certificate itself validated, and the log looks like an authorisation problem rather than a naming one.
Check the identifiers against what the gateway presents
A RouterOS peer entry configured for certificate authentication presents its own certificate, and its identity is drawn from that certificate unless you configured otherwise. If the phone's Remote Identifier names the gateway DNS name, the gateway certificate needs that name in a place the phone will accept, typically a subject alternative name. A certificate issued for a different common name will fail validation even though the key and chain are perfect.
Managed Apple profiles can also carry a certificate-name constraint that is evaluated in addition to the identifier fields. Inspect the payload rather than inferring the validation name from what the settings screen displays, because the two are not the same setting.
Check that the client certificate is a key, not just a trust anchor
Importing a CA certificate gives the phone something to validate the gateway against. It does not give the phone a client identity, and certificate authentication needs the client leaf certificate and its private key delivered together through the approved enrollment path. A PKCS#12 built without the private key produces a profile that installs cleanly and authenticates nothing.
The client leaf also needs an identity the RouterOS side expects, which means the subject or subject alternative name has to line up with the corresponding identity configuration. Issuing client and server certificates from one CA makes the chain convenient and does not make the two leaves interchangeable.
Check that the RouterOS policy accepts that name
On the gateway, the peer entry sets the exchange mode and authentication method, and the identity entry ties the accepted remote identity to a certificate and to the policy that follows. In RouterOS v7 that pairing is expressed through the IPsec peer and identity entries, for example an IKEv2 peer with auth-method=digital-signature. Check the actual menu contents on your installed release rather than a walkthrough written for an older one.
This is also where a mismatch is cheapest to fix, because the gateway can tell you both the identity it received and the identity it wanted. Widening the accepted identity to silence the error removes the binding that made the deployment meaningful.
Check which stage failed before you edit anything
Read the attempt on both ends and classify it before changing a proposal. A proposal mismatch, a missing signing key, an untrusted issuer, a wrong peer identifier and a rejected client authorisation all look like a dead tunnel from the phone, and each has a different owner. Changing all five settings at once guarantees you learn nothing from the result.
Record the presented identity, the expected identity, the certificate issuer and serial, and the relevant policy name, while keeping private keys and profile secrets out of that record. Once authentication succeeds, test a private service and its reply, because address assignment, selectors, DNS and access policy still have to work after the IKE exchange finishes.