NAT is the only mode

Every Linux workspace's network device is attached through VZNATNetworkDeviceAttachment, with no alternative today. Bridged networking, where the guest gets its own address on your network like another physical machine, needs the separate com.apple.vm.networking entitlement, which Velo Workspaces doesn't request. That's a deliberate scope decision. NAT covers nearly everything a development or test workspace needs (outbound access, and the guest reaching the internet and the Mac) without a broader networking entitlement.

NAT here isn't the slow kind

NAT has a reputation as the slower, indirect mode in some virtualization tools, and it doesn't carry over here. Apple's NAT attachment is backed by vmnet, a kernel-level networking framework: translation and forwarding happen in the kernel's network stack, not in a userspace process relaying packets. That's why NAT VMs on this stack are reported to beat userspace-proxied alternatives on throughput-heavy traffic, and why low-gigabit NAT throughput is realistic on current hardware.

A stable MAC address, and why

Each workspace's network device gets a MAC address derived from the workspace's UUID rather than a random one each boot. That does two things: the guest keeps the same DHCP lease across restarts, and the app can find a running workspace's address in the Mac's ARP table without a live handle on the VZNetworkDevice, which doesn't report its own MAC. It's why a workspace's IP address stays predictable, and why the ssh command in the Access tab keeps working across restarts.

The gotcha: a host VPN can break it silently

NAT networking depends on the Mac's routing table sending traffic through vmnet correctly. A VPN client that rewrites the routing table, which is what most VPN clients do so the Mac's own traffic goes through the tunnel, can break a workspace's connectivity as a side effect, with nothing about the workspace changed. If a workspace that was online suddenly isn't, and nothing changed in Velo Workspaces or the guest, check whether a VPN connected or reconnected on the Mac around then before blaming the workspace.

In practice

  • Outbound access is fast and needs no tuning. Kernel-level NAT is the right default for almost all workspace use.
  • Don't expect bridged networking. A workspace isn't its own device on your LAN; to reach it from another computer, hop through the Mac with ssh -J or a port forward.
  • Rule out a host VPN first if a working workspace suddenly loses its connection.

Related reading: how Linux VM networking works, including the Local Network prompt; the device inventory post; disk performance; and vCPU allocation. Or download Velo Workspaces and try it yourself.