1 00:00:02,140 --> 00:00:05,920 Troubleshooting 809 errors when using IKEv2 introduces 2 00:00:05,920 --> 00:00:08,070 some new and interesting challenges. 3 00:00:08,070 --> 00:00:11,760 First, IKEv2 uses UDP for communication, 4 00:00:11,760 --> 00:00:15,480 meaning we can't use our Test‑NetConnection PowerShell 5 00:00:15,480 --> 00:00:18,640 command because that fundamentally uses TCP. 6 00:00:18,640 --> 00:00:19,490 So with UDP, 7 00:00:19,490 --> 00:00:22,670 it makes it a little harder to determine if the VPN 8 00:00:22,670 --> 00:00:25,000 server is actually listening on that port. 9 00:00:25,000 --> 00:00:26,340 Here, unfortunately, 10 00:00:26,340 --> 00:00:29,300 you're just going to have to go out to the command line and run 11 00:00:29,300 --> 00:00:31,790 some tools to capture some network traffic. 12 00:00:31,790 --> 00:00:32,290 Here, 13 00:00:32,290 --> 00:00:35,930 the best way to do this is to run a network trace on the server and the 14 00:00:35,930 --> 00:00:41,610 client at the same time and then basically compare the traces, 15 00:00:41,610 --> 00:00:43,950 see if the traffic ever left the client and if it 16 00:00:43,950 --> 00:00:46,320 eventually ever gets to the VPN server. 17 00:00:46,320 --> 00:00:50,240 Now you may have to take traces in multiple places because if you see the 18 00:00:50,240 --> 00:00:52,780 traffic leave the client and not get to the server, 19 00:00:52,780 --> 00:00:54,780 who dropped the traffic, right? 20 00:00:54,780 --> 00:00:57,450 So we need to dig a little bit deeper and find that out. 21 00:00:57,450 --> 00:01:00,810 We might need to do network traces or packet captures or 22 00:01:00,810 --> 00:01:03,800 packet dumps on our load balancers, edge firewalls, 23 00:01:03,800 --> 00:01:05,230 and things like that. 24 00:01:05,230 --> 00:01:08,840 To run a network trace on the endpoint though, 25 00:01:08,840 --> 00:01:11,750 the best tool to use here is a tool called pktmon, 26 00:01:11,750 --> 00:01:14,420 p‑k‑t‑m‑o‑n, .exe. 27 00:01:14,420 --> 00:01:17,290 And there's the command on your screen that will execute a 28 00:01:17,290 --> 00:01:21,640 command and save all that network traffic to a packet file or 29 00:01:21,640 --> 00:01:24,540 in this case specifically an ETL file. 30 00:01:24,540 --> 00:01:25,900 And then from there, 31 00:01:25,900 --> 00:01:29,440 once you've reproduced the issue and tried to establish a connection, 32 00:01:29,440 --> 00:01:34,600 then you can just run pktmon.exe stop, and that will stop the trace. 33 00:01:34,600 --> 00:01:37,890 And one of the things that I really love the best about pktmon is 34 00:01:37,890 --> 00:01:41,460 it allows you to convert that to a PCAP file, 35 00:01:41,460 --> 00:01:44,380 which you can then view in a tool like Wireshark. 36 00:01:44,380 --> 00:01:48,010 So there's the command on your screen for exporting that 37 00:01:48,010 --> 00:01:51,440 capture file to a Wireshark PCAP file. 38 00:01:51,440 --> 00:01:55,010 Now if you're working with an older version of Windows Server, 39 00:01:55,010 --> 00:01:57,180 pktmon may not be installed there. 40 00:01:57,180 --> 00:01:59,830 It's on Server 2019 and Server 2022. 41 00:01:59,830 --> 00:02:04,190 But if you're using something older, you may have to use netsh.exe, 42 00:02:04,190 --> 00:02:06,090 and those are the commands, of course, 43 00:02:06,090 --> 00:02:09,390 that you can use to generate a packet trace on a Windows 44 00:02:09,390 --> 00:02:11,940 server or a legacy Windows server. 45 00:02:11,940 --> 00:02:16,460 Don't forget to run netsh trace stop, and then it will generate an ETL file. 46 00:02:16,460 --> 00:02:20,840 That ETL file will have to be viewed in the message analyzer. 47 00:02:20,840 --> 00:02:23,660 Unfortunately, the message analyzer has been deprecated. 48 00:02:23,660 --> 00:02:27,810 There is a standalone ETL‑to‑PCAP tool out there. 49 00:02:27,810 --> 00:02:31,520 So if you do a search in your favorite search engine, I'm sure you'll find that. 50 00:02:31,520 --> 00:02:37,490 That does allow you to convert that trace file output by netsh.exe into a 51 00:02:37,490 --> 00:02:40,550 network trace file that's recognizable in Wireshark. 52 00:02:40,550 --> 00:02:41,210 And from there, 53 00:02:41,210 --> 00:02:43,730 you can just compare and let's see where the traffic 54 00:02:43,730 --> 00:02:46,300 came and if it ever got there. 55 00:02:46,300 --> 00:02:47,050 And ultimately, 56 00:02:47,050 --> 00:02:49,300 you'll have to kind of backtrack and try to find out 57 00:02:49,300 --> 00:02:50,940 who was dropping that traffic. 58 00:02:50,940 --> 00:02:53,620 But some things to think about though when you're 59 00:02:53,620 --> 00:02:57,300 troubleshooting 809s with IKEv2. 60 00:02:57,300 --> 00:03:00,860 And this has happened to me more than once is that I 61 00:03:00,860 --> 00:03:06,110 have found that the edge firewall, instead of passing IKEv2 traffic, 62 00:03:06,110 --> 00:03:11,230 will instead respond to IKEv2 traffic on behalf of the firewall. 63 00:03:11,230 --> 00:03:13,920 Essentially, the edge firewall is a VPN server, 64 00:03:13,920 --> 00:03:16,830 and it's responding thinking it's going to establish this 65 00:03:16,830 --> 00:03:20,190 session itself as opposed to forwarding the traffic back 66 00:03:20,190 --> 00:03:21,990 to the VPN server behind it. 67 00:03:21,990 --> 00:03:28,000 So look out for that as well. That's caught me a few times in my days.