250 lines
8.3 KiB
Markdown
250 lines
8.3 KiB
Markdown
# 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
|