macOS: VM's internal DHCP OFFER/ACK (192.168.65.1) leaks onto the host LAN as broadcasts on every VM start #843

Bug report

Docker Desktop's internal DHCP replies to its own VM leak onto the host's physical LAN as UDP broadcasts.

Every time the Docker Desktop VM starts (first start, or waking from Resource Saver), the host sends the VM's DHCP OFFER and ACK out of its physical interface (en0) as a broadcast to 255.255.255.255:68, with the Mac's own MAC and LAN IP as the source and a random UDP source port.

These packets are Docker's internal DHCP server (192.168.65.1) leasing 192.168.65.3 to the VM. They have no business leaving the Mac. On a network with rogue-DHCP detection they show up as an unknown DHCP server on the LAN: our routers' DHCP-server alert flagged the Mac on every VM start (4 out of 4 VM starts in a week, each within a second of com.docker.backend.idle] starting VM).

The leak itself is harmless to LAN clients, since chaddr is the VM's MAC and no real client accepts it. But it is a broadcast DHCP server message from a workstation, which is exactly what network security tooling is built to flag, and it repeats on every Resource Saver wake.

Expected: DHCP traffic between the VM and Docker's internal DHCP server stays inside the virtual network.

Actual: captured from another host on the same LAN, 0.7 s after the VM started (host MAC/IP redacted):

<mac-host> > ff:ff:ff:ff:ff:ff, IPv4, length 342:
  <lan-ip-host>.51993 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x12657697, Flags [none]
    Your-IP 192.168.65.3
    Client-Ethernet-Address a2:4b:b2:0b:54:a4
    Subnet-Mask 255.255.255.0, Default-Gateway 192.168.65.1, Domain-Name-Server 192.168.65.1
    MTU 65535, Lease-Time 3600
    DHCP-Message Offer
    Server-ID 192.168.65.1
<mac-host> > ff:ff:ff:ff:ff:ff, IPv4, length 342:
  <lan-ip-host>.51993 > 255.255.255.255.68: BOOTP/DHCP, Reply, ... same, DHCP-Message ACK

The source port is ephemeral, not 67, and the IP and MAC are the host's own. That suggests the userspace network stack (--networkType gvisor) treats the VM-side all-ones broadcast as ordinary outbound UDP and NATs it through a host socket onto the LAN.

Nothing on the host listens on UDP 67, no container publishes or uses port 67 (the only container on this host has been stopped for weeks), and macOS bootpd is not involved (nothing logged; /etc/bootpd.plist has DHCP disabled).

Steps to reproduce

1. On another machine on the same LAN: sudo tcpdump -i <iface> -nn -e -vvv 'udp port 68'
2. On the Mac, let Docker Desktop's VM stop (Resource Saver, 5 min idle), or quit Docker Desktop.
3. Make a call that needs the engine and is not served from the API cache, e.g. docker system df (or start Docker Desktop).
4. Within about a second of com.docker.backend.idle] starting VM in com.docker.backend.log, the other machine captures the OFFER and ACK above, coming from the Mac.

Platform

macOS

Version information

• Docker Desktop 4.91.0, Engine 29.8.0
• macOS 27.0.1 (26A434), Apple silicon (arm64)
• VM: Apple Virtualization framework, --networkType gvisor (default network settings), Resource Saver on
• Host on wired Ethernet (en0)

Diagnostics ID

Not uploaded; can provide on request.