WiFi bridging Mac Book Pro M5 Pro - not working / 25H2u1 Tahoe 26.4

[Mart Janssen]

Hi, 

Just did a fresh install with 25H2u1 on Tahoe 26.4 (new machine). Wenn selecting bridging/WiFi the Mac asks me to authorise which I do. When starting the guest (in my case Debian / arm64) I get:

Could not connect 'Ethernet0' to virtual network 'vmnet2'.

Resulting in no network in the guest os. NAT works.

In the log:

2026-03-30T16:18:04.102Z -INFO vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] VNET: MacosVmnetVirtApiGetInterfaceForBridging: Using iface: en0 for bridging
2026-03-30T16:18:04.102Z -INFO vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] VNET: MacosVmnetVirtApiStartBridgedInterface: Ethernet0: Starting virtual interface in bridge mode, preferred=(null), selected=en0
2026-03-30T16:18:09.103Z -WARNING vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] VNET: MacosVmnetVirtApiWaitSem: Ethernet0: Timeout while waiting for semaphore
2026-03-30T16:18:09.103Z -ERROR vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] VNET: MacosVmnetVirtApiStartInterface: Ethernet0: Failed to wait for semaphore on interface start
2026-03-30T16:18:09.106Z -INFO vmware-vmx 1368 [fusion@4413 threadName="host-24495"] VNET: MacosVmnetVirtApiStopHandler: Ethernet0: stopping virtual interface, status=1000
2026-03-30T16:18:09.106Z -INFO vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] VNET: MACVNetPort_Connect: Ethernet0: can't start virtual interface
2026-03-30T16:18:09.107Z -INFO vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] [msg.vnet.connectvnet] Could not connect 'Ethernet0' to virtual network '/dev/vmnet0'. More information can be found in the vmware.log file.
2026-03-30T16:18:09.107Z -INFO vmware-vmx 1368 [fusion@4413 threadName="vcpu-0"] [msg.device.startdisconnected] Virtual device 'Ethernet0' will start disconnected.

I am clueless how to solve this. Any ideas?

Best regards,

Mart

[Jean Jean]

Hi,

I’m experiencing the same issue on a MacBook Air M5 running 25H2u1 and macOS 26.4.

However, if I remember correctly, bridging/Wi-Fi worked properly on a MacBook Air M2 with the same versions (25H2u1 and macOS 26.4).

[Jean Jean]

It might be related to Apple’s N1 wireless chip introduced in these new devices ?

[Mart Janssen]

I did some research in the meantime, looking also at some forums from other solution I see pop up the same issue. So indeed, it seems to be a wider problem focusing on the N1.

[Wandong Qin]

I have same issue with my Macbook Air 2026 M5 , I believe it is related to the new N1 chip. Hope this can be solved soon.

[Wandong Qin]

After upgrading to 26H1, the issue is still not resolved.

[dmun]

I have a new 2026 Macbook Pro M5 and can confirm that network bridging is broken in Fusion 26H1. The vmnet-bridge process runs but there is no /dev/vmnet0 for it to connect to. The NAT option does work but I need to run a particular VM in bridge mode. Some searches related to the N1 chip show that Fusion is not the only virtualization product facing this issue.

Hopefully the appropriate engineering resources are aware of this and working on future support for the N1. Thank you!

[Technogeezer]

Apple just fixed an issue with the wi-fi on M5 Macs in macOS 26.5.1:

This update addresses an issue for enterprise users where Macs with an M5 chip could unexpectedly shut down when using certain content filtering network extensions.

Has anyone found if this macOS update has made any difference?

[Technogeezer]

I've been doing a bit more research and have found the following:

• It's indeed true that other hypervisors on the Mac are experiencing the same issue with M5 MacBooks. Parallels and UTM are reporting the same issues with the M5 MacBooks. 
• The issue is not the M5 CPU itself, rather the new Apple N1 wi-fi chip in use on these Macs. If Apple expands the use of this Wi-Fi chip in yet-to-be-released Macs, the problem will not be unique to the current M5 MacBook.
• Research shows that the use of multiple MAC addresses for a Wi-Fi interface (needed to support hypervisor bridged networks) are not technically supported in the Wi-Fi protocols. Some Wi-Fi chipsets and drivers are lax about this support.
• It appears that the driver for Broadcom wi-fi chipsets used for older Macs does not block whatever Fusion is doing to create a bridged network over Wi-Fi. 
• The driver for the N1 chipset is a brand-new implementation by Apple. It's likely that they have adhered more to what's officially supported by Wi-Fi standards. 
• Some hypervisor vendors have implemented workarounds to get Wi-Fi bridging working. I'm wondering if those workarounds no longer work with Apple's new drivers.
• There appears to be no workaround for this.

Not sure if this is going to take Apple to make changes to their driver or VMware/Broadcom to change what they're doing to "fake out" the MAC address to work around the Wi-Fi standards. Either way, Bridged networking over Wi-Fi is very likely to be broken on all new Macs as Apple starts using their in-house developed Wi-Fi chips. 

Broadcom -- are you aware of this and are you looking into what can be done?  It's a show-stopper for many users that rely on Wi-Fi. 

[Technogeezer]

Another thought since I don't have one of those M5 Macs to test. When selecting Bridged Networking, are you selecting Automatic or Wi-FI? If Autodetect, can you switch to Wi-Fi and see if anything changes? 

[Wandong Qin]

Thanks, @Technogeezer, for your detailed explanations.

 

1. I have upgraded to macOS 26.5.1, but nothing has changed — Wi‑Fi bridging is still not working.

 

2. I am also unable to select Wi‑Fi as the bridged interface. It can be selected temporarily, but the setting is never saved and always reverts back to Auto Detect.