Hi
I have a fully functional IKEv2 with EAP-MSCHAPv2 IPSEC config which works SUPER PRETTY FINE with Windows 11 and StrongSwan Android clients, BUT it does not work with native client of android 13! In my ROS 7.6 logs I get “got fatal error: AUTHENTICATION_FAILED” when trying from the native ILEv2 client of android 13.
Has anyone had any simillar issues? Is Mikrotik aware of this? Are there any workarounds?!
I would have to see the debug log from the IKEv2 negotiation, but a new way of indicating the authentication method has been introduced by RFC7427, and I hazily remember the embedded Android IKEv2 client uses it. Unless I have missed something in the release notes of RouterOS, it has not been implemented yet, so if you see something like “unknown authentication method 14” in the log, that’s it.
I have attached two IPSEC logs. One from StrongSwan client on android and the other from Android’d native client (version 13) [both on the same phone]. AndroidNative_DoesNotWork.log.txt (74.9 KB) StrongSwan_Works.log.txt (110 KB)
P.S. The very same server config also works pretty fine with the latest IOS version. I am using the free SSL from CloudFlare and had to install/import "Cloudflare Origin ECC PEM (step 4 of this page https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/) on all platfroms (ios, windows, strongswan and also android native client)
So my assumption was a complete miss, it seems that the Android native client doesn’t like something about the contents of your certificate.
The log suggests that you have set the CA certificate itself, rather than the certificate generated for the Mikrotik and signed by that CA, as the certificate item on the /ip ipsec identity row for that client: nov/27 03:23:46 ipsec cert: O=CloudFlare, Inc., OU=CloudFlare Origin CA, CN=CloudFlare Origin Certificate
Could that be the case? If not, what is the contents of the common-name, subject-alt-name, and key-usage fields of the Mikrotik’s own certificate? /certificate print detail will show them, of course obfuscate the actual names and addresses, only the formal part is interesting.
I have a “MyDomianName.co” pem file and the private key issued by CloudFlare. I have used this as the Radius and also IKEv2 identity.
Here is the export:
/certificate/print detail where name="MyDomianName.co"
Flags: K - private-key; L - crl; C - smart-card-key; A - authority; I - issued, R - revoked; E - expired; T - trusted
0 KL T name="MyDomianName.co"
issuer=C=US,S=California,L=San Francisco,O=CloudFlare,Inc.,OU=CloudFlare Origin SSL Certificate Authority
digest-algorithm=sha256 key-type=rsa organization="CloudFlare, Inc." unit="CloudFlare Origin CA"
common-name="CloudFlare Origin Certificate" key-size=2048
subject-alt-name=DNS:*.MyDomianName.co,DNS:SubDomain1.MyDomianName.co,DNS:MyDomianName.co days-valid=5475
trusted=yes key-usage=digital-signature,key-encipherment,tls-server,tls-client
serial-number="42f3f9f1e00df08dfbfe1c684b60c01fd873d1"
fingerprint="9221c99f4c9b0ce5b1911ccd1b58bf03189a2a57c984cd3248d63f6411027237"
akid=24e853575d7c344087a9eb94dbbae11678fc29a4 skid=12ad33b22b122d9000a9a46b787f85071d44820a
invalid-before=nov/26/2022 01:02:00 invalid-after=nov/22/2037 01:02:00 expires-after=781w6d11h5m23s
I have also imported the “Cloudflare Origin CA root certificates” on the Mikrotik (which I think is not needed):
/certificate/print detail where name="origin_ca_rsa_root.pem_0"
Flags: K - private-key; L - crl; C - smart-card-key; A - authority; I - issued, R - revoked; E - expired; T - trusted
1 T name="origin_ca_rsa_root.pem_0"
issuer=C=US,S=California,L=San Francisco,O=CloudFlare,Inc.,OU=CloudFlare Origin SSL Certificate Authority
digest-algorithm=sha256 key-type=rsa country="US" state="California" locality="San Francisco"
organization="CloudFlare, Inc." unit="CloudFlare Origin SSL Certificate Authority" key-size=2048 subject-alt-name=""
days-valid=3644 trusted=yes key-usage=key-cert-sign,crl-sign serial-number="eace49d4c67c67"
fingerprint="d3c7e85c91707fc0a12abc5d88266747aa4fa8e7b162f633ffb3c9d989947620"
akid=24e853575d7c344087a9eb94dbbae11678fc29a4 skid=24e853575d7c344087a9eb94dbbae11678fc29a4
invalid-before=aug/24/2019 00:38:00 invalid-after=aug/15/2029 20:30:00 expires-after=350w3d6h31m34s
Also checked and confirmed the cert validaty by accessing Router’s Webfig over httpS (Of course because of adding the “Cloudflare Origin CA root certificates” to the OS root CA inventory).
If the issue is related to the certificate contents, I can only imagine that the Android native client looks at the common-name item (which is not very likely) and finds it unrelated to the fqdn it connects to, or that it expects one of the ipsec-end-system, ipsec-tunnel, or ipsec-user values in the key-usage field (it’s actually a logical concatenation of two fields but that’s irrelevant here).
But it may also dislike the EAP challenge which is being sent in the same IKEv2 message like the certificate.
I’m afraid this is the maximum that can be retrieved from the log at Mikrotik side. You can create your own CA, use it to sign a certificate with all the three key-usage values above and see whether it changes something (provided that you can install the CA certificate as a trusted root CA to the Android); if that helps, it makes sense to find out which particular value out of those three is required by creating another certificate with one of them missing, and then create a new certificate signed by Cloudflare with that value present. If it doesn’t, you’ll need to ask for support on the Android side - I believe the log can be obtained at the phone side as well if you use the right tools.
So basically if it’s like the StrongSwan developer describes it, Google has been shipping completely broken IKEv2 EAP-MSCHAPv2 client for >2 years now.
If you search online, you can’t exactly find anyone describing the native client working with any server for this method.
Don’t know if a workaround could be implemented server side or not.
I have working EAP-MSCHAPv2 for Windows 10/11, MacOS, iOS, but Android does not work.
Authentication ends with “AUTH not matching” in Mikrotik log on strongSwan client.
Android native client does not work as you said before.
Tried import certiticate’s CA cert. Both Mikrotik generated self-signed and Let’s Encrypt.