Bug report: vmnat.exe crashes / CPU busy-loop with Kaspersky Firewall - Workstation 26.0.1

[Ricardo Martin]

Hello,

I would like to report a reproducible VMware Workstation NAT issue that occurs when the Kaspersky Premium Firewall component is enabled.

Environment
-----------
Host OS: Windows 11
VMware Workstation Pro: 26H1u1 / 26.0.1 build-25688693
vmnat.exe version reported by Windows Error Reporting: 26.0.1.2799
Kaspersky Premium: 21.26.4.406
Guest OS: Windows 11
Network mode: NAT / VMnet8

The issue has been reproduced on both VMware Workstation 26.0.0 and VMware Workstation 26H1u1 / 26.0.1. Updating from 26.0.0 to 26.0.1 did not resolve it.

VMnet8 configuration:
- Network: 192.168.108.0/24
- Host VMnet8 adapter: 192.168.108.1
- VMware NAT gateway: 192.168.108.2
- Guest IP: 192.168.108.128

Problem
-------
With Kaspersky Premium Firewall enabled, VMware NAT initially works normally, but after a few minutes the guest loses Internet connectivity.

Two different failure modes have been reproduced:

1. vmnat.exe crashes with exception 0xc0000005, and VMware NAT Service may end up stopped.

2. VMware NAT Service remains reported as "Running", but vmnat.exe enters a CPU busy loop. In this state:
   - the guest can still reach 192.168.108.1;
   - the VMware NAT gateway 192.168.108.2 becomes unreachable;
   - Internet connectivity is lost;
   - vmnat.exe remains running.

CPU busy-loop verification
--------------------------
During the broken NAT state:

$c1=(Get-Process vmnat).CPU
Start-Sleep 10
$c2=(Get-Process vmnat).CPU
$c2-$c1

Observed results:
10.015625
9.921875

This means vmnat.exe consumed approximately 10 CPU seconds during 10 seconds of wall-clock time, consistent with approximately one logical CPU core being fully occupied.

Windows Event Viewer / WER
--------------------------
Repeated APPCRASH events were recorded for vmnat.exe 26.0.1.2799 with exception code 0xc0000005.

Examples from 2026-09-04:

22:01:58
Faulting module: vmnat.exe
Exception: 0xc0000005
Fault offset: 0x0000000000012909

22:03:58
Faulting module: VCRUNTIME140.dll 14.50.35719.0
Exception: 0xc0000005
Fault offset: 0x0000000000010b77

22:05:58
Faulting module: vmnat.exe
Exception: 0xc0000005
Fault offset: 0x0000000000010c23

Controlled A/B test
-------------------

Kaspersky Firewall ENABLED:
- NAT initially works.
- After a few minutes NAT fails.
- vmnat.exe either crashes or enters the CPU busy loop.
- The guest loses Internet connectivity.
- The VMware NAT gateway becomes unreachable.

In one controlled ping test:
186 packets sent
162 received
24 lost (12%)

The packet loss was concentrated at the end of the test when NAT failed.

Kaspersky Firewall DISABLED, with the rest of Kaspersky Premium still enabled:
- NAT remained operational.
- VMware NAT Service remained Running.
- Continuous ping test: 1087 packets sent, 1086 received, 1 lost.
- vmnat.exe CPU delta during a 10-second measurement: 0.
- No sustained NAT failure occurred during the test.

Troubleshooting already performed
---------------------------------
- Updated VMware Workstation from 26.0.0 to 26.0.1.
- Updated VMware Tools and rebooted the guest.
- Repaired the VMware Workstation installation.
- Restored VMware virtual networks to defaults.
- Repaired Microsoft Visual C++ 2015-2022 x64 Redistributable.
- Rebooted the Windows host.
- Completely exited Kaspersky VPN Secure Connection and stopped its service; the issue still reproduced.
- Reproduced the issue with all other VMs powered off.
- vmnat.exe / VMware / Broadcom applications are classified as Trusted/Allowed in Kaspersky.
- No explicit vmnat.exe block appears in Kaspersky Firewall reports.
- VMnet8 was tested as both Local and Trusted in Kaspersky; the issue still reproduced.

Important observation
---------------------
Among the variables tested, enabling the Kaspersky Premium Firewall component consistently reproduces the VMware NAT failure.

When only the Kaspersky Firewall component is disabled, while the rest of Kaspersky Premium remains active, the failure has not reproduced in our controlled tests.

I am not claiming that the root cause is necessarily in Kaspersky. The actual process crashing or entering the busy loop is VMware vmnat.exe, so the root defect could be in VMware NAT, Kaspersky network filtering, or the interaction between both products.

I have also opened a support case with Kaspersky so that the issue can be investigated from both sides.

Could the VMware Workstation networking team please investigate this interaction?

I can provide Windows Event Viewer / WER logs, additional reproduction results, and VMware support data if requested.

Attachment(s)

03_Kaspersky_Firewall_OFF_stable.txt   2 KB 1 version

02_Kaspersky_Firewall_ON_vmnat_failure.txt   2 KB 1 version

01_vmnat_APPCRASH_26.0.1.txt   2 KB 1 version

[HansJoachim Ballin]

Im using a Sphinx Firewall on my Windows 11 host to protect my system.

In this case I faced a similar problem, but I could resolve it by checking an setting the rule engine accordingly. From this time on everthing is running well so far a next outbound/outbound call will kick me off again.

Then a new finger exercise is required again.

THerefore I would propose you check the outbound/outbound section of your filrewall.

[Milan Krenzalek]

I can confirm exactly the same behavior on two independent servers running VMware Workstation 26H1u1 (26.0.1) with Kaspersky Endpoint Security installed on the Windows 11 Pro 25H2 hosts.

In our environment, the vmnat.exe deadlock (NAT gateway becomes completely unpingable, Guest VM loses internet and shows "Unknown Network") was reliably triggered after multiple Guest VM reboots or snapshot rollbacks (usually around the 3rd iteration) after the 26H1u1 upgrade.

Workaround that fixed it:
I added a strict exclusion for vmnat.exe inside Kaspersky Endpoint Security:

• Path: C:\Program Files\VMware\VMware Workstation\vmnat.exe
• Action: Exclude from network traffic monitoring / Do not scan network traffic.
  
  

After applying this KES exclusion, the NAT service works perfectly fine and survives consecutive Guest VM reboots and snapshot rollbacks without a single drop on 26H1u1.

Downgrading to base version 26H1 also bypasses the issue without exclusions, which proves there is a definitive conflict between the new 26.0.1 network code and Kaspersky's network filtering driver.
Thank you for opening this thread!

[HansJoachim Ballin]

Bingo, that's what I meant by saying "but I could resolve it by checking and setting the rule engine accordingly". Involved was always the vmnat.exe process on the host.

Good investigation and description! 

[Ricardo Martin]

Thanks Milan and HansJoachim for your replies and for sharing your findings.

I tested Milan's workaround, but unfortunately it didn't solve the issue on my system. One difference is that I'm using Kaspersky Premium, while Milan is using Kaspersky Endpoint Security.

I excluded vmnat.exe from Kaspersky network traffic inspection, but NAT still failed after a few minutes. vmnat.exe crashed again with 0xc0000005, the NAT gateway became unreachable, and VMware NAT Service eventually stopped.

I also contacted Kaspersky Support. They suggested disabling the Kaspersky Anti-Virus NDIS 6 Filter (KL_KLIM6) only on VMware VMnet8. I tested that separately, and also tested both measures together. Unfortunately, I got the same vmnat.exe crashes in all cases.

As another workaround, Kaspersky suggested switching from NAT to Bridged networking. That does work correctly. After setting VMnet0 to bridge directly to my physical Wi-Fi adapter, I ran a continuous Internet ping for about 15 minutes with 863 packets sent, 863 received and 0% packet loss, while VMware NAT Service remained stopped.

So Bridged networking works as a workaround, but I would still prefer to use NAT because of the additional isolation it provides. At this point the problem still seems to be specifically related to the interaction between Kaspersky Firewall and VMware NAT / vmnat.exe.

I've sent these results back to Kaspersky Support and asked them to investigate the issue further, but I'm still looking for a way to make NAT work reliably with Kaspersky Firewall enabled.

If anyone has seen the same issue specifically with Kaspersky Premium, or has any other ideas or tests I could try, I'd really appreciate any suggestions.

I'll update the thread if Kaspersky comes back with anything useful.

Thanks again for your help.

[Milan Krenzalek]

I may see where the difference is.
When I mentioned the network traffic exclusion, I didn't just add a simple firewall rule. I configured it under the deep "Trusted applications" (Exclusions) policy.

Here is a screenshot from KES Policy / General Settings / Exclusions / Trusted applications:

I didn't investigate it any further, but this is what works for me.

[Ricardo Martin]

Hi Milan,

Sorry for the late reply, and thanks again for clarifying your configuration.

I've now reproduced your Trusted Applications setup as closely as possible in Kaspersky Premium. I understand you're using Kaspersky Endpoint Security, so the interface is slightly different, but Premium provides equivalent options for the settings shown in your screenshot. I enabled the same exclusions for vmnat.exe, and I'm attaching a screenshot of my configuration so you can compare it with yours.

Unfortunately, it still didn't solve the issue on my system.

I switched the VM back to NAT and initially everything worked normally: Internet connectivity, the VMnet8 host adapter (192.168.108.1) and the NAT gateway (192.168.108.2) all responded correctly. I then started a continuous ping to 192.168.108.2.

After a few minutes, the NAT gateway became unreachable again.

Interestingly, VMware NAT Service was still reported as Running, but vmnat.exe had entered the same CPU busy-loop as before: approximately 10 CPU seconds during a 10-second measurement, effectively consuming one logical CPU core.

Windows also logged two new vmnat.exe APPCRASH events:

• 19:50:46 - vmnat.exe 26.0.1.2799 - exception 0xc0000005 - fault offset 0x10c23
• 19:52:46 - vmnat.exe 26.0.1.2799 - exception 0xc0000005 - fault offset 0x10c23

So unfortunately, the workaround that works with Kaspersky Endpoint Security doesn't appear to resolve the issue in my Kaspersky Premium environment.

I also have an open case with Kaspersky Support. They're still investigating and have suggested several tests and workarounds, but so far none of them has made VMware NAT stable. Bridged networking continues to work correctly, but I'd still prefer to use NAT.

Thanks again for taking the time to help and for sharing your configuration. If you, or anyone else following the thread, has any other ideas or tests I could try, I'd really appreciate it.