2.8 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| unraid-windows-vm-virtio-no-ip | 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 |
|
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(andbridge-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).