Tailscale conflicts with VMware

So Tailscale just decided to stop working on the laptop. I don’t use it all that much, mostly for some stuff here and there, but the day I actually needed it, it was dead. Every query just came back with:

tailscale status
failed to connect to local tailscaled
503 Service Unavailable: no backend

no backend. The daemon was running, the service was up, and there was just no backend. No idea what that even meant, so naturally I asked ChatGPT.

The part where I panic and break my own network

Not the smartest move on my part. I followed the troubleshooting steps it gave me and somehow ended up nuking my whole networking stack. The Windows Network Reset, and/or deleting oem28.inf while running through the steps, took out the Bluetooth, the Wi-Fi, the Ethernet, however else the network drivers were held together on this machine. The whole Wi-Fi driver ecosystem just collapsed.

Now I had two problems. Tailscale still wasn’t working, and I’d also killed the laptop’s ability to talk to anything at all. The help made it worse. That one stung.

Thankfully I had a restore point saved and the machine came back from it. System Restore rolled the network stack back to something that worked, so at least I was back online. Lesson learned, don’t reset the entire network stack for one app.

Actually looking at the problem this time

After getting the system back, I went straight for the actual Tailscale issue instead of messing with the whole stack again. Had ChatGPT go through the GitHub issues, the Wintun issues, whatever related reports were floating around. That eventually pointed at a VMware networking conflict, which made sense. VMware is on the same box.

The thing that finally stood out was a VMware registry entry. This CLSID:

HKLM\SOFTWARE\Classes\CLSID\{3d09c1ca-2bcc-40b7-b9bb-3f3ec143a87b}

described as:

VMware Bridge notifier object

That VMware Bridge notifier was getting in the way of Windows completing the network-class configuration, and that’s what the Tailscale Tunnel was choking on. In Device Manager it showed:

CM_PROB_NEED_CLASS_CONFIG
Problem Code: 56

So the pieces clicked. Windows couldn’t finish configuring the virtual adapter because of that VMware component, and that’s why the backend never came up. I still can’t tell you exactly how the VMware Bridge notifier breaks Wintun under the hood, but it did, and the symptoms lined up.

Backed the key up before touching it, then removed it:

reg export "HKLM\SOFTWARE\Classes\CLSID\{3d09c1ca-2bcc-40b7-b9bb-3f3ec143a87b}" "$env:USERPROFILE\Desktop\vmware-bridge.reg"

reg delete "HKLM\SOFTWARE\Classes\CLSID\{3d09c1ca-2bcc-40b7-b9bb-3f3ec143a87b}" /f

shutdown /r /t 0

Rebooted and ran tailscale status again. Instead of:

503 Service Unavailable: no backend

it came back with:

Logged out.

That’s actually a good sign. It means the local Tailscale backend was alive again and the only thing left was authentication. Daemon up, adapter up, networking talking. tailscale login was all that remained.

Done

So yeah. The whole mess was one VMware registry entry dressed up as a broken Tailscale install. The Tailscale service was never really the problem, and neither was Wintun. Windows just couldn’t finish network-class configuration on the virtual adapter because of some third-party virtual network component, and it looked exactly like a dead Tailscale daemon.

If you ever see 503 no backend next to Wintun Code 56, don’t start deleting drivers like I did. Check network-class config and third-party virtual network stuff first. Deleting oem28.inf and running a Network Reset won’t fix it, it’ll just take your Wi-Fi with it.

That whole mess is why I wrote this post.