NAT is the only mode — verified, not assumed

Every Linux workspace's network device is attached through VZNATNetworkDeviceAttachment, with no alternative offered today. Bridged networking — giving a guest its own address directly on the host's network, indistinguishable from another physical machine — requires a separate com.apple.vm.networking entitlement that Velo doesn't currently request. That's a real, deliberate scope decision, not a bug or an oversight: NAT covers the overwhelming majority of what a development or testing workspace actually needs (outbound access, the guest reaching the internet and the host) without asking for a broader networking entitlement to get there.

NAT here isn't the slow kind

"NAT" carries a reputation for being the slower, more indirect networking mode in some virtualization tools, and it's worth being precise about why that reputation doesn't carry over here. Apple's VZNATNetworkDeviceAttachment is backed by vmnet, a kernel-level networking framework — address translation and port forwarding happen in the kernel's own network stack, not in a userspace proxy process relaying packets between the guest and the internet. That distinction is exactly why NAT-based VMs on this stack are reported to substantially outperform userspace-proxied alternatives for throughput-heavy traffic, and why NAT throughput in the low gigabits per second is realistic on modern hardware rather than a theoretical ceiling nobody actually reaches.

A stable MAC address, and why it exists

Each workspace's virtio-net device gets a MAC address deterministically derived from the workspace's own UUID, not randomized on every boot. That's a deliberate choice for two concrete reasons: it lets the guest keep the same DHCP lease across restarts instead of re-negotiating a new address every time, and it lets Velo's own IP-resolution code find a running workspace's address by searching the host's ARP table — without needing a live handle on the VZNetworkDevice object itself, which doesn't expose its own MAC address for lookup. Small detail, but it's the reason a workspace's IP tends to stay predictable across restarts rather than shifting around.

The gotcha: a host-side VPN can break this silently

Worth knowing before it costs you a confusing debugging session: NAT networking here depends on the host's own routing table pointing traffic through vmnet's NAT path correctly. A VPN client that rewrites the host's routing table — which is exactly what most VPN clients do, by design, to route the host's own traffic through the tunnel — can break a workspace's connectivity as a side effect, with nothing about the workspace's own configuration having changed. If a workspace that was reaching the internet fine suddenly can't, and nothing in Velo or the guest changed, check whether a VPN connected or reconnected on the host around the same time before assuming the workspace itself is at fault.

What this means in practice

  • Outbound access is fast and doesn't need tuning — vmnet's kernel-level NAT is the right default for the overwhelming majority of workspace use.
  • Don't expect true bridged networking yet — a workspace isn't addressable as its own device on the host's LAN today; NAT is the only mode.
  • Rule out a host-side VPN first if a previously-working workspace suddenly loses connectivity — it's a genuinely common, easy-to-miss cause that has nothing to do with the guest.

Related reading: the device inventory post for how the network device fits alongside Velo's other paravirtualized hardware, disk performance and the virtio-blk/virtio-fs split, and how vCPU core allocation actually works. Or download Velo Workspaces and try it yourself.