Strange IPv6 IKEv2 VPN issue

Question

Hi,
since we switched to mobile IPv6 IKEv2 VPN we have a strange bug when connecting....
The first 1-10 minutes in the morning the VPN packets (ISAKMP/ESP) are not sent at all. I ran a packet capture on the router from the source network and do not see a single packet towards the VPN server when trying to connect. After a few minutes it suddenly works and then works for the rest of the day. The problem cannot be reproduced for the rest of the day, it only occurs again the next morning.

The routing table from the client device looks normal. In the firewall all outgoing connections are allowed. Ping to the VPN server works consistently (even if the VPN connect does not work).

Anyone have an idea what Windows is doing here again for nonsense?

Regards,
Christoph

Answer 1

Hello Christoph,

There are 4 types of ETW providers: MOF, Manifest/Crimson, WPP and TraceLogging. "IKEEXT Trace Provider" is a WPP provider (which is the most difficult type of event to interpret if the TMF information is not published/available). {e7ba355a-ec20-5993-dd3b-9215e4d8a23c} is the GUID of a TraceLogging provider added in Windows 11 (Microsoft.Windows.Networking.Ikeext) that delivers essentially the same information as "IKEEXT Trace Provider" but in an easier to interpret format.

I use tools that I developed myself to inspect the trace data; previously I recommended Microsoft Message Analyzer as the best publicly available tool to use, but this tool has now been decommissioned.

The "not working" trace shows that the initial IKEv2 packet is being transmitted and retransmitted, but no response is received:

So the client appears to be working perfectly well; somewhere along the route between client and server either the initial request or the initial response is being lost (possibly due to NAT). You mentioned in your first message that you were able to make a capture on the "source network" (home network?) router? Can you share any more information about that (e.g. router type, tool used for capture) and are you sure that there was no trace of traffic using UDP port 500?

Gary

Answer 2

Hi Garry,
I have a Fritzbox 6591 as router which is able to capture packets, I did the analysis with Wireshark. If it does not work then I see neither a packet towards VPN server nor a UDP port 500 packet. Both I see as soon as VPN works. Yesterday I have also listened directly on the client on the WiFi interface with Wireshark, same picture. Not a single packet in the direction of the VPN server.

If Windows itself thinks it has sent the package then it just gets crazier.

Answer 3

Hello Christoph,

When you trace a working connection establishment on the Fritzbox, do you see the following sequence behaviour on UDP port 500?

1. UDP source and destination port 500, IPv6 sources address of client, IPv6 destination address of VPN server.
2. UDP source port not 500, UDP destination port 500, IPv6 sources address of Internet facing router interface, IPv6 destination address of VPN server.
3. UDP source port 500, UDP destination port not 500, IPv6 sources address of VPN server, IPv6 destination address of Internet facing router interface.
4. UDP source and destination port 500, IPv6 sources address of VPN server, IPv6 destination address of client.
5. No more traffic on UDP port 500 (client & server switch to port 4500).

While it is possible that the packet "sent" by IKEv2 does not actually reach the wire, it seems more likely (to me) that the capture on the Fritzbox is not working as one might hope (e.g. it is not capturing on all interfaces (internal/external, etc.)). It would nice to have some reassurance that this is not the case.

Gary

Answer 4

Here is the recording of a working connection. You can see quite well who sends what to which port.

2a02:8109.... = Windows Client
2001:1438.... = VPN Server

While it is possible that the packet "sent" by IKEv2 does not actually reach the wire, it seems more likely (to me) that the capture on the Fritzbox is not working as one might hope (e.g. it is not capturing on all interfaces (internal/external, etc.)). It would nice to have some reassurance that this is not the case.

From the same assumption, I ran the Wireshark packet capture directly on the Windows client yesterday. The device was only connected via WiFi and Wireshark did not see any packets on the WiFi interface in the direction of the VPN server. So the Fritzbox already tells the truth here.

Today I wanted to let Wireshark listen to all interfaces, but the problem did not occur this morning.

Answer 5

Hello Christoph,

Mentioning "NAT" was a mistake on my part, triggered by the use of port 4500 in one of the traces. IPv6 does not need "NATting" and the switch to port 4500 was triggered by support for MOBIKE. As RFC 4555 (IKEv2 Mobility and Multihoming Protocol) says:

The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later if a NAT is detected on some other path).

That said, the packet capture on the FRITZ!Box should, if configured appropriately, still see the initial IKEv2 request and response twice (once each on the internal and external interfaces).

I suggest using many packet capture mechanisms simultaneously to check at which points the initial packet can be seen, using (for example):

• pktmon start --capture --comp nics --flags 0x10 --trace --provider Microsoft-Windows-WFP --keywords 0x3FFFFFFFFFFF --provider Microsoft-Windows-RRAS --provider "IKEEXT Trace Provider" --keywords 0x10 --level 4 --file-name why.etl
• Wireshark
• FRITZ!Box capture on both internal and external (Internet) interfaces:
  

Gary