---
name: unraid-windows-vm-virtio-no-ip
description: Unraid VMs fail to get a DHCP IP - PRIMARY cause is Docker setting bridge-nf-call-iptables=1 (drops new-VM DHCP OFFERs on br0); secondary is virtio-net having no in-box Windows driver
metadata:
  type: reference
---

Two distinct causes make Unraid/KVM VMs come up with **no DHCP IP**. Confirmed 2026-06-12/13 on
Jupiter (`172.16.3.20`, Unraid 6.12.85; host creds vault `infrastructure/jupiter-unraid-primary`).

## PRIMARY (the "VMs generally stopped getting IPs lately" cause): bridge-nf-call-iptables
Docker sets `net.bridge.bridge-nf-call-iptables=1`, which routes **bridged** VM traffic on `br0`
through the iptables FORWARD chain. Docker's `DOCKER-FORWARD` chain only ACCEPTs the docker
bridges (`br-*`, `docker0`) and has **no ACCEPT for `br0`** (the VM bridge), so it drops new
unmatched inbound flows. Effect:
- The VM's DHCP DISCOVER (broadcast) egresses fine and pfSense/Kea sends an OFFER...
- ...but the inbound **OFFER (new unicast flow to an unassigned IP) is dropped** before reaching
  the VM tap. The VM never completes DORA -> APIPA 169.254.x. Symptom in tcpdump on the DHCP
  server: VM re-DISCOVERs with 3s/8s/15s backoff, server keeps OFFERing fresh IPs, never an ACK.
- **Existing** VMs survive because lease RENEWALS are ESTABLISHED flows (pass); only NEW/rebooted
  VMs (fresh DISCOVER) break. = "lately" (a Docker/Unraid update) + "all new VMs".
- **Fix (runtime, reversible):** `echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables` (and
  `bridge-nf-call-ip6tables`). Bridged frames then bypass iptables entirely. **Caveat: Docker
  re-sets it to 1 on daemon restart** -> needs a PERSISTENT post-Docker hook (User Scripts "At
  Array Start", or a delayed setter in `/boot/config/go`) to truly fix it fleet-wide. NOT yet
  made persistent on Jupiter as of 2026-06-13 (pending Mike's OK for the prod boot config).

## SECONDARY (per-VM, Windows-specific): virtio-net has no in-box Windows driver
A Windows VM whose NIC model is the Unraid default `virtio-net` has a **dead NIC** (Windows has
no in-box virtio driver; the guest sends 0 packets). Linux VMs are fine (in-kernel virtio).
The "Windows 11" VM worked because it was set to **e1000**. Fix: NIC model `e1000` (in-box Win7/
Server2003 driver, `virsh edit`/Unraid template dropdown) OR install virtio-win NetKVM (ISOs on
Jupiter `/mnt/user/isos/virtio-win-0.1.271-1.iso`). Diagnose without tcpdump: sample
`/sys/class/net/<vnetN>/statistics/rx_packets` twice -> flat = dead NIC (driver), climbing = NIC
works (then look at the bridge-nf cause above).

Diagnosis order: confirm NIC model first (e1000 vs virtio), then if the NIC transmits but no IP,
suspect bridge-nf-call-iptables. Related: [[gururmm-install-report-failed-agent-v1]]
(WIN7TEST is the SPEC-029 legacy-32bit-agent test VM, static IP 172.16.2.55, NIC now e1000).