When it comes to troubleshooting,
the single most valuable piece of information an administrator can obtain is
the error code encountered for the failed connection attempt.
Error codes can be found in multiple locations,
but the first and most important location to look for error
codes is in the event log on the endpoint.
Specifically,
we'll be looking in the application event log because that's
where the VPN client records its error messages.
The next place to look for error messages, specifically for user‑based
connections, is the event log on the NPS server.
Here, we're going to find valuable information for failed connection attempts,
specifically failed authentication attempts.
And while digging through the event log on the endpoint,
we'll ultimately reveal an error code for a failed VPN connection attempt.
It's much easier to use tools such as rasphone.exe,
which is a GUI utility used to launch VPN connections,
and rasdial.exe,
which is a command line tool to launch VPN connections because these
tools will surface the error message for a failed connection attempt
immediately without requiring you, the administrator,
to dig through the event logs and try to find the error code.
So this greatly simplifies and streamlines the process of
identifying these error messages for troubleshooting.
It's important to ensure that the NPS server has auditing enabled for
NPS events because without this option administrators are going to be
flying blind when it comes to troubleshooting.
It should be enabled by default,
but I can tell you from experience somehow it gets disabled.
You can view the auditing setting by using the command auditpol
/get /subcategory:"Network Policy Server".
And if NPS auditing is disabled somehow,
you can enable it quickly using the command auditpol.exe /set /subcategory:
"Network Policy Server" /success:enable /failure:enable.
This ensures that the NPS authentication events on the NPS server,
success or failure,
will be audited and recorded in the event log so that
we can use that for troubleshooting.
So some of the common error codes that we're going to cover
in the next demonstration are 809 This is probably one of
the most common error messages.
And honestly,
this is a very simple error message in that it means
that it's a failed connection attempt.
And specifically, it is a timeout error,
meaning the VPN client attempted to establish a connection,
and the VPN server just simply didn't respond.
The next is an 812.
And again, an 812 is really just couldn't authenticate for some reason,
and there are numerous reasons why a user might not be able to authenticate.
We'll go over many of those later.
13801 is specific to IKE v2,
and it simply means that the IKE authentication failed.
So there was some sort of problem presented in the IKE
authentication process. Sometimes certificates,
sometimes other things, but we'll take a look at those as well.
13806, again, is related to IKE v2 specifically, and this is always a
certificate issue of some sort on the endpoint, on the server,
variety of places it could be a problem with, but it is almost
certainly an issue with a certificate.
And then finally, I want to cover the dreaded 13868.
This is, again, an IKE v2‑specific message and it has
to do with an IPsec policy mismatch,
meaning the policy on the client does not match the policy on
the server, specifically the IPsec policy.
And in that scenario, the peers will not be able to
communicate if they cannot agree on IPsec security parameters, and it will bubble up that 13868 event.