Found a workaround Most people wouldn't even encounter this issue as everyone nowadays can buy a cheap domain name and use it in Common Name and SubjectAlternativeName of the server certificate. iOS client requires the DNS name of the TLS server to be in SANs. Remote ID setting of my client was set to server's IP address (192.168.50.60). iOS sent it as IP of course, server decided it was perfectly okay as it's leftid was set to 192.168.50.60 and proceeded with the authentication. At this moment iOS client checked whether DNS name of the server was amongst the SANs of the server certificate. And it was not. The server didn't even have a DNS name, it had a workaround with an IP address being interpreted as DNS name. I think it tried to match Remote ID to DNS SAN DNS:192.168.50.60 and got confused. I'm not sure why it doesn't do that when not using certificate client authentication. I added a fake DNS name testvpn.xyz to the server cert's SANs, set it as leftid in ipsec.conf and set it as Remote ID of the client. And it worked, iOS client establishes connection. It would be much easier to buy a domain name from the beginning. Oh well. Server certificate: ... X509v3 Subject Alternative Name: IP Address:192.168.50.60, DNS:192.168.50.60, DNS:testvpn.xyz X509v3 Extended Key Usage: TLS Web Server Authentication, 1.3.6.1.5.5.8.2.2 ... ipsec.conf: conn ikev2-vpn ... left=%any leftid=testvpn.xyz leftcert=server-cert.pem leftsendcert=always ...