Regarding KB5099538: VM asymmetric traffic dropped on multihomed adapter

Question

Hello,

We are experiencing asymmetric routing issues on multihomed Windows VMs after installing the July 14 2026 update (KB509538)

Symptoms observed: VM A can connect to VM B but VM B doesn't reply over the same path.

Traceroute shows the reply path is forced out of a completely different network interface (Management NIC)

On a 3 NIC VM, Windows suddenly ignored an interface metric of 1 and routed traffic over metric 10 because both had default gateways set. WE had to remove the duplicate gateway and set a wide metric gap (1 vs 30) to fix it.

Some Investigation

1. The guest VM system log is completely clean
2. There is no AFD event ID 16003 (unregistered tdi provider block), meaning hte local drivers are compliant.

Can a Microsoft Engineer or MVP confirm if the TDI/AFD.sys hardening in this specific update directly alters multi interface socket binding or force Strong Host routing logic?

Answer 1

Hello @MWC

Based on the symptoms, I would be cautious about attributing this directly to KB509538 or AFD.sys/TDI hardening without Microsoft confirming a regression.

Windows multihomed systems with multiple default gateways can produce unpredictable or asymmetric routing. Interface metrics influence route selection, but they don't guarantee that return traffic will use the interface on which the original traffic arrived.

The fact that removing the duplicate default gateway and creating a clearer metric separation resolved the issue strongly points toward route selection on the multihomed VM.

I would recommend capturing the following before and after installing KB509538 on an affected system:

Get-NetRoute -AddressFamily IPv4
Get-NetIPInterface -AddressFamily IPv4
Get-NetIPConfiguration

If identical network configuration produces different route selection specifically after KB509538, that would provide a much stronger case for a Windows regression.

I couldn't find a Microsoft-published known issue for KB509538 specifically confirming that TDI/AFD.sys changes force Strong Host behavior or alter multihomed socket binding. I would therefore avoid stating that the update causes this until Microsoft can correlate it with the update.

Since you can reproduce the behavior pre/post update, opening a Microsoft support case with packet captures, route tables, and the exact Windows build would be the best next step.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.