When Windows IKEv2 Meets Fragment-Dropping Networks

IKEv2 is a clean and efficient VPN protocol, but its reliance on large messages during authentication can cause surprising failures when it crosses access networks that mishandle fragments. Administrators running WatchGuard firewalls and Windows clients have been reporting problems where connections succeed on one ISP but fail completely on another. The culprit is packet fragmentation and the lack of support for IKEv2 fragmentation in some devices.

How the problem appears

A Windows client begins the exchange with the firewall by sending an IKE_SA_INIT request. The firewall responds, and at this point both sides are ready to authenticate. The client then sends the IKE_AUTH message which includes certificate information. If the trusted root CA store on the client is large, Windows includes hashes for all of them, inflating the packet beyond the Ethernet MTU of 1500 bytes.

From Windows 10 version 1803 onward, the client supports IKEv2 fragmentation defined in RFC 7383. This mechanism allows the message itself to be fragmented within IKE before being handed to IP, avoiding reliance on IP fragmentation. However, the server must advertise that it supports RFC 7383. If the server does not, the client falls back to plain IP fragmentation.

On networks that silently drop UDP fragments, which includes T-Mobile 5G home internet and some Spectrum consumer modems, the fragments never arrive at the firewall. Packet captures show the Windows client transmitting several attempts of the fragmented IKE_AUTH, while the firewall sees nothing after IKE_SA_INIT.

Why WatchGuard is affected

WatchGuard’s own knowledge base describes this exact scenario. The product accepts IKEv2 traffic but does not implement RFC 7383. When Windows tries to connect through an ISP that drops fragments, the connection stalls. Administrators see the IKE_SA_INIT succeed but no IKE_AUTH ever reach the device. WatchGuard recommends deleting certificates from the Windows root store, so the packet is small enough to fit under 1500 bytes. That works temporarily, but as the operating system refreshes the store the problem returns.

Why common fixes fail

Lowering the MTU on the Windows interface has no effect because the IKE stack does not honor the interface MTU. The packet is still assembled above 1500 bytes and handed to IP as a single datagram which then fragments. Adjusting VPN proposals or toggling options on the WatchGuard side cannot solve it either because the product simply does not support negotiating IKE fragmentation.

What can be done

There are only a few paths forward. The cleanest is to use a client or server that supports RFC 7383, so the IKE_AUTH never depends on IP fragmentation. Third-party clients like strongSwan or TheGreenBow implement it and interoperate with servers that advertise support. Another approach is to move affected users to SSL VPN which runs over TCP or TLS and avoids UDP fragmentation altogether, although performance is generally lower. The last lever is certificate chain management. By reducing the length of the certificate chain or issuing VPN server certificates directly from a root, the size of the IKE_AUTH message can be kept under the MTU, and fragmentation never occurs.

Conclusion

This is not a bug in Windows. The client is capable of IKE fragmentation, but it will only use it when the server agrees. WatchGuard devices today do not advertise RFC 7383, so Windows falls back to IP fragmentation and fails on networks that discard fragments. Until WatchGuard implements support, administrators must either control the certificate payload size or move to protocols that are not sensitive to this problem.