Error 13801 - Ike-v2 authentication credentials are unacceptable



  • Hello,
    I'm using pfSense v2.2.4 and I did the setup as described on the following website.
    https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

    The self signed CA-root certificate is installed in the root authorities folder.

    Hostname: pfSense.domain.com

    Certificate config:
    Type: server
    CN:vpn.domain.com
    Alternative Names=> DNS:vpn.domain.com

    In Phase1
    ike v2
    My identifier=> Distinguished name: vpn
    Peer identifier=> Any

    The StrongSwan Android Client works without problems.
    The Win7 native client give me following error: Ike authentication credentials are unacceptable.

    If I deactivate the EKU Check I get the same error.

    Can anybody help?
    Thanks
    Greetings


  • Rebel Alliance Developer Netgate

    Did you add the usernames and passwords set for EAP on the Pre-Shared Keys tab in IPsec? If it got that far it's saying the user/pass didn't match.



  • Yes, I set the EAP Pre-Shared Keys.
    The connection with the Android strongSwan app works.



  • Hi there.

    I got the same problem. Configured everything like in this guide: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

    Connection from Ubuntu client works like a charm, but neither native Win7 nor iOS9 clients work.

    According to some googling, the error typically comes from on of the following causes:

    Error 13801 occurs on the client when:
    The certificate is expired.
    The trusted root for the certificate is not present on the client.
    The subject name of the certificate does not match the remote computer.
    The certificate does not have the required Enhanced Key Usage (EKU) values assigned.

    …but none of those are the case: All computers are synced with NTP, CA and server certificate valid for a few years. CA certificate imported to trusted Root CA storage. Correct CN= and DNS fields and both relevant EKU values (pfsense does this for some time now as I learned).

    Did you find a solution?
    Does anyone have hint where we could narrow down/debug the problem, so Windows and Apple clients would work too?

    Best regards,
    Kai


  • Rebel Alliance Developer Netgate

    I've gone through and tested (and re-tested) all of this over the last few weeks/month. It works fine if you follow the instructions on the wiki. If you import the client cert to the wrong place for the wrong type of IKEv2 it won't work (e.g. one kind needs to be in Machine certs, other in the user account). Same goes for OS X, you have to move the cert under System not login and make sure it's marked trusted. Though iOS 9 and OS X have other issues with IKEv2 that we patched up in 2.2.5. I'd start fresh on 2.2.5.



  • You were correct, I did miss that part in the tutorial, where it said "Select local machine".
    I just ran "certmgr.msc", which opens the certificate manager for the current user, which apparently doesn't help for IPSec…

    Btw, this is also stated here:
    https://wiki.strongswan.org/projects/strongswan/wiki/Win7Certs

    The screenshots (good for lazy people like me) there finally tipped me off.

    Win7 and Ubuntu now works. iOS should also work, going to try that next. (maybe via Profile Editor when manual config won't work or limit the available Ciphers)

    Thanks guys!



  • I got this error when I did not choose server certificate also when creating the server certificate!!!  :-(  took a while to trace.



  • I'm facing the same error, but I have validated that the certificate was created with the "server: Yes" option, and that it was installed in the MACHINE's repository, not just the USER's. I'm stuck :(



  • Well, I've managed to get it working, but…

    Turns out I had to import the cert into the PERSONAL folder. That's not viable for every single client that will ever use this connection. Is there a way to automate this? Or even better, is there a way to skip this import at all?
    ps: I'm using a publicly valid certificate.



  • @Reinaldo:

    Well, I've managed to get it working, but…

    Turns out I had to import the cert into the PERSONAL folder. That's not viable for every single client that will ever use this connection. Is there a way to automate this? Or even better, is there a way to skip this import at all?
    ps: I'm using a publicly valid certificate.

    Your certificate likely doesn't have the proper EKU for Windows to recognize it. The references to importing certificates on the client is for CA certs, not server certs, where a self-signed cert is used.



  • @cmb:

    Your certificate likely doesn't have the proper EKU for Windows to recognize it.

    I've confirmed that the cert does have the "server authentication" EKU (1.3.6.1.5.5.7.3.1)
    Isn't it the right one?

    @cmb:

    The references to importing certificates on the client is for CA certs, not server certs, where a self-signed cert is used.

    Yes, I do understand that. I imported the server cert instead because it was quicker, for testing purposes. The point is, I would like to cut off the need to import anything into a computer's "personal" cert folder, since the cert is already publicy trusted.