IKEv2 with EAP-MSCHAPv2 on Android 13 native client

fakeusername2022 · Fri Nov 25, 2022 11:59 pm

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?!

p.s. used https://help.mikrotik.com/docs/display/ ... outerOSv7) for setup. Kudos to Mikrotik for the good doc.

sindy · Sat Nov 26, 2022 10:03 am

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.

fakeusername2022 · Sun Nov 27, 2022 2:08 am

Hi Sindy,

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].

StrongSwan_Works.log.txt

AndroidNative_DoesNotWork.log.txt

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/o ... origin-ca/) on all platfroms (ios, windows, strongswan and also android native client)

sindy · Sun Nov 27, 2022 9:51 am

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.

fakeusername2022 · Sun Nov 27, 2022 1:09 pm

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

1. On the Android, Windows11 and also iOS, I have added/imported the "Cloudflare Origin CA root certificates" [https://developers.cloudflare.com/ssl/s ... a_root.pem] into the operating system's root cert inventory (not included on bundle unfortunately).
2. 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).

sindy · Sun Nov 27, 2022 1:48 pm

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.

jamesg · Wed Dec 28, 2022 10:02 am

There was a problem in the Android 11 client where some parts of the EAP-MSCHAPv2 exchange aren't padded correctly:

https://wiki.strongswan.org/issues/3673#note-4

I'm guessing it still hasn't been fixed for 13.

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.

fakeusername2022 · Mon Jan 09, 2023 7:33 am

Maybe someone in the andrid community can report the issue. Maybe Mikrotik Dev Team can handle this?!

Nexon · Thu Feb 23, 2023 7:56 pm

Any news on this, the new Android can't connect to L2TP/over IPsec etc?

fakeusername2022 · Thu Feb 23, 2023 8:54 pm

Any news on this, the new Android can't connect to L2TP/over IPsec etc?

Android 13 does not have a built-in native L2tp client anymore. The problem with IKEV2/EAP-MSCHAPv2 is not solved and you are limited to a client like https://play.google.com/store/apps/deta ... l=en&gl=US
The issue seems to be from Android and needs to be fixed by Android dev team...

Nexon · Thu Feb 23, 2023 8:57 pm

Why link to strongSwan VPN Client?
It do not have L2TP...

fakeusername2022 · Mon Feb 27, 2023 6:33 am

Why link to strongSwan VPN Client?
It do not have L2TP...

Because this topic is about "IKEv2 with EAP-MSCHAPv2"

dvopet · Mon Jun 26, 2023 6:40 pm

Hi,

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.

Have anyone any suggestion or help?

Thanks for any help.

Petr

 16:49:58 ipsec ipsec: processing payload: EAP
 16:49:58 ipsec,debug ipsec: => EAP MSK (size 0x0)
 16:49:58 ipsec ipsec: adding payload: EAP
 16:49:58 ipsec,debug ipsec: => (size 0x8)
 16:49:58 ipsec,debug ipsec: 00000008 03010004
 16:49:58 ipsec ipsec: <- ike2 reply, exchange: AUTH:3 212.79.110.122[48102] b3be4a700e05969b:e535dc7106cdca53
 16:49:58 ipsec,debug ipsec: ===== sending 272 bytes from 185.7.20.1[4500] to 212.79.110.122[48102]
 16:49:58 ipsec,debug ipsec: 1 times of 276 bytes message will be sent to 212.79.110.122[48102]
 16:49:58 ipsec,debug ipsec: ===== received 112 bytes from 212.79.110.122[48102] to 185.7.20.1[4500]
 16:49:58 ipsec ipsec: -> ike2 request, exchange: AUTH:4 212.79.110.122[48102] b3be4a700e05969b:e535dc7106cdca53
 16:49:58 ipsec ipsec: payload seen: ENC (84 bytes)
 16:49:58 ipsec ipsec: processing payload: ENC
 16:49:58 ipsec,debug ipsec: => iv (size 0x10)
 16:49:58 ipsec,debug ipsec: 06efed74 c8f4bc67 8246b63d 7db9f869
 16:49:58 ipsec,debug ipsec: decrypted packet
 16:49:58 ipsec ipsec: payload seen: AUTH (40 bytes)
 16:49:58 ipsec ipsec: processing payloads: NOTIFY (none found)
 16:49:58 ipsec ipsec: processing payload: AUTH
 16:49:58 ipsec ipsec: requested auth method: SKEY
 16:49:58 ipsec,debug ipsec: => peer's auth (size 0x20)
 16:49:58 ipsec,debug ipsec: ee9b5758 4c3031ac 28350909 1c663e08 98f3fe7f 98c20f15 a1a29897 88e3b1cd
 16:49:58 ipsec,debug ipsec: => auth nonce (size 0x18)
 16:49:58 ipsec,debug ipsec: 348f26bb 19bdda7d 15a523a0 83e296d0 ff89af50 de030593
 16:49:58 ipsec,debug ipsec: => SK_p (size 0x20)
 16:49:58 ipsec,debug ipsec: 2c70c46b 6e603c50 9b690914 2f53025b a9bcc339 86ec0a99 1c7f0307 f484ebcb
 16:49:58 ipsec,debug ipsec: => idhash (size 0x20)
 16:49:58 ipsec,debug ipsec: a0a4c807 c26b62ae 2612827f 47ff40f8 f101c239 b8823c53 e1ac8d4c f29cb7c5
 16:49:58 ipsec,debug ipsec: => calculated peer's AUTH (size 0x0)
 16:49:58 ipsec,error AUTH not matching
 16:49:58 ipsec,error ipsec: AUTH not matching
 16:49:58 ipsec ipsec: reply notify: AUTHENTICATION_FAILED
 16:49:58 ipsec ipsec: adding notify: AUTHENTICATION_FAILED
 16:49:58 ipsec,debug ipsec: => (size 0x8)
 16:49:58 ipsec,debug ipsec: 00000008 00000018

IKEv2 with EAP-MSCHAPv2 on Android 13 native client

IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client

Re: IKEv2 with EAP-MSCHAPv2 on Android 13 native client