Solved: iOS 13 & macOS Catalina IKEv2 VPN not working anymore

theprojectgroup · Sun Oct 20, 2019 11:37 pm

Hey People,
since iO13 or macOS Catalina IKEv2 VPN isn't working anymore (client certificates).

While trying to connect you get this error:

"User authentication failed"

From the MikroTik logs everything looks fine (client gets an IP assigned). MacOS Mojave and iOS12 are still working fine.

This thread shows the same issue (https://forums.developer.apple.com/thread/121193) and suggests setting sha2-truncbug to "no" in /etc/ipsec.conf on the VPN server.
Whats the setting on iOS?
"Apple seems to have silently fixed their racoon code which is known to be buggy with SHA-256 authentication algorithm truncation.
The problem can be fixed also for racoon gateways by removing hmac_sha256 from the list of IKE phase 2 authentication algorithm proposals. Unfortunately, Apple IPhones with IOS13 then choose the weak SHA-1 algorithm."

There were some issues regarding sha2-truncbug in earlier RouterOS versions (viewtopic.php?f=2&t=116556&p=576808&hil ... ug#p576808).

Here are some infos in the FAQ of LibreSwan (https://libreswan.org/wiki/FAQ).

Official announcement (IKEv1): https://support.apple.com/en-us/HT210432

Starting with iOS 13, IPsec supports HMAC-SHA-256 with IKEv1 VPN.
"To make sure that your iOS 13 and macOS Catalina clients can connect to your IKEv1 or VPN server, configure the server to truncate the output of the SHA-256 hash to 128 bits. Truncating to a smaller number of bits might cause the server to drop data that VPN clients transmit."

Any ideas?

- EDIT -
Solution: viewtopic.php?f=2&t=153155&p=755967#p757762

stonerhash · Mon Oct 21, 2019 4:39 pm

I have the same problem. With android it works successfully. But on iOS13 it does not. Is it a Mikrotik issue or iOS?

theprojectgroup · Mon Oct 21, 2019 5:38 pm

Don't want to blame anyone... The tunnel seems to establish fine but iOS thinks it's an "User Authentication" error.
Regarding to apple we need to "configure the server to truncate the output of the SHA-256 hash to 128 bits" on the MikroTik, but how?
Emil is already on it (opened a ticket, support.rif submitted)

stonerhash · Mon Oct 21, 2019 9:50 pm

If it is SHA256 issue I would expect that by using SHA1 would work. But this is not the case. Even MD5 does not work. All produce authentication errors. Lets hope that Mikrotik will release a fix soon cause this is a major issue

theprojectgroup · Mon Oct 21, 2019 9:53 pm

confirmed, changing to different hash algorithm doesn't help.

stonerhash · Mon Oct 21, 2019 10:32 pm

I found and iPhone 12.4.2, released after 13. Last update. I am having the same issue. Can anyone confirm?

UPDATE: My fault it works. I had to add the "Local ID"

theprojectgroup · Mon Oct 21, 2019 11:11 pm

I found and iPhone 12.4.2, released after 13. Last update. I am having the same issue. Can anyone confirm?

UPDATE: My fault it works. I had to add the "Local ID"

I am confused and can’t understand what you are saying. Please let us know what works and what not and how you probably fixed it.

stonerhash · Mon Oct 21, 2019 11:20 pm

I found and iPhone 12.4.2, released after 13. Last update. I am having the same issue. Can anyone confirm?

UPDATE: My fault it works. I had to add the "Local ID"
I am confused and can’t understand what you are saying. Please let us know what works and what not and how you probably fixed it.

I made an invalid statement that the configuration does not also work with iOS 12.4.2. But it actually does work. I had a mistake in my configuration.

theprojectgroup · Tue Oct 22, 2019 9:45 am

Just found the RFC wich mentions the truncate issue:
https://tools.ietf.org/html/rfc8221

AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no
SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST
be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due
to a long standing common implementation bug of this algorithm that
truncates the hash at 96 bits instead of 128 bits, it is recommended
that implementations prefer AUTH_HMAC_SHA2_512_256 over
AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.

theprojectgroup · Tue Oct 22, 2019 10:00 am

https://forums.developer.apple.com/thread/121193

ccolardeau · Tue Oct 22, 2019 1:43 pm

Hello,
Do you have any update on this problem please ?
"User Authentication Problem" seems to be persisted even if I changed to Sha1 proposal.
Thanks for your help.
Christophe

theprojectgroup · Wed Oct 23, 2019 6:53 pm

Not yet - Emil from support suggested to check the certificate to include the subject alternative names of local and remote id which didn't help (i just tried it with the client certificate)

Screenshot 2019-10-23 at 17.52.16.png

theprojectgroup · Wed Oct 30, 2019 10:39 pm

SOLVED:
Thx to Emils Z. from support.
He pointed out, that in iOS13 & macOS Catalina "Apple has added SAN certificate field verification and it fails in the new version because your certificates does not have any Subject Alt".
I re-created both certificates for client & server with subject alternative names field (SAN) configured:

PastedGraphic-2.png

Solution: create certificates with SAN fields configured
Now it's working on iO13 and macOS catalina

pipoe2h · Thu Nov 14, 2019 2:32 am

SOLVED:
Thx to Emils Z. from support.
He pointed out, that in iOS13 & macOS Catalina "Apple has added SAN certificate field verification and it fails in the new version because your certificates does not have any Subject Alt".
I re-created both certificates for client & server with subject alternative names field (SAN) configured:
PastedGraphic-2.png

Solution: create certificates with SAN fields configured
Now it's working on iO13 and macOS catalina

Did you changed something else on your IKEv2 configuration? This is not working for me and I have the SAN on the certificates and in the server matching the common name with the SAN DNS.

theprojectgroup · Thu Nov 14, 2019 10:24 am

no - except of changing to the new certificate

Did you change it?
Can you show screenshots of your certs?

Screenshot 2019-11-14 at 09.23.49.png

pipoe2h · Thu Nov 14, 2019 2:44 pm

Yes, I changed the certificates.

You setup for the peer is different of mine. Wondering if that can be another of the reason. BTW, what RouterOS version are you running? Mine (6.43.

doesn't look like yours.

theprojectgroup · Thu Nov 14, 2019 10:59 pm

I'm on the most current 6.45.7

this is my config:

/ip ipsec profile
add dh-group=modp2048 dpd-interval=1h enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=1h name=ikev2
/ip ipsec peer
add exchange-mode=ike2 name=ikev2 passive=yes profile=ikev2 send-initial-contact=no
/ip ipsec proposal
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-gcm lifetime=1h name=ios-ikev2-proposal pfs-group=modp2048
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=vpn ranges=192.168.1.250-192.168.1.253
/ip ipsec mode-config
add address-pool=vpn name=vpn

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" disabled=yes ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="nat for vpn clients" out-interface=bridge
/ip ipsec identity
add auth-method=digital-signature certificate=vpn.server generate-policy=port-strict mode-config=vpn peer=ikev2 remote-certificate=vpn.client
/ip ipsec policy
set 0 proposal=ios-ikev2-proposal

/certificate print 
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted 
 #         NAME                                   COMMON-NAME                                 SUBJECT-ALT-NAME                                                              FINGERPRINT                                
 0 K  A  T my.ca                                  my.ca                                                                                                                   
 1 K  A    vpn.server                             vpn.server                                  DNS:vpn.server                                                               
 2 K  A    vpn.client                             vpn.client                                  DNS:vpn.client

Romanni4 · Fri Nov 22, 2019 10:43 am

Hi there!

I'm trying to use your config - but it does not work for me!
I have 2 devices:
1. iOS 13.2.3
2. MacOS 10.15.1

[admin@Home CCR01009] /ip ipsec policy> /certificate print
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired,
T - trusted
# NAME COMMON-NAME SUBJECT-ALT-NAME
0 K A T my.ca my.ca DNS:my.ca
1 K A vpn.server vpn.server DNS:vpn.server
2 K A vpn.client vpn.client DNS:vpn.client

Снимок экрана 2019-11-22 в 11.41.57.png

All my certificates got Alt-Names (DNS), but i received: VPN server did not respond.
Any ideas?

theprojectgroup · Fri Nov 29, 2019 4:00 pm

What do the certificates look like?

SupermanSC · Tue Feb 18, 2020 10:18 pm

theprojectnewbie,

I had all this working on IOS12 / High Sierra, however since upgrading to IOS13 / Catalina, I'm getting an array of different issues. Thinking this was related to the SAN issue you mentioned above, I wiped everything out and started over while generating SAN names identical to yours for testing. We'd like to get this functioning for 3 users, each with a MacBook and an iPhone.

I'm curious about your certificates, are you generating all the certs on the Mikrotik and exporting those to the Mac devices directly or are you needing to use Apple Configurator 2 to disable EAP support per this article (https://itimagination.com/mikrotik-ikev ... tup-guide/)?

When this was working several months ago, on our iPhones, the remote ID and server hostname were both set to a DNS hostname that resolved to our MicroTik, is this also what you have or are you specifying it via IP (which is actually preferred if there some sort of major DNS issue)? Also, for LocalID, are you setting that to anything or leaving it blank? On our iPhone configs that used to work, those were blank.

These are our certs as of now. I'd like to add 6 in total, one for each iPhone/Laptop.

Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME SUBJECT-ALT-NAME FINGERPRINT
0 K A T companyname.ca companyname.ca
1 K A vpn.server vpn.server DNS:vpn.server
2 K I vpn.client vpn.client DNS:vpn.client
3 K A vpn.JohnB-iPhone vpn.JohnB-iPhone DNS:vpn.JohnB-iPhone

theprojectgroup · Wed Feb 26, 2020 5:55 pm

Hey,
yes I generate the certs on MT and export (p12) to my mac, then I use apple configurator:
- add both certificates here:

Screenshot 2020-02-26 at 16.54.23.png

vpn_home.mobileconfig 2020-02-26 16-56-33.png

Screenshot 2020-02-26 at 16.55.15.png

Screenshot 2020-02-26 at 16.55.42.png

Todd2 · Mon Apr 27, 2020 8:01 pm

theprojectnewbie,

I had all this working on IOS12 / High Sierra, however since upgrading to IOS13 / Catalina, I'm getting an array of different issues. Thinking this was related to the SAN issue you mentioned above, I wiped everything out and started over while generating SAN names identical to yours for testing. We'd like to get this functioning for 3 users, each with a MacBook and an iPhone.

I'm curious about your certificates, are you generating all the certs on the Mikrotik and exporting those to the Mac devices directly or are you needing to use Apple Configurator 2 to disable EAP support per this article (https://itimagination.com/mikrotik-ikev ... tup-guide/)?

When this was working several months ago, on our iPhones, the remote ID and server hostname were both set to a DNS hostname that resolved to our MicroTik, is this also what you have or are you specifying it via IP (which is actually preferred if there some sort of major DNS issue)? Also, for LocalID, are you setting that to anything or leaving it blank? On our iPhone configs that used to work, those were blank.

These are our certs as of now. I'd like to add 6 in total, one for each iPhone/Laptop.

Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME SUBJECT-ALT-NAME FINGERPRINT
0 K A T companyname.ca companyname.ca
1 K A vpn.server vpn.server DNS:vpn.server
2 K I vpn.client vpn.client DNS:vpn.client
3 K A vpn.JohnB-iPhone vpn.JohnB-iPhone DNS:vpn.JohnB-iPhone

Works for me. Thanks a lot!

anav · Tue May 12, 2020 5:05 am

Hmm, not working for me.
No problems adding the alternate name bit.
I even get a good connection on the MT with a viable active peer.
The problem is on the iphone side which doesnt connect and says unathorized client or user etc.......

anav · Tue May 12, 2020 2:28 pm

Okay same issues not solved. I managed to add the DNS:vpn.server and DNS:vpn.client alternate names in the certificate but the results were the same.

The only details I could find direct from IOS are posted below (1-5). The first three items are covered I believe by the current setup.
Need help understanding 4!!

Oopsie on number five I added a zero to 365 which puts it way past 825 days, to will try 800 and see what comes back
Edit: I set the certificates to 800 days with same result.

Yes I tried every combination of settings from above with no joy.

I think the problem may be item 4 below.
How do I ensure #4 is followed??

Requirements for trusted certificates in iOS 13 and macOS 10.15
All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:
1- TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
2- TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
3- TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

4- TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.??????????
5- TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

anav · Tue May 12, 2020 2:33 pm

Too funny, I made the changes to the #days but left out tls client and tls server on the certificates (check box options).
Will do that now and let you know.

Nope. No difference after adding back in tls server and client on the certificate check boxes and creating new certificates. Still user authentication failed no matter what is entered.

theprojectgroup · Tue May 12, 2020 3:12 pm

My certificates:

Screenshot 2020-05-12 at 14.08.04.png

I guess key usage must be at least tls-client for client and tls-server for server

Screenshot 2020-05-12 at 14.09.50.png|200px

Screenshot 2020-05-12 at 14.09.59.png|20%

Screenshot 2020-05-12 at 14.10.07.png|20%

Screenshot 2020-05-12 at 14.10.19.png|20%

Screenshot 2020-05-12 at 14.10.22.png|20%

anav · Tue May 12, 2020 4:19 pm

We are extremely close in settings.
I do not have any entries for issuer (your CN=my.ca) but I didnt have them before and dont think its a showstopper.
I have 800 days for my server and client certificate, I will change to 365 although I have a feeling that will not make a difference.

(quick question, do my ca expiry date have to match the client and vpn expiry days???)

The final point I will make is that my actual server and client names are not copies of the common name.
When I add alternate name however, they are copes of the common name.

For example server name is myvpn.server, with common name vpn.server and altname DNS:vpn.server
For example client name is myvpn.client, with common name vpn.client and altname DNS:vpn.client

Is this a problem? Should the alternate name match the actual name (vice common name)?

theprojectgroup · Tue May 12, 2020 5:03 pm

ahm, if you don't have a value in issuer field the cert is not signed by the CA?
ca expiration date doesn't has to match client cert date...
try to re-create that all from scratch. New ca on router, new certs on router, sing them with router's ca...
match cn and dns (SAN)
name of the cert could be any, just match it with your cn for easier reading...

anav · Tue May 12, 2020 5:38 pm

Yes, I am attempting to figure that out.
I use the SIGN feature in system certificates and I am signing the vpn.server and vpn.client certificates so it seems but no issuer info ever gets set in there. So my question is how does one get data into the issuer field - via the MT method of self signing certificates??
I also have discovered another potential issue.
Despite including the two tls entries when creating the certificates, the iphone certificate (client) that I imported seems to be missing these two elements.
Can anyone check to on their iphone or imac, whether or not the client certificate shows all 7 attributes and not just 5.

https://imgur.com/a/TG1zzCm

In this linked presentation, there are no issuers??
https://mum.mikrotik.com/presentations/ ... 945783.pdf

theprojectgroup · Tue May 12, 2020 5:58 pm

Yours also shows all 7. 5+2
Extended Key Usage: Client and server authentication. Same on mine.

When you sign the certificate on MT, you must select the existing CA. Otherwise you just get a self signed.

anav · Tue May 12, 2020 6:16 pm

Okay maybe I am really daft here, but when I sign the vpn.client and vpn.server certificates, in the popup box there are two selections to be made:

1. "Certificate" - This is simply the name that you have given the certificate in my case, lets say I am doing the client one. So my entry is for example myvpn.client
2. "CA" - This is simply the original 'base' router certificate I created first.

I just deleted all to start from scratch and now I cannot sign my router certificate as there is no CA available it says unknown in red???
Okay so the first certificate (master) self-signed by ignoring the CA entry in winbox or just using these commands
/certificate add name=my.ca common-name=my.ca key-usage=key-cert-sign,crl-sign trusted=yes
/certificate sign my.ca

Gives me a result where i Have my base Certificate on the router, BUT IT HAS NO CA entry (and no issuer).
I am able to use this though as the CA for both the vpn.server and vpn.client certificates. (but no issuer appears for them).

Does the above make sense? If so where do I go from here??

anav · Tue May 12, 2020 10:07 pm

MT: So its impossible for me to get an entry in issuer no matter what I try.

Apple: With IOS 13 one needs to go to Settings General About - trusted certificates to physically enable the certificate there, which is separate from the General - Settings - Profiles, where one installs the certificate.

*** The problem is there is no entry in the Trusted Certificates section for me to enable???
The discussions have stated if the cert cannot be traced back to a ROOT CA, it will not appear.

Are folks only sending their client certification to the iphone?

anav · Wed May 13, 2020 3:22 am

For future Iphone users, 3 items have changed.
(1) a. Both certs are required (.ca & .client) but they have to be done/installed separately.
b. As well as installing the .ca certificate one has to, on the iphone, also enable the cert under Trusted Certificates.

(2) Have to use Subj Alternate name and format is DNS:actual name (and not DNS:common name)
(3) Max 800 days on certificates

Observation on Key usage.
For the .ca cert only need 'key cert sign', and 'crl sign'
For .server and .client certs only need two keys (not 7) (tls client & tls server)

pavelion · Wed Nov 25, 2020 8:52 pm

For any other fellows struggling to make certificates work with IKEv2 on macOS Big Sur (possibly also with previous versions) - make sure to issue both server & client certificates with subjectAltName field (Subject Alternative Name X509 extension).

I did generate client certificate without it, Mikrotik complained about "peer identity not found" even though it identified the peer with IP or FQDN supplied by macOS client, however the CERT payload was missing and authentication always failed.

patrickmkt · Sun Dec 13, 2020 7:03 am

I did generate client certificate without it, Mikrotik complained about "peer identity not found" even though it identified the peer with IP or FQDN supplied by macOS client, however the CERT payload was missing and authentication always failed.

I am also struggling with peer identity not found. My setup was working fine until a few weeks ago (IOS update or ROS update? I can't figure it out as I discovered the problem after having updated both).
My client and server certs have the SAN DNS field same as common name.
I can't figure out how to make it back to work.

I'll appreciate if someone would have a clue if anything has changed with the latest updates?

sindy · Sun Dec 13, 2020 9:55 am

My client and server certs have the SAN DNS field same as common name.

Does that fqdn in Subject Alt Name of the certificate of the Mikrotik resolve in public DNS to the IP address of the Mikrotik to which the MacOS connects?

And do you also get "peer identity not found" at Mikrotik side or it just "stopped working"?

patrickmkt · Sun Dec 13, 2020 10:45 pm

My client and server certs have the SAN DNS field same as common name.
Does that fqdn in Subject Alt Name of the certificate of the Mikrotik resolve in public DNS to the IP address of the Mikrotik to which the MacOS connects?

And do you also get "peer identity not found" at Mikrotik side or it just "stopped working"?

The SAN DNS:myserver.com entry for the server certificate does resolve (but not for the SAN DNS: client.myserver.com for the client certificate however as it is a roadwarrior).

The relevant messages I have in the ROS log are

ID_I(FQDN):client.myserver.com
ID_R(FQDN):myserver.com
processing payload: AUTH (not found)
requested server id: myserver.com
identity not found for server:myserver.com peer: FQDN: client.myserver.com
reply notify: AUTHENTICATION_FAILED

sindy · Mon Dec 14, 2020 10:39 am

(but not for the SAN DNS: client.myserver.com for the client certificate however as it is a roadwarrior).

That's clear.

The relevant messages I have in the ROS log are

That looks as if the Apple device didn't like the certificate it should use to authentify itself, so it doesn't provide it as ID_I. You may try to change the /ip ipsec identity row at Mikrotik side to remote-id=fqdn:client.myserver.com match-by=remote-id, but if the assumption above is correct, it won't help, you'll just end up with a different set of errors.

xiaotuzi · Wed Dec 23, 2020 9:47 am

Anyone got this solved on IOS14 and ROS 6.47.8 ?

nevolex · Sun Feb 21, 2021 11:25 am

Anyone got this solved on IOS14 and ROS 6.47.8 ?

same issue

sebus · Wed Feb 23, 2022 8:42 am

Isn't it that client certificate SAN needs to have

UPN should be encoded as an "otherName" value in the SAN with a type-id of 1.3.6.1.4.1.311.20.2.3 (Microsoft UPN); not a dNSName.

Who is online