Troubleshooting 809 errors when using IKEv2 introduces
some new and interesting challenges.
First, IKEv2 uses UDP for communication,
meaning we can't use our Test‑NetConnection PowerShell
command because that fundamentally uses TCP.
So with UDP,
it makes it a little harder to determine if the VPN
server is actually listening on that port.
Here, unfortunately,
you're just going to have to go out to the command line and run
some tools to capture some network traffic.
Here,
the best way to do this is to run a network trace on the server and the
client at the same time and then basically compare the traces,
see if the traffic ever left the client and if it
eventually ever gets to the VPN server.
Now you may have to take traces in multiple places because if you see the
traffic leave the client and not get to the server,
who dropped the traffic, right?
So we need to dig a little bit deeper and find that out.
We might need to do network traces or packet captures or
packet dumps on our load balancers, edge firewalls,
and things like that.
To run a network trace on the endpoint though,
the best tool to use here is a tool called pktmon,
p‑k‑t‑m‑o‑n, .exe.
And there's the command on your screen that will execute a
command and save all that network traffic to a packet file or
in this case specifically an ETL file.
And then from there,
once you've reproduced the issue and tried to establish a connection,
then you can just run pktmon.exe stop, and that will stop the trace.
And one of the things that I really love the best about pktmon is
it allows you to convert that to a PCAP file,
which you can then view in a tool like Wireshark.
So there's the command on your screen for exporting that
capture file to a Wireshark PCAP file.
Now if you're working with an older version of Windows Server,
pktmon may not be installed there.
It's on Server 2019 and Server 2022.
But if you're using something older, you may have to use netsh.exe,
and those are the commands, of course,
that you can use to generate a packet trace on a Windows
server or a legacy Windows server.
Don't forget to run netsh trace stop, and then it will generate an ETL file.
That ETL file will have to be viewed in the message analyzer.
Unfortunately, the message analyzer has been deprecated.
There is a standalone ETL‑to‑PCAP tool out there.
So if you do a search in your favorite search engine, I'm sure you'll find that.
That does allow you to convert that trace file output by netsh.exe into a
network trace file that's recognizable in Wireshark.
And from there,
you can just compare and let's see where the traffic
came and if it ever got there.
And ultimately,
you'll have to kind of backtrack and try to find out
who was dropping that traffic.
But some things to think about though when you're
troubleshooting 809s with IKEv2.
And this has happened to me more than once is that I
have found that the edge firewall, instead of passing IKEv2 traffic,
will instead respond to IKEv2 traffic on behalf of the firewall.
Essentially, the edge firewall is a VPN server,
and it's responding thinking it's going to establish this
session itself as opposed to forwarding the traffic back
to the VPN server behind it.
So look out for that as well. That's caught me a few times in my days.