1
00:00:00,440 --> 00:00:04,270
So herein lies a challenge. It is that just because the VPN

2
00:00:04,270 --> 00:00:09,800
server is responding on TCP port 443 does not necessarily

3
00:00:09,800 --> 00:00:11,670
mean that everything is correct.

4
00:00:11,670 --> 00:00:13,330
In other words, you could run this test.

5
00:00:13,330 --> 00:00:16,740
It could come back as positive or as valid.

6
00:00:16,740 --> 00:00:21,410
But if there's a configuration error, the VPN still may fail to connect.

7
00:00:21,410 --> 00:00:22,150
For example,

8
00:00:22,150 --> 00:00:25,470
some common failure scenarios that I see are that the NAT

9
00:00:25,470 --> 00:00:28,080
rule is configured incorrectly and it's sending the traffic

10
00:00:28,080 --> 00:00:30,040
to just a regular web server.

11
00:00:30,040 --> 00:00:34,030
Or I have also seen where the management interface,

12
00:00:34,030 --> 00:00:36,870
which is an HTTPS management interface on the firewall,

13
00:00:36,870 --> 00:00:40,900
is actually responding instead of the VPN server.

14
00:00:40,900 --> 00:00:43,650
And there's a good way to test that using PowerShell.

15
00:00:43,650 --> 00:00:47,520
And to do that, what you'll need to do is run this command.

16
00:00:47,520 --> 00:00:49,840
It's Invoke‑Web‑Request,

17
00:00:49,840 --> 00:00:52,960
and you'll see that this is a rather complex command here.

18
00:00:52,960 --> 00:00:56,790
But bottom line is copy this command. And if you'll

19
00:00:56,790 --> 00:01:00,190
notice that I'm using vpn.example.net,

20
00:01:00,190 --> 00:01:03,120
you'll need to replace this with your public host name.

21
00:01:03,120 --> 00:01:07,920
But the rest of that path should be exactly as it's defined here,

22
00:01:07,920 --> 00:01:11,270
and make sure you use basic parsing as well.

23
00:01:11,270 --> 00:01:14,410
So when you run this command, I'm just going to paste it in here.

24
00:01:14,410 --> 00:01:17,410
When you run this command and hit Enter, what you

25
00:01:17,410 --> 00:01:20,780
should see is an error 401 Unauthorized.

26
00:01:20,780 --> 00:01:24,250
This would give you a good indication that the VPN server is

27
00:01:24,250 --> 00:01:27,790
actually responding because that's the expected response when you

28
00:01:27,790 --> 00:01:31,790
just simply send an HTTP GET to the server.

29
00:01:31,790 --> 00:01:34,660
So if it returns something else, and, for example,

30
00:01:34,660 --> 00:01:38,910
let's say it was the NAT rule forwarded the traffic to like a

31
00:01:38,910 --> 00:01:42,340
common web server and not the VPN server, again,

32
00:01:42,340 --> 00:01:45,640
Test‑NetConnection will report TCP port responding,

33
00:01:45,640 --> 00:01:49,940
but you will also get a very different response.

34
00:01:49,940 --> 00:01:54,750
And what you'll see here is this server returns a 503 Unavailable.

35
00:01:54,750 --> 00:01:58,550
This would be a strong indication that the correct resource

36
00:01:58,550 --> 00:02:01,060
is not actually responding because, again,

37
00:02:01,060 --> 00:02:03,540
the VPN server is going to respond with a 401

38
00:02:03,540 --> 00:02:06,340
Unauthorized, any other normal web service.

39
00:02:06,340 --> 00:02:09,340
Or if it's the firewall's web management console,

40
00:02:09,340 --> 00:02:12,990
it will respond with something else, and in this case a 503. That

41
00:02:12,990 --> 00:02:15,820
tells me I still need to investigate the networking and make sure

42
00:02:15,820 --> 00:02:24,000
that my firewall is configured correctly and delivering the traffic to the VPN server as expected.