Hi Everyone,


I have been having issues with my vpn connection (ikev2), as also mentioned in a few topics here from other people, "it works everywhere else but on Apple devices..."

Found this information:

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.--- not quite sure where
to check this part of the requirements..
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

.

To see the digest-algorithm used, you have to display the certificate parameters using the command line,
/certificate print detail where common-name~"vpn".
But when signing certificates, RouterOS normally uses SHA-256, which is from the SHA-2 suite, so it fits those requirements.

As for the rest, I suppose you've used the DNS name of the Mikrotik, which is used in the Subject-Alt-Name of the certificate, also to configure the remote server field in the Apple VPN client?

Don't fall to false hopes - I don't have a working setup, I'm just trying to help.

And the log from the Apple says authentication failed but doesn't explain whether it got a NOTIFY from the Mikrotik or it didn't like Mikrotik's authentication information. So what does Mikrotik's IPsec log show?

To see the digest-algorithm used, you have to display the certificate parameters using the command line,
/certificate print detail where common-name~"vpn".
But when signing certificates, RouterOS normally uses SHA-256, which is from the SHA-2 suite, so it fits those requirements.

As for the rest, I suppose you've used the DNS name of the Mikrotik, which is used in the Subject-Alt-Name of the certificate, also to configure the remote server field in the Apple VPN client?

Don't fall to false hopes - I don't have a working setup, I'm just trying to help.

And the log from the Apple says authentication failed but doesn't explain whether it got a NOTIFY from the Mikrotik or it didn't like Mikrotik's authentication information. So what does Mikrotik's IPsec log show?

Thank you very much for your quick reply Sindy, I understand, that troubleshooting vpn is not easy, thank you for your effort as well

[admin@MikroTik_RB4011] > /certificate print detail where common-name~"vpn"
Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, T - trusted
0 K I name="VPN_Server" digest-algorithm=sha256 key-type=rsa country="NZ" state="xxxx" organization="Alex's House" common-name="vpn.xxxx.me" key-size=2048 subject-alt-name=DNS:vpn.xxxx.me days-valid=3650
trusted=no key-usage=tls-server ca=Certification_Authority serial-number="2A5A845219E41AEE" fingerprint="769b7d9305e9e21517fbb3652f9exxxxxxdaaaxxxxxxxxxxxxxxxxxxxx"
akid=0c3ee70764xxxxxxxxxxxxxxxxxxxxxx skid=1f4da3ef9bd3125cxxxxxcxxxxxxxxxxxxxxxxxxx invalid-before=nov/05/2020 21:11:12 invalid-after=nov/03/2030 21:11:12 expires-after=506w9h53m22s
[admin@MikroTik_RB4011] >

The log from the Mikrotik shows that the Apple uses its private IP address as its identifier (ID_I), so the Mikrotik cannot find a corresponding row in /ip ipsec identity . But if I understand it right, this actually indicates that the Apple device doesn't consider its own certificate fit for its own authentication. What are the key-usage items of the certificate you've generated for the Apple? Mikrotik is happy with the tls-client value in the initiator's certificate, but the Apple may require one of those ipsec-something ones.

The log from the Mikrotik shows that the Apple uses its private IP address as its identifier (ID_I), so the Mikrotik cannot find a corresponding row in /ip ipsec identity . But if I understand it right, this actually indicates that the Apple device doesn't consider its own certificate fit for its own authentication. What are the key-usage items of the certificate you've generated for the Apple? Mikrotik is happy with the tls-client value in the initiator's certificate, but the Apple may require one of those ipsec-something ones.

I have this one set up, sindy:

for the user cert:

key usage - tlc client




tried to change some settings from

viewtopic.php?t=155828 but got the same results :

feb/21 11:11:16 ipsec,error identity not found for server:vpn.xxxx.me peer: ADDR4: 10.10.0.19
feb/21 11:11:16 ipsec,error ipsec: identity not found for server:vpn.xxxxx.me peer: ADDR4: 10.10.0.19

or

eb/21 11:11:16 ipsec,error ipsec: identity not found for server:vpn.xxxxx.me peer: fqdn name - cert name etc

As I've got no Mac/iPhone laying around, let alone with the OS version in question - can you post the window that opens if you click [Authentication Settings...] in the window you've already posted?

As I've got no Mac/iPhone laying around, let alone with the OS version in question - can you post the window that opens if you click [Authentication Settings...] in the window you've already posted?

Sindy, you are a legend!, if you didn't point it out I would not double-check that at it was chosen a " certificate" and the user cert was there,I changed to "none" and picked the certificate and it gave me a different error, for the 1st time after 6 hours of testing, it must have been a macos software bug
I had a new error with the config as it's on a screenshot, then in Remore ID type to swapped to ignore and was able to connect, can you please recommend if you know please, was settings i should try to play with to keep the Remore ID as auto or at least not as "ignore"

thanks alot

I'd say match-by=certificate remote-certificate=the-one-of-the-client should do the trick with either remote-id=ignore or remote-id=auto. But it's just a guess, maybe auto is necessary, as in fact the header of the certificate is sent as the ID, as the log should show you. Maybe Apple does that differently - again, log will show.

But there is actually nothing bad about ignoring the remote ID (unless you need to choose a particular mode-config and/or policy-template-group per individual client) if the client is authenticated by certificate - the connection will fail if the client presents an invalid certifcate, or one signed by an unknown CA, it's just that the same identity row will be chosen for multiple clients.

I'd say match-by=certificate remote-certificate=the-one-of-the-client should do the trick with either remote-id=ignore or remote-id=auto. But it's just a guess, maybe auto is necessary, as in fact the header of the certificate is sent as the ID, as the log should show you. Maybe Apple does that differently - again, log will show.

But there is actually nothing bad about ignoring the remote ID (unless you need to choose a particular mode-config and/or policy-template-group per individual client) if the client is authenticated by certificate - the connection will fail if the client presents an invalid certificate, or one signed by an unknown CA, it's just that the same identity row will be chosen for multiple clients.

Thank you Sindy but got the same results, here are the logs with standard settings no specific user cert is chosen and remote-id is set to auto, this is when I now get "peer id doesn't match cert "

You may have misunderstood me. The identity row, even if just a single one is attached to a peer, is always matched on either the remote ID or the certificate (depending on the setting of the match-by parameter). So if remote-id is set to ignore, the row will match on any ID_I received, and the only thing to be checked about the certificate is whether it has been signed by a known certification authority. If you set match-by=certificate, the certificate received from the initiator peer is used also to find the matching identity row, so it must be stored on the Mikrotik and the remote-certificate of the identity must point to it. BTW, in this case, only the header fields of the certificate is compared, so even if the one stored at Mikrotik expires, a valid (renewed) certificate with the same header fields is properly matched.

The log shows that the Apple does not send a reference to the certificate as its ID, and keeps sending the IP address as ID_I:

formatted code

23:33:19 ipsec ipsec: processing payload: ID_I 
23:33:19 ipsec ipsec: ID_I (ADDR4): 10.10.0.19 
23:33:19 ipsec ipsec: processing payload: ID_R 
23:33:19 ipsec ipsec: ID_R (FQDN): vpn.xxx.me 
23:33:19 ipsec ipsec: processing payload: AUTH 
23:33:19 ipsec ipsec: processing payload: CERT 
23:33:19 ipsec ipsec: got CERT: CN=AlxxxxxxVPN,C=NZ,ST=Wellington,L=,O=Alex's House,OU=,SN= 

You may have misunderstood me. The identity row, even if just a single one is attached to a peer, is always matched on either the remote ID or the certificate (depending on the setting of the match-by parameter). So if remote-id is set to ignore, the row will match on any ID_I received, and the only thing to be checked about the certificate is whether it has been signed by a known certification authority. If you set match-by=certificate, the certificate received from the initiator peer is used also to find the matching identity row, so it must be stored on the Mikrotik and the remote-certificate of the identity must point to it. BTW, in this case, only the header fields of the certificate is compared, so even if the one stored at Mikrotik expires, a valid (renewed) certificate with the same header fields is properly matched.

The log shows that the Apple does not send a reference to the certificate as its ID, and keeps sending the IP address as ID_I:

formatted code

23:33:19 ipsec ipsec: processing payload: ID_I 
23:33:19 ipsec ipsec: ID_I (ADDR4): 10.10.0.19 
23:33:19 ipsec ipsec: processing payload: ID_R 
23:33:19 ipsec ipsec: ID_R (FQDN): vpn.xxx.me 
23:33:19 ipsec ipsec: processing payload: AUTH 
23:33:19 ipsec ipsec: processing payload: CERT 
23:33:19 ipsec ipsec: got CERT: CN=AlxxxxxxVPN,C=NZ,ST=Wellington,L=,O=Alex's House,OU=,SN= 

Sindy, thanks alot for your help, all the issues were related to idiotic ikev2 requirements of mac os itself I didn't have to adjust anything else, all was left as auto I just had to specify "Local ID" (in mac os vpn configurator) that is the user's cert subject alt name and all worked :)

so in network settings in mac os you absolutely have to use:

server address = vpn server fqdn or ip (from server cert)
remote id = same vpn server fqdn or ip (from server cert)
local id - user's subject alt name not the common name but they can be the same, the user cert must have "subject alt name" it in order to work in mac os (user cert)