MacOS Tahoe: default bridge conflicts with my local network

[matejcik]

Describe the bug
By default, multipass creates a bridge interface bridge100 and assigns it the address 192.168.2.1, no matter what I do.

That happens to be the same subnet on which my computer lives, and same ip that my actual internet gateway is using.
This is a problem that has mysteriously broken my internet once before i managed to trace it to multipass.

Stopping all VMs shuts down the bridge which makes the problem go away.

I need the internal network to live on its own damn subnet. 192.168.2.x is taken in this household, i'm not super keen on reconfiguring everything.

I happen to have a network with 192.168.3.x, when I connect to that, the internal network stays on 192.168.2.x, confirming that the subnet in use is hardcoded (or hard-configured somewhere), as opposed to copied from my outer network.

---

I tried sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.vmnet.plist Shared_Net_Address -string 192.168.64.1, the config value is set but not used here

while a vm is running, I see this in plutil -p /etc/bootpd.plist:

{
  "bootp_enabled" => false
  "detect_other_dhcp_server" => [
    0 => "bridge100"
  ]
  "dhcp_enabled" => [
    0 => "bridge100"
  ]
  "ignore_allow_deny" => [
    0 => "bridge100"
  ]
  "Subnets" => [
    0 => {
      "_creator" => "com.apple.NetworkSharing"
      "allocate" => true
      "dhcp_domain_name_server" => [
        0 => "192.168.2.1"
      ]
      "dhcp_router" => "192.168.2.1"
      "interface" => "bridge100"
      "lease_max" => 3600
      "lease_min" => 3600
      "name" => "192.168.2/24"
      "net_address" => "192.168.2.0"
      "net_mask" => "255.255.255.0"
      "net_range" => [
        0 => "192.168.2.2"
        1 => "192.168.2.254"
      ]
    }
  ]
}

AI is suggesting that the NetworkSharing service is doing that, but i didn't manage to reconfigure it in any way. some other sources indicate that maybe the subnet is hardcoded into qemu.

To Reproduce

1. start any multipass instance in default configuration
2. observe that ifconfig bridge100 IP address is 192.168.2.1

Expected behavior
some other ip address, preferably on a different subnet. maybe the usual 192.168.64.x that a lot of resources

Logs
Please provide logs from the daemon, see accessing logs on where to find them on your platform.

Additional info

• OS: macOS 26.1
• CPU architecture or model: Apple M4
• multipass version

  multipass   1.16.1+mac
  multipassd  1.16.1+mac
  

• multipass info

Name:           honest-hedgehog
State:          Stopped
Snapshots:      0
IPv4:           --
Release:        --
Image hash:     8e67b57e8201 (Ubuntu 25.04)
CPU(s):         --
Load:           --
Disk usage:     --
Memory usage:   --
Mounts:         /Users/jan.matejek/projekty/prace/trezor-firmware => /home/ubuntu/trezor-firmware
                    UID map: 502:default
                    GID map: 20:default

• multipass get local.driver -> qemu

Additional context
Add any other context about the problem here.

[tobe2098]

Hi @matejcik, thank you for reporting the issue in great detail. Multipass should create a bridge on the subnet 192.168.64.x by default using macOS’s Internet Sharing. I cannot reproduce the issue right now, but I would like to share this troubleshooting guide with you for help.

A possible solution could be to create your own bridge and set it for multipass to use via multipass set local.bridged-network=bridgename as you can see here.

[matejcik]

possibly related: utmapp/UTM#3294 (comment)

[matejcik]

but I would like to share this troubleshooting guide with you for help.

Thanks, but there's very little that is applicable to my situation. the networking from inside the container basically works, and the total crash that I describe only seems to happen when, something like, the OS revisits the networking stack and chooses a different 192.168.2.1 to send internet traffic to ... or something.
The only applicable advice is "Configure Multipass to use a different subnet", which, as stated above, doesn't actually do anything.

create your own bridge and set it for multipass to use

i will try that one later, seems reasonable.

[tobe2098]

This May also be helpful if you go for different bridges. If the different subnet did not work it makes me think the 192.168.2.1 you are using is the Shared_Net_Address, which multipass also uses to get the default IPs.

[ricab]

Hi @matejcik, this is not up to us: we delegate on macOS, which appears to have started using 192.168.2.0/24 in Tahoe, instead of the previous 192.168.64.0/24.

Others have commented on this being problematic in #4383. There are some configuration files, but it appears they are not honored.

People have opened bug reports with Apple. If more people do that (or pile up on existing ones), perhaps they'll notice and fix it.

[ricab]

On further inspection, this is really the same as that other issue. Closing as duplicate