Windows 10 ikev2 13801: IKE authentication credentials are unacceptable error

patrickmkt · Sun Aug 18, 2019 1:35 pm

I am loosing my mind trying to do a certificate authentication between a Mkt server and a windows 10 client using ikev2.

I can log in to the Mkt server from an iPhone, however, I got the dreaded error from Windows saying: "IKE authentication credentials are unacceptable".

I am also lost how to find any relevant data in windows log, as the only thing I was able to find in the event viewer was the failed connection and the error 13801 associated with it.

From an internet search, common causes for this issue are:

The machine certificate, which is used for IKEv2 validation on the RAS Server, does not have Server Authentication as the EKU (Enhanced Key Usage).
The machine certificate on RAS server has expired.
The root certificate to validate the RAS server certificate is not present on the client
The VPN Server Name, provided on the client, does not match with the subjectName of the server certificate.

I have checked that the server certificate has the proper Server Authentication and IP security Intermediate IKE EKU, in addition to Digital Signature and Key Encipherment.
The CN has the fqdn and the SAN has also the DNS fqdn.
I have tried with the root certificate and intermediate certificate in both the local and machine certificate store in the Windows Client.
I have tried to add to the mikrotik identity setting the certificate both the intermediate and root certificate in addition to the server one.

The Mikrotik log shows that during the ESP phase, after negotiating a match proposal, the windows client did not send its identity, but only its ID_I (ADDR4) ip address and the server show an error as identity not found as no certificate was sent.

My question is two folds:
Does someone knows how to increase/create/find a verbose log for the VPN connection on Windows 10?
Do you have any clue what could be my problem?

sindy · Sun Aug 18, 2019 3:20 pm

The possible reasons you've googled may be related both to Windows acting as server and to Windows acting as client so not all of them may be relevant.

Unless Windows need something specific, the normal requirements are the following:

to be able to prove its own identity to the remote party, each local party needs to have the private key for its own certificate.
to be able to check the authenticity of the remote party, each local party needs to have access to public certificates of the complete chain of trust of the other party's public certificate - the public certificate of the ultimate root CA in the issuing chain as well as the public certificates of any intermediate CAs, and the root CA's public certificate must be marked as trusted root CA (stored in the appropriate certificate store) locally.

So if you have generated the machine certificate for the Windows client elsewhere, make sure you have exported it including the private key. If you have created and exported the certificate for the Windows client on the Mikrotik itself, it means that you have to enter the passphrase for the key when exporting it, otherwise the private key is silently not exported (and the Windows don't ask for the passphrase when importing the certificate).

To allow Windows to verify authenticity of the server's (Mikrotik's) certificate, you have to export (this time without the private key) the certificate of the issuing CA and any intermediate CAs for the Mikrotik's certificate and import them to Windows, where the certificate of the root CA in the server's chain of trust must be stored in the "trusted root CA" store.

Failure in one of the points above is the most likely explanation why the Windows' VPN client doesn't send its own certificate.

Similarly, to allow the Mikrotik to verify authenticity of the client's certificate (once the Windows VPN client sends it after all), you have to install the public certificate of the root CA and all the intermediate CAs in the chain of trust of the client's certificate on the Mikrotik. Only if you want to use the client certificate itself as as a selector value to the /ip ipsec identity, you need to store the client's public certificate itself on the Mikrotik. If you've generated the certificate on the Mikroik itself, these requirements are automatically met.

patrickmkt · Wed Aug 21, 2019 7:34 pm

Thanks,
I had all the chain of trust of the CA in both the client and server.
The client certificate had its key too.

I am really surprised not to find any information how to get a better error log on the windows vpn client... That would point me into the right direction instead of playing half blind with only the Mikrotik side.

McSee · Wed Aug 21, 2019 9:05 pm

If you have more than one certificate installed in Local Computer Personal certificate store that might be used for client authentication, you might need to specify one to be used by MachineCertificateIssuerFilter parameter of a VPN connection.

PowerShell command for this is:

Set-VpnConnection -Name VPN_connection_name -MachineCertificateIssuerFilter "path_to_CA.cer_file"

patrickmkt · Wed Aug 21, 2019 9:19 pm

I had selected the option to have windows asking me which client certificate to use each time. And indeed I have a dropdown box letting me chose at the connection time.

McSee · Wed Aug 21, 2019 9:39 pm

If you have dropdown box you are using wrong auth method, it should be Use machine certificates.

ike2.png

patrickmkt · Wed Aug 21, 2019 10:03 pm

I believe that I tried with machine certificate before without success also and eventually reading that both could be used as long as the certificates and chain were in the proper stores (user or machine).
But to make sure I tried again. I even put all the certificates in both chain. Still the same error message.

McSee · Thu Aug 22, 2019 5:51 pm

EAP auth with cert doesn't work with Mikrotik as an IKEv2 server, it doesn't see client cert at all, as you found, nor recognize auth method.

What error message do you see in your Mikrotik's log with Use machine certificates selected on the client ?
Isn't it hh:mm:ss ipsec,error can't verify peer's certificate from store ?

patrickmkt · Fri Aug 23, 2019 11:17 am

With the same series of certificate:
When I successfully connect from an Iphone:

aug/22 16:05:54 ipsec ike auth: respond 
aug/22 16:05:54 ipsec processing payload: ID_I 
aug/22 16:05:54 ipsec ID_I (FQDN): My_Client_Cert 
aug/22 16:05:54 ipsec processing payload: ID_R 
aug/22 16:05:54 ipsec ID_R (FQDN): my.server.com 
aug/22 16:05:54 ipsec processing payload: AUTH 
aug/22 16:05:54 ipsec processing payload: CERT 
aug/22 16:05:54 ipsec got CERT: CN=My_Client_Cert,OU=My_Client_Cert 
aug/22 16:05:54 ipsec requested server id: my.server.com
[...]
aug/22 16:05:54 ipsec IKE Protocol: ESP 
[...]
aug/22 16:05:54 ipsec ike auth: finish 
aug/22 16:05:54 ipsec ID_R (FQDN): my.server.com 
aug/22 16:05:54 ipsec processing payload: NONCE 
aug/22 16:05:54 ipsec cert: CN=my.server.com 
aug/22 16:05:54 ipsec adding payload: CERT 
aug/22 16:05:54 ipsec cert: CN=intermediateCA.my.server.com 
aug/22 16:05:54 ipsec adding payload: CERT 
aug/22 16:05:54 ipsec cert: CN=rootCA 
aug/22 16:05:54 ipsec adding payload: CERT 
aug/22 16:05:54 ipsec adding payload: ID_R 
aug/22 16:05:54 ipsec adding payload: AUTH

When I attempt to connect from Windows with a machine certificate:

03:52:29 ipsec ike auth: respond 
03:52:29 ipsec processing payload: ID_I 
03:52:29 ipsec ID_I (DER DN): CN=My_Client_Cert,OU=My_Client_Cert 
03:52:29 ipsec processing payload: ID_R (not found) 
03:52:29 ipsec processing payload: AUTH 
03:52:29 ipsec processing payload: CERT 
03:52:29 ipsec got CERT: CN=My_Client_Cert,OU=My_Client_Cert 
03:52:29 ipsec,error identity not found for peer: DER DN: CN=My_Client_Cert,OU=My_Client_Cert 
03:52:29 ipsec reply notify: AUTHENTICATION_FAILED

When I attempt to connect with a local certificate from Windows:

03:53:43 ipsec ike auth: respond 
03:53:43 ipsec processing payload: ID_I 
03:53:43 ipsec ID_I (ADDR4): 192.168.123.100 
03:53:43 ipsec processing payload: ID_R (not found) 
03:53:43 ipsec processing payload: AUTH (not found) 
03:53:43 ipsec,error identity not found for peer: ADDR4: 192.168.123.100 
03:53:43 ipsec,error identity not found for peer: ADDR4: 192.168.123.100 
03:53:43 ipsec reply notify: AUTHENTICATION_FAILED 
03:53:43 ipsec adding notify: AUTHENTICATION_FAILED

So it appears that at least with a machine certificate a proper certificate is presented while it is not with a local certificate as McSee indicated.

However, the main difference I see between the iPhone and Windows is that the iphone present:
ipsec ID_I (FQDN): My_Client_Cert
ipsec ID_R (FQDN): my.server.com

while Windows does not seem to send the ID_R as I got ID_R (not found).

McSee · Fri Aug 23, 2019 7:59 pm

Looks like you explicitly set my-id for an identity instead of leaving it at auto (it's My ID type in WinBox).
So it should match to ID_R that a client presents.
If that's the case try to set it to auto .

patrickmkt · Sat Aug 24, 2019 12:05 pm

I have set up as follow:
remote id type= auto
match by=certificate

I also tried with match by id with all the different remote id type

sindy · Sat Aug 24, 2019 4:27 pm

I'm afraid @McSee might have in mind the own ID at Mikrotik side, which it uses to match the ID-R received from the initiator. So double-check that you have my-id in the identity row set to auto. I've tested here and I have no issue although the log shows that the Windows client sends, like in your case, no ID-R at all and ID-I as DER DN:

14:34:35 ipsec payload seen: ID_I
14:34:35 ipsec payload seen: CERT
14:34:35 ipsec payload seen: CERTREQ
14:34:35 ipsec payload seen: AUTH
14:34:35 ipsec payload seen: NOTIFY
14:34:35 ipsec payload seen: CONFIG
14:34:35 ipsec payload seen: SA
14:34:35 ipsec payload seen: TS_I
14:34:35 ipsec payload seen: TS_R
14:34:35 ipsec ike auth: respond
14:34:35 ipsec processing payload: ID_I
14:34:35 ipsec ID_I (DER DN): CN=w10-nb,C=tv,ST=,L=here,O=me,OU=mikrotik,SN=
14:34:35 ipsec processing payload: ID_R (not found)
14:34:35 ipsec processing payload: AUTH
14:34:35 ipsec processing payload: CERT
14:34:35 ipsec got CERT: CN=w10-nb,C=tv,ST=,L=here,O=me,OU=mikrotik,SN=

Unlike in your case, there are no complaints on inability to find the identity. However, on his machine I'm running 6.44.3, so it is not excluded that there is some regression in newer versions. There is also a similar topic from March/6.44.1 which is marked as SOLVED but continues by an open end.

patrickmkt · Sat Aug 24, 2019 5:00 pm

You're right. With the own ID to auto it does connect...
Thanks

Now I need to figure out why this difference behavior between iOS and Windows.
Also, I still need to fix the routing issue as windows does not get any gateway set up.

sindy · Sat Aug 24, 2019 5:45 pm

Now I need to figure out why this difference behavior between iOS and Windows.

If you mean the difference at Tik side, it is because iOS does send ID-R while Windows don't.

Also, I still need to fix the routing issue as windows does not get any gateway set up.

Have you specified any list of networks in split-include of the mode-config to which the identity row points? Beware - for Windows, the split-include may contain several subnets, but iOS reportedly only accepts the first one, and it cannot be 0.0.0.0/0.

patrickmkt · Sat Aug 24, 2019 6:32 pm

Yes I am aware of the split include limitation on Windows.

My issue was from my firewall rules. I had the VPN issue an IP from a dhcp pool that was managed by bridge rules, but obviously the ipsec connection is not an interface and not attached to a bridge. I had to add a new rule for the IP subnet.

sindy · Sat Aug 24, 2019 6:55 pm

My issue was from my firewall rules. I had the VPN issue an IP from a dhcp pool that was managed by bridge rules, but obviously the ipsec connection is not an interface and not attached to a bridge. I had to add a new rule for the IP subnet.

Yes, the payload packets coming via an IPsec SA are seen by the firewall as coming from the same interface through which the SA's transport packets carrying them came in. So in order to let the DHCPINFORM reach the DHCP server process, a permissive rule for protocol=udp dst-port=67 must match on src-address and/or on in-interface(-list) together with ipsec-policy=in,ipsec.

patrickmkt · Mon Aug 26, 2019 10:43 am

I now have another problem with Windows. When attempting to use a second VPN connection to another Mikrotik with a different intermediate CA, I have the known problem of WIndows presenting the wrong certificate (the one of the first vpn connection) and refusing the authentication.

To avoid this issue, I am supposed in Power Shell to add to the VPN settings, which issuing authority certificate should be use for the connection by using the command (in my case the client certificate is issued by the intermediate CA):

Set-VpnConnection -Name "VPN_connection_name" -MachineCertificateIssuerFilter "path_to_intermediateCA.cer_file"

I checked in the Windows log that the indeed, the intermediate CA certificate thumbprint was added to the filter of the vpn connection.
The client certificate, intermediate certificate and root certificate are in the machine certificate store.

However, when I attempt to connect, Windows does not even try to reach the server and return the error:
"Can't connect: an array that must contain at least one element is zero length."

Any suggestions?

fkons991 · Sat Oct 26, 2019 4:03 pm

I do it !
Windows 10 clients and iOS 13 clients can connect at the same time.
Thanks all for suggestions.
Special thanks to this man: https://directaccess.richardhicks.com/2 ... iguration/

My settings:
Certificates:
3650 days, key usage: all with 'ipsec' in name,
CA is self signed certificate with IP address in subjectAltName
server certificate with CN and subjectAltName as DNS:some.host.com, signed by CA
iOS remote certificate with CN and subjectAltName as some email, signed by CA
Windows10 remote certificate with CN and subjectAltName as WINDOWS_COMPUTER_NAME, signed by CA

Mikrotik side:
Policy: default
Proposals: default with Auth.alg. selected sha1,sha256, Encr. Alg. selected 3des,aes256, PFS: modp1024
Peers: default with "Passive" checked and "IKE2" exchange mode selected
Identities:
Iphone: default peer selected, auth method digital signature, server certificate with CN and subjectAltName as DNS:some.host.com, remote certificate with CN and subjectAltName as some email, My ID and remote ID type = auto, match by: certificate, generate policy: port strict
Windows10: default peer selected, auth method digital signature, server certificate with CN and subjectAltName as DNS:some.host.com, remote certificate with CN and subjectAltName as WINDOWS_COMPUTER_NAME, My ID and remote ID type = auto, match by: certificate, generate policy: port strict
Profiles: default with Hash sha256, Encr.alg 3des,aes128,aes256, DH group modp1024,modp2048, proposal check: obey, nat traversal checked
Mode configs: default with "Responder" checked, some address pool selected, and static DNS selected with IP address of router.

iOS side:
both CA and user certificates must be installed
VPN type: IKEv2
Server: ip or dns name of server
Remote ID: dns name of VPN server (i have one; you can enter IP address here but in this case you must re-create server certificate with IP address as subjectAltName)
Local ID: not needed
User Auth: none
Use certificate: yes
Certificate: select client certificate with email as subjectAltName
Proxy: off

Windows10side:
CA cert must be installed as trusted root certificate (i have installed in local machine store and in user store also)
Windows10 client certificate with CN and subjectAltName = WINDOWS_MACHINE_NAME must me installed in local machine cert store (not the user store).
Type of VPN: IKEv2
Data encryption: require
Auth: use machine certificate

BurliestTrout · Thu Jan 16, 2020 3:02 pm

Hi. Did anyone find solution for the "An array that must contain at least one element is zero length." when you try to connect ?

jerryroy1 · Thu Mar 12, 2020 7:51 pm

Thanks,
I had all the chain of trust of the CA in both the client and server.
The client certificate had its key too.

I am really surprised not to find any information how to get a better error log on the windows vpn client... That would point me into the right direction instead of playing half blind with only the Mikrotik side.

So, do I need to import both the CA cert and the client cert?

jerryroy1 · Thu Mar 12, 2020 8:23 pm

I keep getting "identity not found for peer: ADDR4: 192.168.86.26" The IP here is the ip assigned to me thru my AP at home. Any ideas?

sindy · Thu Mar 12, 2020 9:26 pm

I keep getting "identity not found for peer: ADDR4: 192.168.86.26" The IP here is the ip assigned to me thru my AP at home. Any ideas?

The idea is that you post your current config, anonymized as per my automatic signature below.
A wild guess is that you haven't set the identity representing your Windows 10 machine at Mikrotik side to match on the certificate itself (match-by=certificate).

To answer your previous question, you have to import the root CA's certificate to each piece of equipment which needs to verify the certificate offered by the remote peer which is (indirectly) signed by that root CA through a chain of trust, unless that root CA's certificate is pre-installed in the OS. So on Mikrotik, you always have to install the certificate(s) of the root CA(s) of each peer's certificate; on Windows, you may not have to if the root CA of your Mikrotik's certificate is pre-installed on Windows.

jerryroy1 · Thu Mar 12, 2020 9:43 pm

Hi Sindy, See attached.

Thanks for looking!

cert-names.png

sindy · Thu Mar 12, 2020 10:08 pm

There is no /ip ipsec identity item whatsoever, so no wonder it cannot be found.

jerryroy1 · Thu Mar 12, 2020 10:50 pm

Is this not it? It is in the file I uploaded.

/ip ipsec identity
add auth-method=digital-signature certificate=vpn.corp.company.net \
generate-policy=port-strict match-by=certificate mode-config=\
modeconfig.vpn.corp.company.net peer="peer my.ip.add.r" \
policy-template-group="group vpn.corp.company.net" \
remote-certificate=jroy@company.net remote-id=\
fqdn:jroy@company.net

sindy · Thu Mar 12, 2020 11:02 pm

Is this not it? It is in the file I uploaded.

Sorry, I had "search upwards" ticked in my Notepad

Set remote-id of the identity item to auto, otherwise it seems fine to me. I must admit it is not clear to me why that field is displayed at all given that match-by is set to certificate...

jerryroy1 · Fri Mar 13, 2020 12:38 am

IKE2.png

Changed but still same message about Identity not found for peer and it shows my private IP assigned via my AP on network

jerryroy1 · Fri Mar 13, 2020 3:24 am

IKE2-fail.png

Do I have something wrong in one of my certs?

So are both my ID and Remote ID set to Auto?

sindy · Fri Mar 13, 2020 9:38 pm

It is too early to say whether something is wrong with the certs. First of all, the Windows machine doesn't send its certificate in its ID_I field in AUTH 1 message:

log code

20:19:52 ipsec processing payload: ID_I 
20:19:52 ipsec ID_I (DER DN): CN=w10-450g6,C=cr,ST=,L=here,O=me,OU=mikrotik,SN=

nor does it send the certificate itself like in the correct case:

log code

20:19:52 ipsec payload seen: ID_I (90 bytes) 
20:19:52 ipsec payload seen: CERT (968 bytes) 
20:19:52 ipsec payload seen: CERTREQ (1185 bytes)

In your case, it says

log code

ID_I (ADDR4): 192.168...

and only sends a CERTREQ, not its own certificate.

So double-check your settings at Windows. The certificate for Windows must be imported as a machine one, not a user one. And the Windows machine must have the private key for the certificate, otherwise it cannot use it to authenticate itself to the peer.

It also depends on how you've created the certificate.

The proper way is that you create a request along with the private key on the Windows machine itself, then deliver the request to the CA which signs it, and then you import the signed certificate back to the Windows machine. So the private key never leaves the machine where it wil be used.

The usual way is that you create the request and the private key for the Windows machine on the Mikrotik acting as the CA, sign it there, and export the signed certificate there along with the private key, and import it along with the private key on the Windows machine. But to do this properly, you must export it as type=pkcs12 and you must use a passphrase, otherwise the private key is not exported to the file.

jerryroy1 · Fri Mar 13, 2020 11:44 pm

So double-check your settings at Windows. The certificate for Windows must be imported as a machine one, not a user one.

It was imported as a machine one.

The Windows Certificate was generate using the process from this tutorial

https://www.youtube.com/watch?v=fQokeBcrjdc

ALL Cert generation starts at 12:51 mark
Client cert generation starts at 16:20 mark
Client Cert install starts at 1:17:37 time mark

And the Windows machine must have the private key for the certificate, otherwise it cannot use it to authenticate itself to the peer.

Yes, This is the cert I generated on Mikrotik and installed on the Client. That is correct, right?

It also depends on how you've created the certificate. (see process I used outlined in video above).

The proper way is that you create a request along with the private key on the Windows machine itself, then deliver the request to the CA which signs it, and then you import the signed certificate back to the Windows machine. So the private key never leaves the machine where it will be used.

I did NOT do this process. I followed the process in this video

The usual way is that you create the request and the private key for the Windows machine on the Mikrotik acting as the CA, sign it there, and export the signed certificate there along with the private key, and import it along with the private key on the Windows machine. But to do this properly, you must export it as type=pkcs12 and you must use a passphrase, otherwise the private key is not exported to the file.

I believe that was the process I completed. Only thing is I did not create the cert on the windows machine.

sindy · Sat Mar 14, 2020 3:15 pm

It was imported as a machine one.
...
I believe that was the process I completed.

In that case, there are two possible reasons why Windows do not send the certificate and don't use it as ID_I. Either it's an issue in Tik's configuration and the Tik doesn't ask for it, or it's an issue at Windows side as the VPN is either misconfigured or the certificate contents is not applicable for the purpose.

So first, check in the log whether, shortly after
20:19:51 ipsec matched proposal:
there is also
20:19:51 ipsec adding payload: CERTREQ

If it's there, the issue is at Windows side; if it is not, it's something about the Mikrotik side, but I cannot see anything wrong in your config export.

Second, please post the output of /certificate print detail where name~"jroy" - maybe there is something wrong in the certificate properties?

The Windows Certificate was generate using the process from this tutorial
https://www.youtube.com/watch?v=fQokeBcrjdc
...
Client Cert install starts at 1:17:37 time mark

I still don't get why people need a 1:30' video for something that is described concisely on three screens here. But that's a generation problem I guess

jerryroy1 · Mon Mar 16, 2020 10:02 pm

20:19:51 ipsec matched proposal:
20:19:51 ipsec adding payload: CERTREQ

CERTREQ is there

Second, please post the output of /certificate print detail where name~"jroy"

See Attached>

sindy · Mon Mar 16, 2020 10:29 pm

The log reveals the public IPs so you may want to edit the previous post if that bothers you.

Looking at your certificates and the one which works on my Win10, the only significant difference I can spot is that mine has empty subject-alt-name. Another difference is that mine has a much longer key-usage list (digital-signature,key-encipherment,key-agreement,tls-client,ipsec-end-system,ipsec-tunnel), but as the manual only requires the tls-client item, I guess this is not the reason.

sindy · Tue Mar 17, 2020 12:10 am

Other than that, the first certificate you've created has subject-alt-name which seems formally incorrect to me (but I'm no expert here, I just suspect a comma-separated list of e-mail addresses is not a correct value of a subject-alt-name type e-mail), and I guess you've imported both to Windows; now Windows may have trouble to choose among them. If you look at post #4, you can see that Windows chooses a client certificate based on the signing CA, so if you have imported multiple ones signed by the same CA, it may cause trouble. Never tried doing so, so maybe the cert store automatically replaces the previously imported one signed by a given CA by the newly imported one signed by the same CA, but better check what the cert store actually contains, and tidy up if necessary.

jerryroy1 · Tue Mar 24, 2020 7:25 am

Sorry for the long delay in responding. Corona Virus be damned!

A Complete "Do OVER" I think the issue on Windows 10 is it does not install the Certificate in the correct Store. I need someone to validate this. In Any case, I have redone it completely on a different Mikrotik and now I can get the certs to work on Windows 7 but only with sha1. I am having another issue though that is evading me. I am unable to pass traffic from the Road Warrior (10.0.88.0/24 subnet) to the Lan side of the Mikrotik. 172.24.94.0/23. I have attached my files. Maybe you can have a peek? Another set of eyes is always a blessing. BTW, the Mikrotik documentation (which I went thru) is lacking so much detail, that it would be near impossible to get a working config. This is typical of their documentation over the years. It is not written to the right audience. Not bashing, just a different mindset.

Thanks for the support! You have been a Great Help!

sindy · Tue Mar 24, 2020 3:00 pm

A Complete "Do OVER" I think the issue on Windows 10 is it does not install the Certificate in the correct Store. I need someone to validate this.

someone can only validate it using a Teaviewer session; you can validate it the following way:

press the windows icon (Start button), start typing c e r t
you should get three suggestions for administration of certificates - for machines, users, and files. Run the one for machines (I cannot give you the exact names as my Windows' GUI lanuage is not English).
in there, two folders are of interest (as said these may not be their exact names in English-speaking WIndows 10):
- in "trusted root certification authorities->certificates", you should find the certificate of the CA using which you have generated the machine CA. Check it is there, and if yes, double-click it and check its properties.
- in "personal->certificates", you should find the certificate you've issued for the machine; double-click it and check that at the bottom of the leftmost tab, below the validity period, there is a key icon and a text saying you do have a private key needed to use this certificate; on the rightmost tab, check the "path to the certificate" - it must be signed by the one above.
in your particular case, it is quite likely that you have two "personal" (actually, machine) certificates, the one with the list of e-mail identities in subject-alt-name and the normal one. Get rid of the broken one, check the other one's properties as above.

I am unable to pass traffic from the Road Warrior (10.0.88.0/24 subnet) to the Lan side of the Mikrotik. 172.24.94.0/23.

The action=fasttrack-connection rule, the way it is created by default, does not care about the direction of the packet. So in chain=forward of your firewall, you accept packets from 10.0.88.0/24 before they can reach the action=fasttrack-connection rule, but as you've disabled the rule "defconf: accept out ipsec policy" (which says "accept whatever matches the outgoing direction of any IPsec policy"), the response packets from your LAN to the IPsec client do reach the fasttracking rule, which means subsequent packets of that connection stop being matched by IPsec policies (fasttracking actually means bypassing of many layers of packet handling in the kernel).

So as a quick check, just disable the action=fasttrack-connection rule (don't remove it). If it makes it possible to establish new connections from the road warrior to a machine in LAN (the old ones already caught by the action=fasttrack-connection rule are lost, forget about them), you can first re-enable the "defconf: accept out ipsec policy" rule, and then the action=fasttrack-connection one (the order is important).

If it does not help, you'll need to use packet sniffing to find out what happens. Windows firewall is the usual case, ignoring traffic not coming from the interface's own subnet.

Another set of eyes is always a blessing.

Exactly.

jerryroy1 · Tue Mar 24, 2020 8:17 pm

OK, doing what you suggested, I get traffic in one direction, I can see the bytes increasing from the 172.24.x.x (workstation on LAN of MT) to the 10.0.88.10 (Road Warrior IP) while pinging but still no response since it is not returning. Firewalls on windows systems both sides are completely disabled. The Split Tunnel settings I do not think are working. There is no route in the Road Warrior side routing Table. Also, the NAT's (see 0 and 1 below) have zero matches (I have tried two different methods based on recommendations for security).

[admin@MikroTik] > ip ipsec export
/ip ipsec mode-config
add address-pool=ike2-pool address-prefix-length=32 name="modeconf vpn.corp.mycompany.net" split-include=172.24.94.0/23 static-dns=10.0.88.1 system-dns=no
/ip ipsec policy group
add name="group vpn.corp.mycompany.net"
/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name="profile vpn.corp.mycompany.net"
/ip ipsec peer
add exchange-mode=ike2 local-address=xxx.xxx.237.254 name="peer vpn.corp.mycompany.net" passive=yes profile="profile vpn.corp.mycompany.net"
/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 lifetime=8h name="proposal vpn.corp.mycompany.net" pfs-group=none
/ip ipsec identity
add auth-method=digital-signature certificate=vpn.corp.mycompany.net generate-policy=port-strict match-by=certificate mode-config="modeconf vpn.corp.mycompany.net" peer=\
"peer vpn.corp.mycompany.net" policy-template-group="group vpn.corp.mycompany.net" remote-certificate=jroy@mycompany.net remote-id=user-fqdn:jroy@mycompany.net
/ip ipsec policy
add dst-address=10.0.88.0/24 group="group vpn.corp.mycompany.net" proposal="proposal vpn.corp.mycompany.net" src-address=0.0.0.0/0 template=yes
[admin@MikroTik] > ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP
0 E spi=0x73269C5 src-address=xxx.xxx.237.225:4500 dst-address=xxx.xxx.237.254:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="56c63dedc86d4b8084e418748bd30b02405bd808" enc-key="101c1db472c66c990df5a531207779bdb6ad2a857db6189f84babccfa0c5beec" add-lifetime=6h24m16s/8h21s replay=128

1 E spi=0x5A59911E src-address=xxx.xxx.237.254:4500 dst-address=xxx.xxx.237.225:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=256
auth-key="102fe8d53e12d16bb325244a142c6cf1b1cbe8c5" enc-key="2b041044e4995aa3ca213ef6168fe9ff0616b1e394b7a808b0fcc0ebf3422feb" addtime=mar/24/2020 10:43:03 expires-in=7h39m39s
add-lifetime=6h24m16s/8h21s current-bytes=14460 current-packets=241 replay=128
[admin@MikroTik] >

[admin@MikroTik] > ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; src-nat IKE2: 10.0.88.0/24 --> ether1
chain=srcnat action=src-nat to-addresses=174.46.237.254 src-address=10.0.88.0/24 out-interface=ether1 log=no log-prefix="" ipsec-policy=out,none

1 ;;; Masquerade IKE2: 10.0.88.0/24 --> WAN
chain=srcnat action=masquerade src-address=10.0.88.0/24 out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,none

2 chain=dstnat action=dst-nat to-addresses=172.24.95.164 to-ports=3389 protocol=tcp in-interface-list=WAN dst-port=3389 log=yes log-prefix=""

3 ;;; defconf: masquerade
chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,none
[admin@MikroTik] >

jerryroy1 · Tue Mar 24, 2020 8:49 pm

Under mode config, If I place a split of 0.0.0.0/0 I get traffic encrypted and decrypted and can ping from the LAN side of MT to Road Warrior = (RW) IP and get a response. The pings do not get a response from the RW side to the MT LAN because they are using default route instead of tunnel path. Any ideas?

jerryroy1 · Tue Mar 24, 2020 10:32 pm

Walked away for an hour or so and now traffic is passing in both directions and the route is in the routing table for the lan of the MT. Not sure what changed, but it is working. Going to see if I can duplicate the configuration on the original RB1100AHx2. Can I move CA certs and others between systems successfully?

sindy · Tue Mar 24, 2020 10:51 pm

Going to see if I can duplicate the configuration on the original RB1100AHx2. Can I move CA certs and others between systems successfully?

You can export the certificates along with their keys and import them to another Mikrotik, including the CA one. The certificates signed at one Mikrotik will not be marked as Issued once you import them to the other one although you'll import also the certificate of the CA you've used to sign them, so you will be unable to revoke them, but otherwise they will keep working.

Are you still using Win7 or has tidying up the cert store on Win10 helped?

jerryroy1 · Wed Mar 25, 2020 12:24 am

Set the modconf back to just the LAN subnet of the MT and was not able to ping in both directions for a bit, then it started to work again.

At the moment, Win7 environment. When I get to go back to office, I will have access to all Win10 systems. No chances to test and I delete dups until I do.

Thanks again for your support. You have been a wealth of knowledge and insight!

jerryroy1 · Fri Mar 27, 2020 5:11 am

Back in office. I am having issue importing certs exported from working system. BTW, passphrase does not accept spaces! I generated the certs with a Pass Phrase! not a password

The certs imported but do not have same values, for Example, the CA cert only shows Authority and Trusted. It is missing the "K" Private Key (I assume from no passphrase being supplied). All of them are actually. I tried to place double quotes around phrase but it fails.

sindy · Fri Mar 27, 2020 8:49 am

That must be something else, I've just tried to export a certificate using a passphrase with a space in it and both export and import worked flawlessly - from a command line, that is.

While exporting, if you specify type=pkcs12, the certificate is exported along with its private key and all the certificates in its chain of trust up to the issuing CA into a single .p12 file. If you don't, a default value of type=pem is used, which means that only the exported certificate itself is exported into a .crt file, and its private key is exported into a separate .key file. In both cases, the private key is only exported if a non-empty passphrase has been provided.

In the former case, you copy the .p12 file to the target machine and import it in a single step. In the latter case, in order to install the private key at the target machine, you have to import those files one by one, in any order. You have to specify the passphrase only when importing the .key one. Specifying it when importing the .crt one is requested but an empty passphrase doesn't prevent the file from being imported.

If you did use type=pkcs, I can imagine Winbox or WebFig may have an issue with passphrases with a space in them, but if it is the case, using just the substring of the passphrase, from the first character (included) up to the first space (not included) might allow you to import the key on the target machine.

For a .p12 file, you can copy it to a Windows machine, right-click it and choose the open (rather than the default install) action from the menu. If it is exported using a passphrase, you'll get an error message that it is passphrase-protected (and that will be it, no way to enter the passphrase); if it opens, it means the passphrase has not been used during export, and hence the private key didn't make it to the file.

jerryroy1 · Fri Apr 03, 2020 7:53 am

OK, the Long and winding road. LOL, It is finally working. I had to create all new certs on the 1100 with all the settings all over again to get this to work.

I finally have Windows 10 clients connecting with IKEv2 to the Mikrotik 1100AHx2. It still displays erratic behavior. Maybe just because I have tested so many different scenarios.

So what I am attempting to complete now (to put this to bed), I need the clients to connect to a subnet that is BEYOND the LAN of the MT. The LAN of the MT is 10.0.90.0/24 with .1 being my bridge interface on the MT and .2 being the "DMZ" interface of a Cisco ASA. I also have a bridge-loopback interface addressed with 10.0.88.1 on the MT that the IKEv2 clients establish the tunnel to after receiving an IP from the pool 10.0.88.10-10.0.89.254. The clients with a 10.0.88.0/23 ip addresses assigned from the pool can get all the way thru to 10.0.90.2 (ASA "dmz" interface. The subnet the clients need to access is 172.24.94.0/23 but I am having a hell of a time with the ASA rules. If it was just a router, I would be done. It looks like I have to have NAT from the DMZ (one to one or Pat, I am not completely sure with the ASA) to the "inside" of the ASA. The ASA has old code and the nat commands are some archaic syntax (I just hate ASA's, used to manage a few but it has been over 10 years). So I need the IKEv2 clients to be able to connect to resources sitting behind the ASA on it's "inside". I can get to the MT on 10.0.90.1 from the "inside" (ASA) subnet of 172.24.94.0/23. but cannot go other way.

Also, I believe the Ipsec ->"mode configs" -> "split include" has a bug. The entire 10.0.0.0/8 route gets added to the routing table on the client even when I don't have it in the split include. See attached "route print". Notice when I am connected and not connected with ipsec

route.jpg

client. It doesn't do that for other subnets I add.

split.jpg

route2.jpg

sindy · Fri Apr 03, 2020 9:51 am

I am having a hell of a time with the ASA rules.

Don't rely on getting help with a Cisco product on a 'Tik forum

Sometimes miracles happen, but better go search in the domestic woods of that beast.

I can get to the MT on 10.0.90.1 from the "inside" (ASA) subnet of 172.24.94.0/23. but cannot go other way.

At Mikrotik side, network debug is facilitated by means of /tool sniffer. So open the terminal window, make it as wide as your screen allows, and run /tool sniffer quick ip-address=172.24.94.0/23 there, then try pinging from that subnet to one of the clients' addresses, and (separately) try pinging from one of the clients to one of the machines in the 172.24.94.0/23 subnet. You'll see whether the ASA or the Tik are blocking your traffic.

If the packets from 172.24.94.0/23 do reach the ASA-facing interface of the Tik, the ASA doesn't block them at least in this direction. This way, you won't see them leaving the Tik even if they do as they get encrypted so they transmutate into IPsec transport packets with both IP addresses different, but there are more complex ways available to visualize (or at least count) them anyway - /ip firewall mangle add chain=postrouting action=xyz src-address=172.24.94.0/23 will just count them if you use passthrough instead of xyz, or log their IP header and other information if you use log instead of xyz. Just make sure first that this rule is the topmost one in its chain (mangle -> postrouting) - it should be given the firewall export you've posted.

If the sniff shows you the packets from the IPsec clients towards 172.24.94.0/23 at the ASA-facing interface, it is the ASA that blocks them, otherwise it's the Mikrotik rules.

If you plan that the IPsec clients would not only initiate connections to servers in 172.24.94.0/23, but also vice versa (i.e. if you want to be able to even ping the clients from 172.24.94.0/23), you have to add one rule to the top of the nat -> srcnat chain: action=accept ipsec-policy=out,ipsec. The actual IPsec processing (matching of packets to the traffic selectors of the policies, encryption of the matching ones and new routing of the resulting transport packets) is done after all the firewall handling; this rule ensures that the initial packet of each new connection will not reach the "masquerade all that goes out via WAN" rule, which otherwise changes its source address to the public one so it won't fit to the IPsec traffic selectors any more. All the subsequent packets of each connection inherit the NAT behaviour of the first one (as appropriate with regard to their direction), so the connections initiated by the IPsec clients are not affected by the absence of said rule.

The clients with a 10.0.88.0/23 ip addresses assigned from the pool
...
Also, I believe the Ipsec ->"mode configs" -> "split include" has a bug. The entire 10.0.0.0/8 route gets added to the routing table on the client even when I don't have it in the split include. See attached "route print". Notice when I am connected and not connected with ipsecroute.jpg client. It doesn't do that for other subnets I add. split.jpgroute2.jpg

There is a catch in Windows' VPN client. On W10, right-click the network icon in the status area, and choose network and internet settings rather than just open. In the "new GUI" window that opens, left-click change adapter settings - this will open the "old GUI" window with the physical and virtual network cards. Right-click the WAN miniport (IKEv2) one representing your connection and choose Properties from the menu. In the window that opens, choose the Networks tab. Double-click the "IP version 4 protocol" line (not the checkbox on it). Keep the IP address and DNS server on "auto" and press the only button there (probably called Details). Now you should see three tickboxes - use as a default gateway, forbid adding a class-based route, and automatic metric. I suppose use of a default gateway is unticked (correct), but forbid adding a class-based route is unticked as well, which causes that Windows finds the A, B or C class subnet to which the IP address assigned by the remote server belongs and adds a route to that subnet regardless what the routing table in Option 249 of the DHCPINFORM response (which Mikrotik populates with the subnet prefixes from the split-include list) says.

I have no clue whether Windows negotiate that class-based route using the IKEv2 traffic selector negotiation; if they do, /ip ipsec policy print where src-address~"10.0.0.0" should show you something. If this is the case, you can create a non-default /ipsec policy group item, and create a new /ip ipsec policy item with group referring to that group, template=yes, and src-address=172.24.94.0/23 dst-address=0.0.0.0/0, and set the policy-template-group of the corresponding /ip ipsec identity item to that group. This will make IPsec reject the traffic selector for 10.0.0.0/8 proposed by the Windows VPN client.

jerryroy1 · Fri May 15, 2020 4:53 am

Sindy,

Thanks for all your support. It has been a pleasure to work with you and I am so Thankful for your dedication to seeing this completed. It is all working as expected. I can't Thank You enough

I even got the Class based routing issue resolved. (see image)

class-based-win10.jpg

I hope I am in a position to help you out some time

Highest Regards!

jerryroy1 · Mon Jun 22, 2020 10:30 pm

OK, Now they are asking for 2 Factor authentication for users that have been assigned machine certificates. I am not sure where to start. I was sent this by MT support. https://www.notakey.com/products/ I would like to get some recommendations on a method that will not require a lot of support and maybe tie into Active directory on Windows?

(I am dreaming now) LOL

sindy · Mon Jun 22, 2020 10:53 pm

Although Microsoft AD is a RADIUS server, the description there indicates that the 2nd factor is based on information exchange with a mobile phone, so the RADIUS server must interact with Notakey's server which provide the communication with the mobile phone.

jerryroy1 · Sat Jun 27, 2020 12:09 am

OK, I currently have the Mikrotik on the DMZ interface of an ASA. What do you think would need to change to bring it in to the inside (LAN) of the ASA so it can get to the Notakey server? I assume I am going to need to create a new server certificate since the WAN IP of the MT will now be private? Just thinking out loud LOL

rozvald · Mon Aug 17, 2020 10:07 pm

Could someone please help me with the same / similar issue?
I've created a thread, as I'm struggling with iOS clients as well (Android works..)

For Win10 I've tried several settings, even changed names of the router to match the IDs in the certs, though nothing helped so far..

Thanks!

/viewtopic.php?t=164982

Mobistek · Thu Oct 01, 2020 3:41 pm

Hi there. So my situation is not so bad. I have configured IKEv2 server on mikrotik and issued certificates. Installed them on "Local Computer" in W10 and everything seems like is working fine BUT! ))
If you want to make another VPN IKEv2 connection on W10 OR you have some other installed certificates - it uses first that comes by alphabet. For example if I have certificates named client1 and another is client2 for 2 different connections W10 tries to use client1 on both. So of cause second connection gives an error of wrong certificate
So my question is HOW to make windows10 use right certificate for each connection?

sindy · Thu Oct 01, 2020 7:54 pm

So my question is HOW to make windows10 use right certificate for each connection?

viewtopic.php?t=135647#p668516

volkswagner · Mon Feb 15, 2021 9:41 pm

Hi. Did anyone find solution for the "An array that must contain at least one element is zero length." when you try to connect ?

For anyone landing here. I had this same issue.

Best to keep good notes, as I've been down this road before.
It's especially important for windows machines with multiple VPN connections.
Windows sucks a choosing a certificate and the only way to force it to
use a specific certificate is via powershell. The important thing to remember

Install the user certificated and add it as a machine certificate
Open MMC add certificate snap-in
find your CA cert (usually in "Trusted Root Certificate Authority" folder)
right click the CA > tasks > export
save it with a name you choose in a path you choose
use powershell command to point to this cert/list]

Again it's important to export the CA, as the command tells it to use certificate signed by....

Example powershell command:
Code: Select all
```
Set-VpnConnection -name home -MachineCertificateIssuerFilter "C:\Users\eric\homeVPN\homevpnCA.cer"
```

szymonzdziabek · Sun Feb 20, 2022 1:39 am

Hi. Did anyone find solution for the "An array that must contain at least one element is zero length." when you try to connect ?

Few things here in addition to volkswagner, 'cause probably this is the only place describing the issue in the whole Internet

. Today I've managed the problem on one of my PC. Using the certificate MMC snap-in (certmgr.mmc) I imported PKCS12 certificate to Personal -> Certificates. Then I moved (drag and drop) CA certificate to Trusted Root Certification Authorities -> Certificates and saved somewhere on a HDD CA certificate exported separately as PEM. After that I created IKE2 VPN connection using Powershell command:

Add-VpnConnection -Name "CONNECTION_NAME" -ServerAddress VPN_SERVER_IP -TunnelType Ikev2 -AuthenticationMethod MachineCertificate -EncryptionLevel Maximum -MachineCertificateIssuerFilter 'CA_CERTIFICATE_LOCATION.crt' -SplitTunneling

When I tried to connect I always got "An array (...)" error. What I did? Additionally installed certificates once more by right clik on them and chose install option. Now it works like a charm.

volkswagner · Fri Jun 30, 2023 5:08 pm

This thread has a lot of good stuff.

I wanted to add something that may be limited to Windows 11 (perhaps home version only).

With Windows 11, using all the same steps that worked for Windows 10, I was getting the following error in event log when attempting to connect:
error 13819 wrong certificate type

What seemed to fix it for me was changing the properties of the imported CA certificate.
Open MMC, file > add snap-in, choose certificates, then
right-click the CA certificate and select properties. Mine was automatically set to "enable all purposes for this certificate"
I changed the radio button to "Enable only the following purposes". I unchecked all purposes except "server authentication"
and "client authentication".

Bam... it worked!

log code

log code

log code

Who is online