Network Observations & Anomalies — 2026-06-03¶
Findings from a read-only UniFi API scan of the UDM SE on 2026-06-03. These are observations with evidence, ranked by how likely they are to cause "things unexpectedly stopped talking" — to the internet or internally. Nothing here has been changed on the network; each item lists how to confirm it.
Supporting current-state docs: network-live.md and firewall-live.md.
Update 2026-06-19
AdGuard is deployed on 192.168.6.17 and resolving. O1 remains relevant
until UDM WAN + all VLAN DHCP point at AdGuard and PiHole is decommissioned.
See AdGuard and Phase 7 §8.
Context at capture time¶
- UniFi Network was just updated
10.4.46→10.4.57, and the gateway had ~6 minutes of uptime — i.e. a firmware update + reboot had just happened. Firmware updates re-apply ZBF, bounce all links, and can reset or re-default settings. Several findings below may be a consequence of that event.
O1 — Whole-network DNS depends on the PiHole slated for decommission (HIGH)¶
Evidence:
- Every VLAN has
dhcpd_dns_enabled: false→ DHCP clients use the UDM gateway as their DNS server. - WAN1 (
Internet 1) has manual DNSwan_dns1 = 192.168.6.80— that is Blocktopus / the legacy PiHole. IPv6 DNS (wan_ipv6_dns1) is also an address on Blocktopus's MAC. - AdGuard Home (
192.168.6.17) is not referenced anywhere in DHCP or WAN DNS, despite network.md describing it as primary.
Why it matters: the gateway forwards all client DNS to 192.168.6.80. If
Blocktopus is rebooted, migrated, or decommissioned (an open project task), the
entire network loses name resolution — every VLAN appears to "lose the
internet" even though routing/WAN is fine. This is the single most likely cause
of a sudden, broad outage.
Confirm: From a client, nslookup google.com and check the Server line —
it will be the VLAN gateway, which forwards to 192.168.6.80. On the UDM:
Settings → Internet → WAN1 → DNS. Verify Blocktopus (192.168.6.80) is up.
O2 — Several devices have no DHCP lease / IP (MEDIUM)¶
Associated at L2 but no IPv4 in stat/sta at scan time:
| Device | VLAN | Conn | Note |
|---|---|---|---|
| SLZB-06M Zigbee coordinator | IoT 5 | wired | critical for Home Assistant / Zigbee |
| ChargePoint Charger | IoT 5 | Wi-Fi | also no network mapping |
| Fiio R7 (streamer/DAC) | Personal 2 | Wi-Fi | |
| SamsungPrinter | (none) | Wi-Fi | also has no VLAN tag |
| harbor-registry | Servers 4 | wired | Proxmox guest |
| Whrrr — LAN3 | Servers 4 | wired | NAS 3rd NIC |
| Proxbox — influxdb | Servers 4 | wired | Proxmox guest |
Why it matters: the Wi-Fi devices (ChargePoint, Fiio, Samsung printer) and the Zigbee coordinator failing to hold a lease will be unreachable. The wired Server-VLAN guests are often just invisible to the controller because they sit behind the Proxmox/NAS bridge (the UDM never sees their DHCP), so those may be false positives — verify on the host, not the controller.
Confirm: ping each from the gateway VLAN; for the Zigbee coordinator check
Home Assistant's connection to it; for Proxmox guests check ip a on the guest.
O3 — IoT hub on the wrong VLAN (MEDIUM)¶
Evidence: Aqara Hub M2 is on GenPop (192.168.1.82, VLAN 1), not IoT
(its documented target is 192.168.7.81, VLAN 5). The Fellow Aiden coffee
brewer landed on Appliances (192.168.5.39), where the older map expected
it on IoT.
Why it matters: an Aqara hub on GenPop can't reach (and isn't reachable by) its expected IoT peers; child Zigbee/Matter devices bound to it may drop. If something was moved during the VLAN migration and a hub didn't follow, its accessories go offline.
Confirm: check the Aqara app / Home Assistant for the hub and its children; re-tag the client to the IoT network in UniFi if intended.
O4 — Personal → IoT is blocked, limiting AirPlay/HomeKit (MEDIUM)¶
Evidence: Apple HomePod (192.168.7.124) and Apple TV 4K
(192.168.7.106) are on the IoT VLAN. The firewall allows mDNS discovery
(via the gateway reflector) but the only Internal→IoT unicast allow is
Personal → Appliances — there is no Personal → IoT allow, so the actual
AirPlay/HomeKit/casting streams from phones/laptops on Personal are blocked.
Why it matters: devices show up in the AirPlay/Home list (mDNS works) but playback/control fails — a classic "it sees it but won't connect" symptom.
Confirm: try AirPlaying from a Personal-VLAN device to the HomePod. If intended to work, add an Internal(Personal) → IoT allow for the AirPlay ports (or move those Apple devices to a trusted VLAN).
O5 — Management zone is more isolated than "Allow Management → All" implies (LOW)¶
Evidence: the "Allow Management → All" policy is scoped to the Internal zone. Management (VLAN 10) therefore cannot reach the IoT, Appliances, or Security zones — those are blocked.
Why it matters: an admin workstation on VLAN 10 can manage servers but cannot reach cameras or IoT/appliance devices for troubleshooting. Likely fine by design, but it's not literally "all."
O6 — Dual-WAN: WAN2 enabled but down (INFO)¶
WAN2 (eth9, failover-only) is enabled but link-down; WAN1 (eth8, weighted)
is the only active uplink. Expected if there is no second ISP — listed so it
isn't mistaken for a fault.
O7 — Inventory / older docs are stale vs reality (LOW)¶
Live scan shows entities/IPs not reflected in inventory/ or the 2026-05-15
device-VLAN mapping: harbor-registry
(Servers VLAN), shifted DHCP IPs (e.g. Molly & Cody feeder .169 vs documented
.167), and the Fellow Aiden/Aqara placements above. Reconcile inventory in a
follow-up so generators and the security register stay accurate.
Quick triage order¶
- DNS / Blocktopus
192.168.6.80(O1) — most likely cause of a broad "internet down" event. - Missing leases (O2) — for any specific device that went quiet.
- Aqara hub on GenPop (O3) — if smart-home accessories dropped.
- Personal → IoT block (O4) — if AirPlay/HomeKit specifically broke.