40 lines
2.8 KiB
Markdown
40 lines
2.8 KiB
Markdown
---
|
|
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).
|