1
00:00:03,540 --> 00:00:06,000
Now I'll demonstrate some of the techniques that I use when

2
00:00:06,000 --> 00:00:10,240
troubleshooting common AlwaysOn VPN‑related error messages.

3
00:00:10,240 --> 00:00:12,250
So here we are on a Windows 10 client.

4
00:00:12,250 --> 00:00:14,660
It's been provisioned for AlwaysOn VPN,

5
00:00:14,660 --> 00:00:16,970
both the device tunnel and the user tunnel.

6
00:00:16,970 --> 00:00:17,680
And in this case,

7
00:00:17,680 --> 00:00:20,640
the client is outside of my corporate network or

8
00:00:20,640 --> 00:00:22,620
outside of my internal trusted network.

9
00:00:22,620 --> 00:00:26,660
So it's on the internet and it is unable to establish a connection.

10
00:00:26,660 --> 00:00:28,250
And so to demonstrate this,

11
00:00:28,250 --> 00:00:31,810
the first thing I'm going to do is open up the event log,

12
00:00:31,810 --> 00:00:35,260
and I'm going to expand the Windows logs.

13
00:00:35,260 --> 00:00:37,100
Go to the Application log.

14
00:00:37,100 --> 00:00:41,990
And what I'm looking for here is an error from the event source RasClient.

15
00:00:41,990 --> 00:00:43,520
So I'm going to double‑click on this,

16
00:00:43,520 --> 00:00:47,030
and you'll see here that this is an error 809.

17
00:00:47,030 --> 00:00:49,570
Instead of digging through the event log,

18
00:00:49,570 --> 00:00:49,930
however,

19
00:00:49,930 --> 00:00:53,100
you can actually get some tools to just tell you simply

20
00:00:53,100 --> 00:00:55,120
what the error code is immediately.

21
00:00:55,120 --> 00:00:57,480
And there's two tools for this that I want to show you.

22
00:00:57,480 --> 00:01:00,180
And the first is a GUI tool or a graphical tool,

23
00:01:00,180 --> 00:01:05,130
and this one is called rasphone.exe, and you just simply run that.

24
00:01:05,130 --> 00:01:09,410
And here what you see is a drop‑down list of all of the VPN connections,

25
00:01:09,410 --> 00:01:12,980
and I'm going to test my AlwaysOn VPN user tunnel here.

26
00:01:12,980 --> 00:01:14,890
So we'll choose Connect,

27
00:01:14,890 --> 00:01:18,730
and you'll see here that it returns the error message

28
00:01:18,730 --> 00:01:20,220
right in front of the administrator.

29
00:01:20,220 --> 00:01:23,150
So you don't have to really go digging through the event log

30
00:01:23,150 --> 00:01:25,100
unless you're looking for something historical.

31
00:01:25,100 --> 00:01:28,950
But at the end of the day, this presents you immediately with the error message.

32
00:01:28,950 --> 00:01:32,870
Another option is to use a command line tool called rasdial.exe.

33
00:01:32,870 --> 00:01:34,350
And to do that,

34
00:01:34,350 --> 00:01:38,410
you'll type in rasdial.exe and then the name of the VPN

35
00:01:38,410 --> 00:01:43,940
connection that you want to initiate.

36
00:01:43,940 --> 00:01:45,680
And essentially, it's the same thing, only different.

37
00:01:45,680 --> 00:01:47,760
It returns the same access error.

38
00:01:47,760 --> 00:01:49,060
We have an 809 error.

39
00:01:49,060 --> 00:01:52,840
So let's press on with troubleshooting our error 809.

40
00:01:52,840 --> 00:01:55,210
So the first thing that I want to do is I want to open up

41
00:01:55,210 --> 00:01:57,320
our PowerShell command window here.

42
00:01:57,320 --> 00:02:00,150
And it probably goes without saying the first thing we need to

43
00:02:00,150 --> 00:02:02,940
validate is if we have access to the internet.

44
00:02:02,940 --> 00:02:06,890
You can very easily just open a browser, browse to your favorite website.

45
00:02:06,890 --> 00:02:09,260
But I like to do this at the command line,

46
00:02:09,260 --> 00:02:15,440
and the PowerShell command to do that is simply Test‑NetConnection.

47
00:02:15,440 --> 00:02:16,560
So when you run this command,

48
00:02:16,560 --> 00:02:19,590
it goes out to a site hosted by Microsoft and performs some

49
00:02:19,590 --> 00:02:22,240
very quick rudimentary validation checks.

50
00:02:22,240 --> 00:02:25,090
But ultimately, you know you have access to the internet.

51
00:02:25,090 --> 00:02:27,020
Our ping probe was successful,

52
00:02:27,020 --> 00:02:30,970
and you can see that we've got a fairly low‑latency connection here,

53
00:02:30,970 --> 00:02:32,620
which is fantastic.

54
00:02:32,620 --> 00:02:36,700
Now, next we need to find out, okay, well we have internet access.

55
00:02:36,700 --> 00:02:39,260
Can I get to my VPN server?

56
00:02:39,260 --> 00:02:43,920
Now if the VPN server is supporting SSTP connections,

57
00:02:43,920 --> 00:02:46,420
this is actually pretty easy to validate.

58
00:02:46,420 --> 00:02:49,250
So I want to demonstrate those techniques now.

59
00:02:49,250 --> 00:02:52,860
So I'm actually going to run the Test‑NetConnection command once more,

60
00:02:52,860 --> 00:02:57,360
but now I'm going to be more specific and provide the host and

61
00:02:57,360 --> 00:03:02,640
the port that I want to check connectivity for.

62
00:03:02,640 --> 00:03:06,320
And so here I've supplied the public hostname of my VPN server,

63
00:03:06,320 --> 00:03:12,150
as well as port 443, which is, of course, the port that SSTP is listening on.

64
00:03:12,150 --> 00:03:16,620
And of course, you can see here that my connection has failed.

65
00:03:16,620 --> 00:03:19,160
What I'm looking for in the output of this command,

66
00:03:19,160 --> 00:03:21,650
however, is to make sure that, one,

67
00:03:21,650 --> 00:03:27,040
my remote address or my public IP address is indeed correct.

68
00:03:27,040 --> 00:03:29,730
And one of the things you'll notice here is that my ping was

69
00:03:29,730 --> 00:03:33,100
actually successful so I was able to ping this resource but it

70
00:03:33,100 --> 00:03:37,040
is not responding on TCP port 443.

71
00:03:37,040 --> 00:03:40,000
So this tells me I probably have a good network path

72
00:03:40,000 --> 00:03:43,390
at least to the VPN server or, in this case,

73
00:03:43,390 --> 00:03:47,490
the firewall hosting the public IPv4 address for this server.

74
00:03:47,490 --> 00:03:53,690
But bottom line is is that if it's not responding to TCP 443, why is that?

75
00:03:53,690 --> 00:03:54,570
So at this point.

76
00:03:54,570 --> 00:03:58,590
I would probably want to look at the configuration of my edge firewall.

77
00:03:58,590 --> 00:04:02,740
Make sure that the public IP address is assigned to the correct interface,

78
00:04:02,740 --> 00:04:05,450
that it's listening on port 443,

79
00:04:05,450 --> 00:04:08,670
that the access control lists are configured correctly,

80
00:04:08,670 --> 00:04:13,040
the firewall rules on the firewall, and that the NAT rule is configured as well.

81
00:04:13,040 --> 00:04:15,540
This is probably where you're going to need to go into the

82
00:04:15,540 --> 00:04:18,460
firewall logs and enable logging there,

83
00:04:18,460 --> 00:04:21,240
make sure that the traffic is passing and so forth.

84
00:04:21,240 --> 00:04:24,830
If it's being denied, you can address that in the firewall rules there.

85
00:04:24,830 --> 00:04:26,120
If it's being allowed,

86
00:04:26,120 --> 00:04:28,600
then you'll probably want to investigate and see well if

87
00:04:28,600 --> 00:04:30,420
the firewall is passing the traffic,

88
00:04:30,420 --> 00:04:35,180
where specifically is it passing it to? And in this case, you may end up

89
00:04:35,180 --> 00:04:39,480
having to take network traces. And honestly, I love taking network traces

90
00:04:39,480 --> 00:04:41,750
in these scenarios because as the saying goes,

91
00:04:41,750 --> 00:04:43,090
the packets don't lie.

92
00:04:43,090 --> 00:04:46,630
And in this case, you would run a network trace on the client,

93
00:04:46,630 --> 00:04:51,870
on the endpoint and on the VPN server, and then you would run this test and

94
00:04:51,870 --> 00:04:54,400
then you should be able to see this traffic. And if you don't,

95
00:04:54,400 --> 00:05:02,000
then you'll have to kind of back up and try to find out where specifically that traffic was being dropped.