# UniFi Firewall Host-Group Membership Proposal Purpose: propose concrete membership for the missing host/device groups referenced by the firewall design, using current repo documentation and the recent UniFi cleanup state. This is a planning artifact only; it does not apply live network changes. Evidence used: - `docs/architecture/SERVICES_DIRECTORY.md` - `docs/architecture/NETWORKING_MODEL.md` - `docs/servers/PLAUSIBLEDENABILITY.md` - `docs/servers/SERENITY.md` - `docs/servers/ROCINANTE.md` - `pihole/README.md` - `home/doris-dashboard/docs/unifi-client-cleanup-shortlist-2026-05-22.md` - memory note: UniFi is `10.5.0.1`; PD is `10.5.30.6`; Serenity Pi-hole HA VIP is `10.5.30.53/24` ## Executive summary These groups should be split into three confidence bands: - High confidence: safe to define now from documented inventory - Medium confidence: likely right, but validate in UniFi/UI before live enforcement - Low confidence / leave empty for now: do not guess; create the group but keep it empty until a real dependent flow proves it is needed ## 1. Proposed group membership ### HOST-ADMIN-TRUSTED Purpose: - devices allowed to initiate management/admin traffic into the Management lane Proposed members: - Rocinante trusted endpoint/client - John primary phone: `Pixel-9-Pro-XL` - Optional: `Pixel-7` if you really want phone-based admin Do NOT include by default: - `FlyingDutchman` - `steamdeck` - `Valkyrie` - random laptops/TVs/tablets just because they are on Trusted Confidence: - Medium Reasoning: - the cleanup shortlist says these human/operator devices are intentionally on Trusted - Rocinante is the explicit operator station in the cutover docs - the firewall design says this group should be small and deliberate Implementation note: - if UniFi requires IPs instead of clean client objects for this group, resolve the current IP/MACs from live client state before creating the actual group ### HOST-CORE-SERVICES Purpose: - core homelab service hosts on the Servers lane Proposed members: - PlausibleDeniability / PD -> `10.5.30.6` - Serenity -> `10.5.30.5` - N.O.M.A.D. -> `10.5.30.7` - Rocinante -> `10.5.30.112` Confidence: - High Reasoning: - all four are documented infrastructure hosts - these are the obvious server endpoints repeatedly referenced across the repo ### HOST-PROTECT-SERVICES Purpose: - target for camera/security devices that need to talk to the Protect/NVR side Proposed members: - UDM Pro / UniFi gateway-controller -> `10.5.0.1` Confidence: - Medium Reasoning: - the docs clearly identify `10.5.0.1` as the UDM Pro / controller - the chimes and doorbell are UniFi Protect accessories - no separate UNVR/NVR host is documented anywhere obvious in the repo inventory Caution: - verify in UniFi before hard enforcement whether Protect is actually hosted on the UDM Pro in this environment or whether there is another Protect endpoint not yet documented ### HOST-DNS Purpose: - approved DNS resolvers for restricted lanes Proposed members: - Pi-hole HA VIP -> `10.5.30.53` - Optional explicit backing nodes if you want belt-and-suspenders: - PD Pi-hole primary -> `10.5.30.6` - NOMAD Pi-hole replica admin host -> `10.5.30.7` Recommended practical membership: - start with just `10.5.30.53` Confidence: - High for VIP - Medium for adding the backing hosts directly Reasoning: - the repo explicitly calls `10.5.30.53` the VIP for client DNS - using the VIP keeps the policy clean and decoupled from backend failover details ### HOST-NTP Purpose: - approved NTP targets for restricted lanes Proposed members: - leave empty for now if clients are intended to use public NTP directly Alternative if you insist on local NTP later: - add the actual documented local NTP server only after verifying one exists and is intended for clients Confidence: - Low / intentionally unresolved Reasoning: - the firewall design explicitly says this can be omitted if public NTP is used - the repo docs do not currently provide a clear dedicated client-facing LAN NTP service - the Pi-hole docs explicitly note Pi-hole NTP is disabled on PD because host `chronyd` owns UDP 123, but that alone is not enough proof that PD should become the universal client NTP target Recommendation: - for first-pass enforcement, model NTP as outbound internet allowed where needed rather than pretending a local NTP service is definitely part of the design ### HOST-IOT-HELPERS Purpose: - specific server-side helpers that IoT devices are allowed to contact Proposed members for first pass: - Home Assistant on PD -> `10.5.30.6` service port `8123` - Kima Hub on PD -> `10.5.30.6` service port `3333` Possible later additions only if proven necessary: - any MQTT broker actually used by IoT devices - any local appliance helper/integration endpoint that demonstrably breaks without local access Confidence: - Medium Reasoning: - Home Assistant and Kima Hub are the only clearly documented smart-home/helper services in the repo inventory - these are plausible “approved server helpers” for IoT - do not add Plex, Tautulli, or general app hosts here by default just because they exist Caution: - no explicit MQTT broker is clearly documented in the current inventory as a central IoT dependency; do not invent one into this group ### HOST-CAMERA-HELPERS Purpose: - server-side helpers cameras/security devices are allowed to contact beyond pure internet access Proposed members: - same initial target as HOST-PROTECT-SERVICES: - UDM Pro / Protect endpoint -> `10.5.0.1` Confidence: - Medium Reasoning: - until a separate Protect/NVR host is documented, the safest concrete starting point is the documented UniFi gateway/controller ### HOST-LEGACY-EXCEPTIONS Purpose: - explicit ugly one-off quarantine exceptions for legacy devices Proposed members: - none initially; create the group empty Confidence: - High for “empty by default” Reasoning: - the design explicitly treats Legacy CIA as hospice, not production - there is no documented exception that has already earned inclusion - empty is safer than pretending one-offs are already justified ## 2. Port-group follow-up proposal The firewall gap list noted two useful missing port groups. ### PORT-PROTECT Proposed status: - define later, only after verifying the actual required Protect ports for chime/doorbell traffic in this environment Confidence: - Low now Reasoning: - the repo docs do not yet give a trusted exact Protect port list for this design - better to leave broad camera policy undone than to guess wrong and strand security devices ### PORT-CAST Proposed status: - do not define yet Confidence: - High for deferral Reasoning: - the design explicitly says cast/discovery rules should only appear after real failure testing - wait for the Google/cast pilot ## 3. Suggested first-pass implementation set If you want the cleanest minimal live enforcement pass later, the least-controversial groups to create/use first are: 1. `HOST-CORE-SERVICES` - `10.5.30.5` - `10.5.30.6` - `10.5.30.7` - `10.5.30.112` 2. `HOST-DNS` - `10.5.30.53` 3. `HOST-ADMIN-TRUSTED` - only the one or two devices John truly admins from 4. `HOST-PROTECT-SERVICES` - `10.5.0.1` pending verification 5. `HOST-IOT-HELPERS` - `10.5.30.6` only, if using Home Assistant / Kima Hub as the first-pass helper target And leave these empty until proven: - `HOST-NTP` - `HOST-CAMERA-HELPERS` if different from Protect - `HOST-LEGACY-EXCEPTIONS` ## 4. Validation questions before live rule apply Before turning these into real enforced firewall objects, verify: 1. Which exact Trusted client(s) should truly admin Management? 2. Is Protect actually on the UDM Pro at `10.5.0.1`, or is there a separate undocumented host? 3. Do IoT devices need Home Assistant and/or Kima Hub locally right now, or can they live on cloud-only plus DNS/internet first? 4. Is there a real client-facing local NTP service, or should NTP just be allowed outbound? 5. Are there any Legacy CIA one-off exceptions that have actually earned existence? If not, keep that group empty. ## 5. Blunt recommendation If we want a safe first real enforcement pass later: - definitely create/use `HOST-CORE-SERVICES`, `HOST-DNS`, and a very small `HOST-ADMIN-TRUSTED` - probably create `HOST-PROTECT-SERVICES` as `10.5.0.1` after one verification step - treat `HOST-NTP`, `PORT-PROTECT`, and `PORT-CAST` as intentionally unresolved until verified - keep `HOST-LEGACY-EXCEPTIONS` empty unless a specific ugly legacy device proves it needs one