VMs can't boot with Network Mode set to Bridged on Apple M5 Pro machines

[elusiveshiba]

Describe the issue
Can't boot VMs with Network Mode set to 'Bridged' on machines with the new Apple M5 Pro
I tested the latest ubuntu-24.04.4-live-server-arm64.iso
It boots fine with Network Mode set to 'Host Only' or 'Extended'

Configuration

• UTM Version: 4.7.5 (118)
• macOS Version: 26.3.1 (a)
• Mac Chip (Intel, M1, ...): M5 Pro

Crash log
The app doesn't crash, it just sits on the loading screen immediately after pressing run

Debug log
Unfortunately it doesn't get to a point where the option to export the debug log is shown

Upload VM
config.plist.zip

[darkmode5]

Yes I am experiencing the same issue on my m5 pro.

[jason5ng32]

Same here

[gcsmal]

I am also experiencing the same issue. I tried Oracle Virtualbox and again hit the exact same problem. Bridged networking is broken on my M5 Air.

Interestingly, it also appears to be affecting Parallels as well (https://forum.parallels.com/threads/any-users-having-issues-with-the-new-macbook-air-with-m5-and-n1-network-chip.369654/)

So it seems that there's a wider issue with support for the new N1 chips perhaps?

[mhaccs]

seems to be wider:

https://community.broadcom.com/vmware-cloud-foundation/question/wifi-bridging-mac-book-pro-m5-pro-not-working-25h2u1-tahoe-264

[elusiveshiba]

When I use an ethernet adapter, Bridged networking works fine. Seems to only be an issue when using WiFi

[jason5ng32]

Yes, the issue only happens when using WiFi

[mozzee]

Yes, same issue on M5

[gangstein]

Same issue on M5 pro

[JC-000]

This is not a bug. Wifi and Wifi NICs don't support bridged mode. This is not a limitation of UTM or macOS, it is a limitation of the connection at the MAC layer. Wifi doesn't allow a device to forward traffic for another that way so no one is going to program around this. As elusiveshiba noted, there are no issues with bridging to an ethernet NIC.

[gcsmal]

It worked before though

…

-------- Original Message --------

On Friday, 04/10/26 at 23:45 JC_000 ***@***.***> wrote: JC-000 left a comment [(utmapp/UTM#7658)](#7658 (comment)) This is not a bug. Wifi and Wifi NICs don't support bridged mode. This is not a limitation of UTM or macOS, it is a limitation of the connection at the MAC layer. Wifi doesn't allow a device to forward traffic for another that way so no one is going to program around this. As elusiveshiba noted, there are no issues with bridging to an ethernet NIC. — Reply to this email directly, [view it on GitHub](#7658 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/CA7CCMKKXQ5VEERIYS7GF7D4VF2RTAVCNFSM6AAAAACW3B5NOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRXGE4TCMRWGM). You are receiving this because you commented.Message ID: ***@***.***>

[JC-000]

I suggest you google why this does not and cannot work. Wifi does not support bridging this way. If it appeared to be working before something else was happening.

[gangstein]

It worked for me on my M4 Pro, but I recently updated to the M5 Pro and it stopped working.

[Leung-Kam-Ho]

I suggest you google why this does not and cannot work. Wifi does not support bridging this way. If it appeared to be working before something else was happening.

I have four different Mac chips — M1, M3, M4, and M5 — all using the same UTM file with a bridged network. The VMs run perfectly on the M1, M3, and M4 Macs, but the Mac with the M5 chip can’t even start the VM. So, we suggest that there might be something wrong or special about the M5 chip rather than the Mac’s Wi‑Fi system.

[JC-000]

First, the IEEE 802.11 standard is not intended to allow multiple MACs to be associated with a single client. that's MAC addresses - not Apple Macs. Search for yourself instead of arguing about this in the issues pages. If a client is truly bridging and if an access point is allowing true bridging, it is a fragile non-standard implementation on both sides that works by virtue of bug compatibility in the AP and client. The client has to be bugged to allow it, and the AP has to be bugged to accept it.

VirtualBox attempts to finesse this and explains what they do and how (see the second note on the page below) - but also that it is not true bridging on wireless and that some protocols and MTUs won't work as a result. [https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/network_bridged.html]

You might consider the fact that the M5 machines support Wifi 7 and have a different driver code base in your analysis. Then bear in mind - based on your confirmatory research regarding the 802.11 standard - that if the older hardware driver was allowing true bridging, it was a bug in the driver code that Apple delivers and cryptographically signs for macOS. UTM developers cannot change this driver behavior, and Apple is not going to take action on a feedback request to insert a bug into a device driver. This is not a UTM issue.