Why this matters beyond the homelab: IoT segmentation is a standard enterprise network design pattern. Isolating untrusted devices from production infrastructure, then punching specific firewall rules for legitimate data flows, is exactly what you would do with a corporate IoT VLAN or an OT network in a manufacturing environment.
What Kashyyyk Is
Home Assistant (VM 116, codename Kashyyyk) is the IoT automation layer for the Alliance Fleet. It runs on Node-B (QCM1255/CR90 Corvette) on VLAN 30 Mustafar, the dedicated IoT segment isolated from production services. InfluxDB telemetry flows from HA to the observability stack. The plan is smart home automations, presence detection, and eventually a Frigate surveillance integration.
The deployment itself is straightforward: download the HAOS qcow2, import it as a Proxmox disk, create the VM, boot. Ten minutes if you have done it before. This time it took four hours.
The VM
| Field | Value |
|---|---|
| VM ID | 116 |
| Codename | Kashyyyk |
| OS | Home Assistant OS 17.2 |
| Node | QCM1255 (Node-B, CR90 Corvette) |
| VLAN | 30 (Mustafar, IoT) |
| IP | 192.168.30.10/24 |
| RAM | 4GB |
| URL | http://192.168.30.10:8123 |
Bug 1: Wrong Network, Wrong IP
After booting VM 116, the Proxmox console showed the VM had obtained 192.168.1.190. That is the Default management VLAN, not VLAN 30.
The cause: when creating the VM in Proxmox, net0 was set to vmbr0 without a VLAN tag. Proxmox puts untagged traffic on the default network. The fix is one field: Proxmox > VM 116 > Hardware > net0 > VLAN Tag: 30. Shut down, apply, reboot.
After the fix the VM came up at 192.168.30.10 via DHCP. Correct.
# Verify from Proxmox shell
qm config 116 | grep net
# Should show: net0: virtio=...,bridge=vmbr0,tag=30
Bug 2: Isolate Network Blocking Everything
With the VM on the right VLAN, the next step was confirming access from the management workstation. Browser to 192.168.30.10:8123: connection refused. Ping from the management network: no response.
Added a UniFi LAN In firewall rule allowing the management subnet to reach 192.168.30.10. Still nothing.
The cause: UniFi VLAN 30 had Isolate Network enabled. This setting blocks all inter-VLAN traffic at the switch level regardless of firewall rules. It is designed for guest VLANs where you want clients isolated from each other and from the rest of the network. On a purpose-built IoT VLAN where you control exactly which flows are permitted via firewall rules, it is redundant and silently overrides everything.
The fix: UniFi > Networks > IoT (VLAN 30) > Isolate Network: OFF.
After turning it off, the firewall rules started working and the HA UI loaded immediately.
Bug 3: Firewall Rule Source Type
With basic access confirmed, the next step was wiring InfluxDB. Home Assistant needs to reach 192.168.20.41:8086 on the Services VLAN to push telemetry.
Added a LAN In firewall rule: source 192.168.30.10, destination 192.168.20.41, port 8086, action Accept, Before Predefined Rules ON.
InfluxDB Data Explorer: no data. The rule was not matching.
The cause: the source field was set to Gateway IP Address instead of IP Address. “Gateway IP Address” matches 192.168.30.1, the VLAN gateway, not the host at 192.168.30.10. Only traffic originating from the gateway matched the rule, which was nothing useful.
The fix: change the source Network Type to IP Address, enter 192.168.30.10 explicitly.
After the fix, InfluxDB measurements started flowing immediately. The homeassistant bucket in InfluxDB (org: TheAlliance) populated with device trackers, media players, sensors, weather entities, and person tracking.
InfluxDB Wiring
The HA InfluxDB integration uses the v2 API. Configuration in configuration.yaml:
influxdb:
api_version: 2
host: 192.168.20.41
port: 8086
token: <write-token-from-vaultwarden>
organization: TheAlliance
bucket: homeassistant
The write token is scoped to write-only on the homeassistant bucket. Stored in Vaultwarden.
What Did Not Work: Wazuh Syslog
The plan was to forward HA logs to Wazuh for fleet-wide SIEM coverage. HAOS does not support the standard syslog integration for remote forwarding. The built-in syslog integration writes to local syslog only. HAOS blocks agent installs entirely.
This is parked. The path forward is either an n8n workflow pulling HA events via the REST API or a Wazuh custom log input reading HA logs via a sidecar approach. Neither is implemented yet.
Final State
| Task | Status |
|---|---|
| VLAN 30 exists in UniFi | Done |
| VM 116 on VLAN 30 | Done |
| Accessible at 192.168.30.10:8123 | Done |
| DHCP reservation set | Done |
| Credentials in Vaultwarden | Done |
| Uptime Kuma monitor | Done (HTTP, 60s interval, green) |
| InfluxDB metrics flowing | Done |
| Wazuh syslog forwarding | Parked |
| Smart home integrations | Ongoing |
The Three Bugs in Summary
Every one of these is a silent failure. No error message, no log entry pointing at the root cause. Just “it does not work” until you know where to look.
The VLAN tag missing from Proxmox net0 is the most common Home Assistant on Proxmox gotcha. Every guide covers the HAOS deployment steps. Almost none mention that you have to tag the network interface or the VM lands on the default VLAN.
UniFi Isolate Network is less common but equally silent. The firewall rule UI lets you create rules and save them without any indication that Isolate Network is rendering them irrelevant at the switch level.
The Gateway IP Address source type is the subtlest. The rule exists, it matches something (the gateway), it just does not match what you intended. Worth checking this field any time a UniFi firewall rule is not behaving as expected.