truenas-stacks/home/doris-dashboard/docs/unifi-firewall-host-group-proposal-2026-05-22.md

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