The next error message we'll investigate is the 13806.
And much like the 13801, this is exclusive to IPsec and specifically IKEv2.
Now this could be caused by any number of things.
The most common is a certificate missing on the
endpoint for device tunnel connections.
If there's not a certificate in the local computer certificate store for the
device, then obviously that authentication is going to fail.
We can validate this by opening the local computer certificate store
and ensuring that we have a certificate that was issued to the device
that includes the client authentication EKU.
It's also possible that the certificate could simply be
missing from the VPN server itself.
So here,
once again, we want to make sure that we have our IPsec certificate
issued to the VPN server, and we also want to make sure that it is
valid and trusted. And once again,
much like the previous scenario with the 13801, if
there's issues with certificate revocation,
if there's issues with the certification path, and any of these
certificates are missing, that can be problematic as well.
The last point I want to make about this is that there's a security
option that you can enable, and we did this in an earlier lab where you
can restrict which certificates are used or trusted for IPsec
connections with IKEv2. The command to view that and set it is
Get‑VpnAuthProtocol. And here you'll see we've defined the value of
RootCertificateNameToAccept. And in this scenario, I have configured the
incorrect certificate.
I have defined a global or a public CA as the root of
trust for my IPsec connections, which is incorrect.
I'm issuing certificates to my endpoints for IPsec from my internal private CA.
So this is actually incorrect. So this would result in the 13806 failure as well.