VMware Fusion Support Report - Windows 11 ARM Sustained TCP Failure with VMXNET3 Offloads
Report date: 2026-06-05
Reporter: redacted
Product: VMware Fusion 26.0.0, build 25388279
Severity: High - guest networking unusable for sustained downloads without workaround
Status: Workaround identified; requesting permanent fix from Broadcom/VMware
EXECUTIVE SUMMARY
A Windows 11 ARM64 guest on VMware Fusion 26.0.0 running on an Apple M1 MacBook Air with macOS 26.5.1 exhibits failure of sustained TCP downloads while basic connectivity such as DHCP, DNS, ping, and small transfers appears normal. The failure occurs on both NAT and bridged networking with the VMXNET3 adapter.
Packet captures on the host show TCP SYN retransmissions from the guest with no completing handshake or sustained return traffic until VMXNET3 hardware offloads are disabled in the Windows guest.
Workaround that restores bulk TCP:
- Use bridged networking to Wi-Fi, en0.
- Disable all VMXNET3 TCP/IP offloads in the Windows guest, including checksum offload, TSO, LSO, RSS, RSC, and global task offload.
After the workaround, download behavior improved from approximately 48 KB followed by stall/timeout to approximately 150 MB in 120 seconds at about 1.2 MB/s, reaching 85% of a 176 MB test file before the test script timeout.
ENVIRONMENT
Host:
- Hardware: MacBook Air, MacBookAir10,1, Apple M1, 16 GB RAM
- macOS: 26.5.1, build 25F80, macOS Tahoe
- VMware Fusion: 26.0.0, build 25388279
- Host Wi-Fi IP: <host-lan-ip>, same LAN as guest in bridged mode
- Host router: <router-ip>
- macOS application firewall: Disabled during testing
Guest VM:
- Display name: Windows 11 64-bit Arm
- VM path: /Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/
- Guest OS: Windows 11 Home ARM64, build 26200.8457
- Hostname: <guest-hostname>
- Virtual NIC: VMXNET3, ethernet0.virtualDev = "vmxnet3"
- MAC address: <redacted-guest-mac>
- vCPU / RAM: 4 vCPU / 8192 MB
- VM encryption: Partial, vmx.encryptionType = "partial"
- VMware Tools: 13.1.0.0; install error 21004 observed in vmxf
VMXNET3 / driver versions from logs and bundled driver:
- Guest VMXNET3 driver in vmware.log: 24409624
- Bundled ARM64 INF in drivers-arm64.zip: 1.9.20.0, DriverVer 10/23/2024, Provider Broadcom Inc.
- vmxf manifest vmxnet3_Win10Arm: 1.9.20.1
- Tools monolithic in vmxf: 13.1.0.0
Network modes tested:
- NAT, vmnet8, 172.16.8.0/24
Guest IP when working at L3: <guest-nat-ip>
Sustained TCP result: Fail, stall at about 48 KB.
- Bridged Wi-Fi, en0
Guest IP when working at L3: <guest-bridged-ip>
Sustained TCP result: Fail until offloads disabled; then mostly OK.
PROBLEM DESCRIPTION
Symptoms:
1. Guest has working DHCP, gateway, DNS, and light connectivity.
2. Large or sustained HTTPS downloads stall almost immediately or progress slowly and then fail.
3. Windows curl.exe against the Sysinternals test file:
- Before fix: approximately 48,629 bytes of 176,072,374 received, then timeout after 60 seconds.
- After offload workaround in bridged mode: 149,782,528 bytes in 120 seconds, about 1.2 MB/s, HTTP 200. The timeout occurred only because the script max-time was 120 seconds and the full file would need about 148 seconds at that rate.
Controlled reproduction in guest:
curl.exe -4 -L --http1.1 --connect-timeout 10 --max-time 60 `
-o $env:TEMP\test.zip `
Expected file size: 176,072,374 bytes.
Host control on same network and same URL:
curl -4 -L --http1.1 --connect-timeout 10 --max-time 20 \
-o /tmp/sysinternals_host.zip \
Host result: HTTP 200, full 176,072,374 bytes, approximately 38-52 MB/s. The host is not the bottleneck.
DIAGNOSTIC EVIDENCE
1. NAT path - guest TCP never completes in packet capture
Host captures on Fusion NAT, vmenet3 / bridge101 / 172.16.8.0/24:
- Guest <guest-nat-ip> emitted many TCP SYN frames to public destinations.
- No SYN-ACK observed on guest-side interface during failure windows.
- DNS via NAT, <nat-dns-ip>:53, still worked.
- WAN-side en0 capture did not show corresponding forwarded NAT flows during the same windows.
Conclusion: NAT translation/return path via vmnet-natd appeared broken, or the guest TCP path was broken before return traffic could be delivered.
2. Bridged path - same SYN-only pattern before workaround
Host capture on en0, guest <guest-bridged-ip>, bridged:
50 packets captured - all outbound SYN from <guest-bridged-ip>
Zero inbound SYN-ACK or data to <guest-bridged-ip>
Multiple SYN retransmissions to 8.8.8.8, Akamai, Microsoft, and other destinations
Example packet pattern:
<guest-bridged-ip>.xxxxx > 8.8.8.8.443: Flags [S], seq ..., win 65535, options [mss 1460,...]
Repeated retransmits, no replies captured on en0.
After disabling VMXNET3 offloads, the same test showed sustained curl progress at approximately 1.2 MB/s.
3. VM log - earlier bridged/NAT VMXNET3 RX errors from prior session
In an earlier bridged run before switching to NAT, vmware.log contained thousands of:
VMXNET3 hosted: Cannot retrieve the buffer descriptors per rx packet
Count observed in prior debugging: 4229.
This specific message was not reproduced in the latest bridged session log grep, but it is consistent with VMXNET3 RX path instability.
4. Guest adapter counters during failure
Windows reported no ReceivedDiscardedPackets, ReceivedPacketErrors, or outbound errors during failed downloads. The failure is not reflected as obvious adapter error counters.
5. MTU / PMTU ruled out
- Interface MTU: 1500
- ping -4 -f -l 1472 to 8.8.8.8 succeeded with DF set.
- Smaller sizes also succeeded.
ATTEMPTS THAT DID NOT FIX THE ISSUE
1. NAT to Bridged Wi-Fi: Still failed until offloads were disabled.
2. Restart vmnet-cli --configure / --stop / --start: No fix.
3. Disable Windows LSO / TSO / RSS / RSC plus TCP autotuning: No fix alone.
4. Increase VMXNET3 ring/buffer values to max INF values: No fix.
5. Use e1000e adapter: No working Windows ARM driver path.
6. Change to 4 vCPU / 8 GB RAM: No fix.
7. Disable 3D / WDDM blockingPreemptEvent: No effect on network.
8. Set useMacosVmnetVirtApi = 0 in nat.conf: No fix; reverted.
9. pnputil /add-driver vmxnet3.inf /install: Driver already current; no fix alone.
WORKAROUND CONFIRMED
A. Use bridged networking
VMX settings:
ethernet0.connectionType = "bridged"
ethernet0.virtualDev = "vmxnet3"
Fusion log confirms:
VNET: MacosVmnetVirtApiStartBridgedInterface: Ethernet0: bridge mode, selected=en0
Guest received an IPv4 address on the same LAN as the host, with the same LAN gateway.
B. Disable all VMXNET3 offloads in Windows guest
Global commands:
netsh int ip set global taskoffload=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global rsc=disabled
netsh int tcp set global ecncapability=disabled
netsh int tcp set global timestamps=disabled
Disable-NetAdapterLso -Name "Ethernet" -IPv4 -Confirm:$false
Disable-NetAdapterLso -Name "Ethernet" -IPv6 -Confirm:$false
Disable-NetAdapterRss -Name "Ethernet" -Confirm:$false
Per-adapter VMXNET3 Advanced properties set to Disabled:
- IPv4 Checksum Offload
- IPv4 TSO Offload
- TCP Checksum Offload, IPv4 and IPv6
- UDP Checksum Offload, IPv4 and IPv6
- Large Send Offload V2, IPv4 and IPv6
- Receive Side Scaling
- Recv Segment Coalescing, IPv4 and IPv6
Optional setting used during automated test:
- mtu=1400 on guest interface
Then restart the guest adapter:
Restart-NetAdapter -Name "Ethernet"
Workaround result from automated test:
- Guest IP: <guest-bridged-ip>
- Ping host LAN IP: 3/3 OK, less than 1 ms
- Ping gateway: 3/3 OK, around 10 ms
- curl Sysinternals, 120 second max: 149,782,528 / 176,072,374 bytes, about 1.2 MB/s, HTTP 200
- Failure mode after workaround: Timeout at 120 seconds, not early stall
ROOT CAUSE ANALYSIS / REPORTER ASSESSMENT
Primary suspected cause:
VMXNET3 TCP offload path defect or regression on Fusion 26 with Windows 11 ARM64 build 26200. Sustained TCP fails with default offload settings; disabling offloads restores bulk throughput.
Secondary suspected issue:
On this host, Fusion NAT via vmnet-natd also exhibited broken guest TCP completion, with SYN out and no SYN-ACK on guest-side capture. This may be a separate Fusion/macOS 26 regression, or it may be exacerbated by the same guest offload issue.
Items ruled out:
- Host bandwidth
- DHCP/DNS
- MTU/PMTU
- Guest RAM/vCPU
- Physical Wi-Fi
HOST ENVIRONMENT NOTES / POSSIBLE CONFOUNDERS
These were present but were not removed during the final successful workaround test:
- Third-party WireGuard and OpenVPN VPN system extensions were activated, but VPN profiles were disconnected.
- Multiple WireGuard VPN profiles existed in the macOS network list.
- com.apple.nesessionmanager.content-filter was present in launchd.
macOS Local Network permission for Fusion should be enabled when using bridged Wi-Fi.
REQUEST TO BROADCOM / VMWARE ENGINEERING
1. Acknowledge and reproduce sustained TCP failure on Fusion 26.0.0, build 25388279, with macOS 26.5.1 and Windows 11 ARM build 26200 using default VMXNET3 offload settings.
2. Fix the VMXNET3 ARM64 driver so default offload settings work for sustained TCP, or ship safe defaults with the problematic offloads disabled.
3. Investigate NAT, vmnet-natd, guest TCP completion on macOS 26 / Fusion 26 where SYN leaves the guest but no SYN-ACK appears on guest-side capture.
4. Investigate VMware Tools install error 21004 on this VM, because it may affect the driver/tools update path.
5. Provide a supported permanent workaround or KB article for Windows 11 ARM on Apple Silicon until fixed.
FILES TO ATTACH TO SUPPORT CASE
Before posting publicly, review all files for local usernames, hostnames, serial numbers, VM UUIDs, MAC addresses, LAN IPs, public IPs, and account identifiers.
Primary logs and config:
/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/vmware.log
/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/vmware-0.log
/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/Windows 11 64-bit Arm.vmx
/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/Windows 11 64-bit Arm.vmxf
/Library/Preferences/VMware Fusion/vmnet8/nat.conf
/Library/Preferences/VMware Fusion/networking
Packet captures, if still available:
/tmp/vm-vmenet3-curl2.pcap
/tmp/vm-en0-curl2.pcap
/tmp/vm-vmenet3-after-reset.pcap
/tmp/vm-en0-after-reset.pcap
Workaround test output:
/Users/<local-user>/.vm_cmd_relay/out.txt
VMX backups / config history:
Windows 11 64-bit Arm.vmx.bak-network-20260604
Windows 11 64-bit Arm.vmx.bak-bridged-20260605
Windows 11 64-bit Arm.vmx.bak-bridged-20260605-2
Windows 11 64-bit Arm.vmx.bak-e1000e-20260605
Windows 11 64-bit Arm.vmx.bak-vmxnet3-4cpu-8gb-20260605
Windows 11 64-bit Arm.vmx.bak-disable3d-20260605
Bundled driver reference:
/Applications/VMware Fusion.app/Contents/Library/isoimages/arm64/drivers-arm64.zip
-> vmxnet3/Win10_1709/ARM64/vmxnet3.inf, DriverVer 10/23/2024, 1.9.20.0
SUGGESTED SUPPORT BUNDLE COMMANDS FOR HOST
Collect Fusion support data, preferably with Fusion quit:
sudo /Applications/VMware\ Fusion.app/Contents/Library/vm-support.sh
Optional: copy key artifacts into one folder for upload.
Review the copied files for personal identifiers before posting publicly.
mkdir -p ~/Desktop/fusion-support-bundle-20260605
cp "/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/vmware"*.log ~/Desktop/fusion-support-bundle-20260605/
cp "/Users/<local-user>/Virtual Machines.localized/Windows 11 64-bit Arm.vmwarevm/Windows 11 64-bit Arm.vmx"* ~/Desktop/fusion-support-bundle-20260605/
cp /Users/<local-user>/.vm_cmd_relay/out.txt ~/Desktop/fusion-support-bundle-20260605/
cp /Library/Preferences/VMware\ Fusion/vmnet8/nat.conf ~/Desktop/fusion-support-bundle-20260605/ 2>/dev/null
REPRODUCTION STEPS FOR VMWARE QA
1. Install Fusion 26.0.0, build 25388279, on an Apple Silicon Mac running macOS 26.x.
2. Create or use a Windows 11 ARM64 guest, build 26200, with VMXNET3 and default offload settings.
3. Configure NAT and run the Sysinternals curl test. Observe stall at approximately 48 KB.
4. Switch to bridged Wi-Fi, en0, and repeat. Observe the same stall.
5. Run host tcpdump -i en0 host <guest-bridged-ip> and tcp during curl. Observe SYN retransmits without SYN-ACK.
6. In guest, disable all VMXNET3 offloads listed above plus taskoffload=disabled.
7. Repeat curl. Observe sustained download, approximately 1+ MB/s in this test.
8. Compare with host-native curl on the same URL, which should complete at full host network speed.
REFERENCES
- Brad Diggs - VMXNET3 "Cannot retrieve the buffer descriptors per rx packet" / vmnet-cli restart:
- Broadcom KB - VMXNET3 out-of-buffers / packet drops:
- Broadcom KB / release notes - Fusion NAT / Sequoia+ issues with bridged workaround documented:
- Community discussion - Windows 11 ARM slow network on Fusion:
SHORT FORUM / TICKET SUMMARY
Subject:
Fusion 26.0.0 - Windows 11 ARM VMXNET3 sustained TCP failure on NAT and bridged networking, fixed only by disabling all offloads
Body:
Windows 11 ARM64 guest, build 26200, on Fusion 26.0.0 / macOS 26.5.1 / Apple Silicon fails sustained TCP downloads on VMXNET3 with default settings. NAT and bridged networking are both affected. tcpdump shows guest SYN retransmissions without replies. Disabling all VMXNET3 offloads plus using bridged Wi-Fi restores bulk TCP, reaching 149 MB in 120 seconds versus approximately 48 KB before. Requesting a driver/Fusion fix for the ARM64 VMXNET3 offload path and investigation of the NAT regression. Logs and vmx are available after redaction.
End of report.