One more error we'll take a look at here is the 13868.
The 13868 error, once again, is an IPsec error.
So this would be exclusive to IKEv2 connections,
either device tunnel or user tunnel connections.
And a 13868 is very simply an IPsec policy mismatch.
So let me demonstrate that.
And you'll see here straightaway, you get an error 13868.
Let's take a look at that in the event log as well.
And there you have it, error code returned on failure is 13868.
To troubleshoot this,
what we need to do is make sure that the IPsec policy matches
on both the VPN server and the VPN client.
So we're going to start by running some commands to look at the
IPsec policy that's in place on the VPN client.
Unfortunately, there's no way to do this in the UI.
You must do this at the command line, specifically in PowerShell.
And so to do that, we're going to run the command, Get‑VpnConnection.
Then we'll supply the name of the connection.
In this case, my VPN profile is deployed in the all users profile,
so I'm going to run the AllUserConnection parameter.
And then I'm going to pipe that to the Select‑Object.
And I have to expand the property because there's
additional information in there.
And what we're looking for, the property specifically that we're looking for,
is IPsecCustomPolicy.
So there you have it.
And by the way, there's another way to get to this information.
I'll just show that to you right now.
You can actually just create a variable to store the object
and then look at its properties that way.
So we'll just create the variable here,
and here what we can do is just type the command vpn,
and we can look at the specific property by adding that name.
Same thing, only different, right?
Just a little different way to get to this information,
but whatever floats your boat here.
If you like to type more, you can do that.
Sometimes it's a little easier.
It really depends.
At the end of the day though,
what we want to do is make sure that these settings,
that these IPsec security parameters, match exactly those on the server.
And here you'll see that our
AuthenticationTransformConstants are using GCMAES128.
The same for the CipherTransform.
We're using DHGroup 14, and we're using SHA256 for our integrity check.
And for perfect forward secrecy here, we're using ECP256,
which is elliptic curve that provides a little bit better security.
And then finally for encryption, we're using GCMAES128 as well.
So let's go take a look at the settings that are configured on the VPN server.
So here we are on our VPN server,
and I'm going to run the command Get‑VpnServerConfiguration.
And the first thing you'll notice is that our
transform constants are using AES128.
The same goes for our encryption.
And again, this does not match.
Recall that we were using GCMACS128 on the client.
Also, Group14.
By the way, Group14 is the same as PFS2048, so those actually match.
So Diffie‑Hellman Group14 is a 2048‑bit RSA key.
But you'll notice that the PFS group is also different here.
We were using ECP256 on the client, and here we're using PFS2048.
So in this scenario,
we would need to reconfigure the server to ensure
that all of the parameters line up.
There are two scenarios in which you would receive a 13868 error
message and still have the policies align exactly.
So let me be clear.
You could have the policies match perfectly on the VPN server and the
VPN client and still receive an IPsec policy mismatch error basically
because of a weird configuration issue on NPS.
So here we are on our NPS server.
So if we take a look at our AlwaysOn VPN policy,
we go to the Settings,
there is a settings here called Encryption. And you'll see that there's a bunch
of these are set. And in fact, it's kind of scary looking because it says it
supports no encryption or even some of these very poor‑quality encryptions.
Administrators may mistakenly think that disabling all of these will improve
security, and perhaps it might.
I don't know. The bottom line is is that in this scenario
with only 128‑bit MPPE encryption defined,
you will actually get an IPsec policy mismatch.
At a minimum, you must have strong enabled. I honestly don't have an
answer for you as to why specifically this is required.
But it's important to understand that this does not
degrade your security much at all, if any.
And the reason for that is that this is the inner encryption, or
this is basically the encryption for the point‑to‑point protocol
that is actually used within IPsec.
So this stream here is well protected with AES128 or GCMAES128.
And so this is rather inconsequential from a security standpoint. But just
ensure that if you've unchecked any of these other settings here,
you have to have a minimum of strong encryption and
strongest encryption enabled for that to work.
And one final scenario that could yield the same results.
Again,
exact identical policies on the endpoint and on the server. You can still
get a 13868 error message IPsec policy mismatch if someone has added this
particular registry key to the endpoint or the server. Now what this
particular registry key does, I'm not entirely certain, but I have seen
some blog posts from many, many years ago, these are old,
ancient blog posts, that talk about security hardening, and
they tell you to enable this feature.
This will override the IPsec policy settings on the server or on the
client and could result, again, in this 13868.
So if your policies match identically and you're still getting this error,
have a look at this registry key and make sure that it's not set on the VPN server or on the VPN client.