1 00:00:02,040 --> 00:00:06,300 One more error we'll take a look at here is the 13868. 2 00:00:06,300 --> 00:00:10,630 The 13868 error, once again, is an IPsec error. 3 00:00:10,630 --> 00:00:13,840 So this would be exclusive to IKEv2 connections, 4 00:00:13,840 --> 00:00:16,100 either device tunnel or user tunnel connections. 5 00:00:16,100 --> 00:00:21,350 And a 13868 is very simply an IPsec policy mismatch. 6 00:00:21,350 --> 00:00:23,250 So let me demonstrate that. 7 00:00:23,250 --> 00:00:28,130 And you'll see here straightaway, you get an error 13868. 8 00:00:28,130 --> 00:00:31,420 Let's take a look at that in the event log as well. 9 00:00:31,420 --> 00:00:36,540 And there you have it, error code returned on failure is 13868. 10 00:00:36,540 --> 00:00:38,430 To troubleshoot this, 11 00:00:38,430 --> 00:00:41,790 what we need to do is make sure that the IPsec policy matches 12 00:00:41,790 --> 00:00:44,880 on both the VPN server and the VPN client. 13 00:00:44,880 --> 00:00:47,750 So we're going to start by running some commands to look at the 14 00:00:47,750 --> 00:00:51,140 IPsec policy that's in place on the VPN client. 15 00:00:51,140 --> 00:00:53,790 Unfortunately, there's no way to do this in the UI. 16 00:00:53,790 --> 00:00:57,120 You must do this at the command line, specifically in PowerShell. 17 00:00:57,120 --> 00:01:03,140 And so to do that, we're going to run the command, Get‑VpnConnection. 18 00:01:03,140 --> 00:01:05,250 Then we'll supply the name of the connection. 19 00:01:05,250 --> 00:01:09,920 In this case, my VPN profile is deployed in the all users profile, 20 00:01:09,920 --> 00:01:14,190 so I'm going to run the AllUserConnection parameter. 21 00:01:14,190 --> 00:01:18,240 And then I'm going to pipe that to the Select‑Object. 22 00:01:18,240 --> 00:01:21,510 And I have to expand the property because there's 23 00:01:21,510 --> 00:01:23,320 additional information in there. 24 00:01:23,320 --> 00:01:26,490 And what we're looking for, the property specifically that we're looking for, 25 00:01:26,490 --> 00:01:30,140 is IPsecCustomPolicy. 26 00:01:30,140 --> 00:01:30,950 So there you have it. 27 00:01:30,950 --> 00:01:33,560 And by the way, there's another way to get to this information. 28 00:01:33,560 --> 00:01:35,080 I'll just show that to you right now. 29 00:01:35,080 --> 00:01:37,740 You can actually just create a variable to store the object 30 00:01:37,740 --> 00:01:39,740 and then look at its properties that way. 31 00:01:39,740 --> 00:01:43,110 So we'll just create the variable here, 32 00:01:43,110 --> 00:01:48,020 and here what we can do is just type the command vpn, 33 00:01:48,020 --> 00:01:53,440 and we can look at the specific property by adding that name. 34 00:01:53,440 --> 00:01:54,720 Same thing, only different, right? 35 00:01:54,720 --> 00:01:56,300 Just a little different way to get to this information, 36 00:01:56,300 --> 00:01:58,010 but whatever floats your boat here. 37 00:01:58,010 --> 00:02:00,390 If you like to type more, you can do that. 38 00:02:00,390 --> 00:02:01,560 Sometimes it's a little easier. 39 00:02:01,560 --> 00:02:02,500 It really depends. 40 00:02:02,500 --> 00:02:03,790 At the end of the day though, 41 00:02:03,790 --> 00:02:06,060 what we want to do is make sure that these settings, 42 00:02:06,060 --> 00:02:11,730 that these IPsec security parameters, match exactly those on the server. 43 00:02:11,730 --> 00:02:13,020 And here you'll see that our 44 00:02:13,020 --> 00:02:18,050 AuthenticationTransformConstants are using GCMAES128. 45 00:02:18,050 --> 00:02:19,460 The same for the CipherTransform. 46 00:02:19,460 --> 00:02:27,210 We're using DHGroup 14, and we're using SHA256 for our integrity check. 47 00:02:27,210 --> 00:02:30,620 And for perfect forward secrecy here, we're using ECP256, 48 00:02:30,620 --> 00:02:34,690 which is elliptic curve that provides a little bit better security. 49 00:02:34,690 --> 00:02:39,490 And then finally for encryption, we're using GCMAES128 as well. 50 00:02:39,490 --> 00:02:43,440 So let's go take a look at the settings that are configured on the VPN server. 51 00:02:43,440 --> 00:02:45,020 So here we are on our VPN server, 52 00:02:45,020 --> 00:02:49,540 and I'm going to run the command Get‑VpnServerConfiguration. 53 00:02:49,540 --> 00:02:51,740 And the first thing you'll notice is that our 54 00:02:51,740 --> 00:02:55,730 transform constants are using AES128. 55 00:02:55,730 --> 00:02:57,800 The same goes for our encryption. 56 00:02:57,800 --> 00:02:59,590 And again, this does not match. 57 00:02:59,590 --> 00:03:04,240 Recall that we were using GCMACS128 on the client. 58 00:03:04,240 --> 00:03:05,500 Also, Group14. 59 00:03:05,500 --> 00:03:11,520 By the way, Group14 is the same as PFS2048, so those actually match. 60 00:03:11,520 --> 00:03:15,440 So Diffie‑Hellman Group14 is a 2048‑bit RSA key. 61 00:03:15,440 --> 00:03:18,450 But you'll notice that the PFS group is also different here. 62 00:03:18,450 --> 00:03:24,320 We were using ECP256 on the client, and here we're using PFS2048. 63 00:03:24,320 --> 00:03:25,510 So in this scenario, 64 00:03:25,510 --> 00:03:28,960 we would need to reconfigure the server to ensure 65 00:03:28,960 --> 00:03:31,240 that all of the parameters line up. 66 00:03:31,240 --> 00:03:35,030 There are two scenarios in which you would receive a 13868 error 67 00:03:35,030 --> 00:03:39,380 message and still have the policies align exactly. 68 00:03:39,380 --> 00:03:40,460 So let me be clear. 69 00:03:40,460 --> 00:03:44,820 You could have the policies match perfectly on the VPN server and the 70 00:03:44,820 --> 00:03:49,760 VPN client and still receive an IPsec policy mismatch error basically 71 00:03:49,760 --> 00:03:53,190 because of a weird configuration issue on NPS. 72 00:03:53,190 --> 00:03:55,640 So here we are on our NPS server. 73 00:03:55,640 --> 00:03:58,280 So if we take a look at our AlwaysOn VPN policy, 74 00:03:58,280 --> 00:03:59,530 we go to the Settings, 75 00:03:59,530 --> 00:04:03,490 there is a settings here called Encryption. And you'll see that there's a bunch 76 00:04:03,490 --> 00:04:07,070 of these are set. And in fact, it's kind of scary looking because it says it 77 00:04:07,070 --> 00:04:11,740 supports no encryption or even some of these very poor‑quality encryptions. 78 00:04:11,740 --> 00:04:16,950 Administrators may mistakenly think that disabling all of these will improve 79 00:04:16,950 --> 00:04:19,390 security, and perhaps it might. 80 00:04:19,390 --> 00:04:22,730 I don't know. The bottom line is is that in this scenario 81 00:04:22,730 --> 00:04:27,640 with only 128‑bit MPPE encryption defined, 82 00:04:27,640 --> 00:04:30,820 you will actually get an IPsec policy mismatch. 83 00:04:30,820 --> 00:04:35,220 At a minimum, you must have strong enabled. I honestly don't have an 84 00:04:35,220 --> 00:04:38,130 answer for you as to why specifically this is required. 85 00:04:38,130 --> 00:04:40,300 But it's important to understand that this does not 86 00:04:40,300 --> 00:04:43,240 degrade your security much at all, if any. 87 00:04:43,240 --> 00:04:46,670 And the reason for that is that this is the inner encryption, or 88 00:04:46,670 --> 00:04:50,170 this is basically the encryption for the point‑to‑point protocol 89 00:04:50,170 --> 00:04:53,140 that is actually used within IPsec. 90 00:04:53,140 --> 00:04:58,990 So this stream here is well protected with AES128 or GCMAES128. 91 00:04:58,990 --> 00:05:03,460 And so this is rather inconsequential from a security standpoint. But just 92 00:05:03,460 --> 00:05:06,910 ensure that if you've unchecked any of these other settings here, 93 00:05:06,910 --> 00:05:10,020 you have to have a minimum of strong encryption and 94 00:05:10,020 --> 00:05:14,040 strongest encryption enabled for that to work. 95 00:05:14,040 --> 00:05:17,220 And one final scenario that could yield the same results. 96 00:05:17,220 --> 00:05:17,810 Again, 97 00:05:17,810 --> 00:05:22,430 exact identical policies on the endpoint and on the server. You can still 98 00:05:22,430 --> 00:05:28,230 get a 13868 error message IPsec policy mismatch if someone has added this 99 00:05:28,230 --> 00:05:32,920 particular registry key to the endpoint or the server. Now what this 100 00:05:32,920 --> 00:05:37,930 particular registry key does, I'm not entirely certain, but I have seen 101 00:05:37,930 --> 00:05:42,210 some blog posts from many, many years ago, these are old, 102 00:05:42,210 --> 00:05:45,570 ancient blog posts, that talk about security hardening, and 103 00:05:45,570 --> 00:05:47,490 they tell you to enable this feature. 104 00:05:47,490 --> 00:05:51,970 This will override the IPsec policy settings on the server or on the 105 00:05:51,970 --> 00:05:55,680 client and could result, again, in this 13868. 106 00:05:55,680 --> 00:05:59,660 So if your policies match identically and you're still getting this error, 107 00:05:59,660 --> 00:06:07,000 have a look at this registry key and make sure that it's not set on the VPN server or on the VPN client.