Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Error 13801 - Ike-v2 authentication credentials are unacceptable

    Scheduled Pinned Locked Moved IPsec
    11 Posts 6 Posters 28.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      muehle
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the šŸ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • M
          muehle
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • K
            kais
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              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.

              Remember: Upvote with the šŸ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • K
                kais
                last edited by

                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!

                1 Reply Last reply Reply Quote 0
                • K
                  kapara
                  last edited by

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

                  Skype ID:Ā  Marinhd

                  1 Reply Last reply Reply Quote 0
                  • R
                    reinaldo.gomes
                    last edited by

                    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 :(

                    1 Reply Last reply Reply Quote 0
                    • R
                      reinaldo.gomes
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • R
                          reinaldo.gomes
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.