Now I'll demonstrate some of the techniques that I use when
troubleshooting common AlwaysOn VPN‑related error messages.
So here we are on a Windows 10 client.
It's been provisioned for AlwaysOn VPN,
both the device tunnel and the user tunnel.
And in this case,
the client is outside of my corporate network or
outside of my internal trusted network.
So it's on the internet and it is unable to establish a connection.
And so to demonstrate this,
the first thing I'm going to do is open up the event log,
and I'm going to expand the Windows logs.
Go to the Application log.
And what I'm looking for here is an error from the event source RasClient.
So I'm going to double‑click on this,
and you'll see here that this is an error 809.
Instead of digging through the event log,
however,
you can actually get some tools to just tell you simply
what the error code is immediately.
And there's two tools for this that I want to show you.
And the first is a GUI tool or a graphical tool,
and this one is called rasphone.exe, and you just simply run that.
And here what you see is a drop‑down list of all of the VPN connections,
and I'm going to test my AlwaysOn VPN user tunnel here.
So we'll choose Connect,
and you'll see here that it returns the error message
right in front of the administrator.
So you don't have to really go digging through the event log
unless you're looking for something historical.
But at the end of the day, this presents you immediately with the error message.
Another option is to use a command line tool called rasdial.exe.
And to do that,
you'll type in rasdial.exe and then the name of the VPN
connection that you want to initiate.
And essentially, it's the same thing, only different.
It returns the same access error.
We have an 809 error.
So let's press on with troubleshooting our error 809.
So the first thing that I want to do is I want to open up
our PowerShell command window here.
And it probably goes without saying the first thing we need to
validate is if we have access to the internet.
You can very easily just open a browser, browse to your favorite website.
But I like to do this at the command line,
and the PowerShell command to do that is simply Test‑NetConnection.
So when you run this command,
it goes out to a site hosted by Microsoft and performs some
very quick rudimentary validation checks.
But ultimately, you know you have access to the internet.
Our ping probe was successful,
and you can see that we've got a fairly low‑latency connection here,
which is fantastic.
Now, next we need to find out, okay, well we have internet access.
Can I get to my VPN server?
Now if the VPN server is supporting SSTP connections,
this is actually pretty easy to validate.
So I want to demonstrate those techniques now.
So I'm actually going to run the Test‑NetConnection command once more,
but now I'm going to be more specific and provide the host and
the port that I want to check connectivity for.
And so here I've supplied the public hostname of my VPN server,
as well as port 443, which is, of course, the port that SSTP is listening on.
And of course, you can see here that my connection has failed.
What I'm looking for in the output of this command,
however, is to make sure that, one,
my remote address or my public IP address is indeed correct.
And one of the things you'll notice here is that my ping was
actually successful so I was able to ping this resource but it
is not responding on TCP port 443.
So this tells me I probably have a good network path
at least to the VPN server or, in this case,
the firewall hosting the public IPv4 address for this server.
But bottom line is is that if it's not responding to TCP 443, why is that?
So at this point.
I would probably want to look at the configuration of my edge firewall.
Make sure that the public IP address is assigned to the correct interface,
that it's listening on port 443,
that the access control lists are configured correctly,
the firewall rules on the firewall, and that the NAT rule is configured as well.
This is probably where you're going to need to go into the
firewall logs and enable logging there,
make sure that the traffic is passing and so forth.
If it's being denied, you can address that in the firewall rules there.
If it's being allowed,
then you'll probably want to investigate and see well if
the firewall is passing the traffic,
where specifically is it passing it to? And in this case, you may end up
having to take network traces. And honestly, I love taking network traces
in these scenarios because as the saying goes,
the packets don't lie.
And in this case, you would run a network trace on the client,
on the endpoint and on the VPN server, and then you would run this test and
then you should be able to see this traffic. And if you don't,
then you'll have to kind of back up and try to find out where specifically that traffic was being dropped.