# 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
