docs: record unifi firewall enforcement and closeout
This commit is contained in:
Fizzlepoof
@@ -0,0 +1,131 @@
|
||||
# UniFi SSID Cleanup Proposal — 2026-05-23
|
||||
|
||||
Purpose: turn the remaining SSID cleanup into an exact low-risk keep/retire proposal before any live Wi-Fi changes.
|
||||
|
||||
## Basis
|
||||
Artifact-based planning only. No live SSID edits were made in this pass.
|
||||
|
||||
Artifacts used:
|
||||
- `unifi-live-preflight-snapshot-2026-05-22.md`
|
||||
- `unifi-readonly-recon-2026-05-22.md`
|
||||
- `unifi-client-rehome-results-2026-05-22.md`
|
||||
- `google-cast-pilot-result-2026-05-23.md`
|
||||
- `unifi-legacy-cia-closeout-2026-05-23.md`
|
||||
- `network-redesign-plan.md`
|
||||
- `network-redesign-implementation-runbook.md`
|
||||
|
||||
## Current SSIDs seen in the last verified inventory
|
||||
- `CIA Via` -> `Old IoT`
|
||||
- `UNEF's Playhouse` -> `Camera`
|
||||
- `Whiskey Neat Fuck Ice` -> `Trusted`
|
||||
- `Yer a Wifi Harry` -> `Trusted`
|
||||
|
||||
## Steady-state target
|
||||
Long-term, the network should converge on:
|
||||
- one Trusted SSID
|
||||
- one IoT SSID
|
||||
- one Guest SSID
|
||||
- one Security SSID
|
||||
- no Legacy CIA SSID
|
||||
- no duplicate Trusted SSIDs unless a real compatibility reason remains
|
||||
|
||||
## Exact keep / retire proposal
|
||||
|
||||
### 1) `Yer a Wifi Harry`
|
||||
- Proposed role: `keep`
|
||||
- Lane: `Trusted`
|
||||
- Why:
|
||||
- already one of the two Trusted SSIDs
|
||||
- should become the single main human/operator SSID
|
||||
- keeping this as the surviving Trusted SSID lets the duplicate Trusted SSID be retired later without renaming everything at once
|
||||
- Preconditions to call it final:
|
||||
- trusted phones/laptops are healthy here
|
||||
- no critical household endpoint still depends on the other Trusted SSID for compatibility
|
||||
|
||||
### 2) `Whiskey Neat Fuck Ice`
|
||||
- Proposed role: `temporary keep, then retire`
|
||||
- Lane: `Trusted`
|
||||
- Why:
|
||||
- it is currently duplicate Trusted capacity, not a distinct policy lane
|
||||
- the Google/cast pilot device `dc:e5:5b:8f:57:d2` was previously on this SSID and successfully landed on `IoT` / `CIA Via` via override
|
||||
- duplicate Trusted SSIDs create policy ambiguity and make cleanup harder
|
||||
- Retirement gate:
|
||||
- confirm all remaining clients on this SSID are either:
|
||||
- intentionally kept on Trusted and able to use `Yer a Wifi Harry`, or
|
||||
- moved off Trusted entirely
|
||||
- Safe retirement method:
|
||||
1. inspect current client list on `Whiskey Neat Fuck Ice`
|
||||
2. migrate or test any stragglers onto `Yer a Wifi Harry`
|
||||
3. disable `Whiskey Neat Fuck Ice`
|
||||
4. verify admin path and key household endpoints still behave
|
||||
5. only then consider deletion later
|
||||
|
||||
### 3) `CIA Via`
|
||||
- Proposed role: `temporary keep as quarantine/legacy bridge, then retire last`
|
||||
- Lane: `Old IoT` / legacy quarantine
|
||||
- Why:
|
||||
- recent verified artifacts still show it serving the remaining Google/discovery-sensitive devices and the unidentified quarantine leftovers
|
||||
- after the Google/cast pilot, the moved Google device reassociated and was seen on SSID `CIA Via` while logically landing on `IoT`; that means this SSID is still part of the current transition path and should not be yanked casually
|
||||
- the legacy closeout explicitly keeps six unidentified devices quarantined on `Old IoT`
|
||||
- Retirement gate:
|
||||
- all intentionally kept devices have been moved to clean `IoT`, `Security`, or `Trusted` as appropriate
|
||||
- any unclaimed leftovers are either retired/killed or deliberately left for a later maintenance window
|
||||
- no household-critical Google/cast behavior still depends on this legacy SSID path
|
||||
- Safe retirement method:
|
||||
1. complete human validation of the existing Google/cast pilot from a laptop
|
||||
2. decide whether more Google devices move to clean `IoT` now or stay deferred
|
||||
3. confirm the six quarantine leftovers are the only residents, or reduce further
|
||||
4. when `CIA Via` has no required clients left, disable it first
|
||||
5. observe for complaints / breakage
|
||||
6. delete only after a calm observation period
|
||||
|
||||
### 4) `UNEF's Playhouse`
|
||||
- Proposed role: `keep`
|
||||
- Lane: `Camera` / `Security`
|
||||
- Why:
|
||||
- it is already mapped to the security lane
|
||||
- doorbell and Protect-chime estate justify a distinct security SSID
|
||||
- keeping security separate from generic IoT matches the redesign intent and future camera growth plan
|
||||
- Preconditions to call it final:
|
||||
- doorbell/chimes remain healthy
|
||||
- no evidence that merging them into general IoT would be safer or simpler
|
||||
|
||||
### 5) Guest SSID
|
||||
- Proposed role: `create or enable separately when ready`
|
||||
- Why:
|
||||
- the target design calls for a true guest lane
|
||||
- the last verified enabled-SSID list did not show a guest Wi-Fi SSID even though the Guest network object exists
|
||||
- do not repurpose one of the current live SSIDs for Guest unless the live client list proves it is unused and the change window is calm
|
||||
- Recommended approach:
|
||||
- treat Guest as a separate controlled add, not part of the first retirement move
|
||||
|
||||
## Recommended cleanup order
|
||||
This is the safest order based on current evidence:
|
||||
|
||||
1. Keep `Yer a Wifi Harry` as the surviving main Trusted SSID
|
||||
2. Keep `UNEF's Playhouse` as the Security SSID
|
||||
3. Validate the existing Google/cast pilot from the laptop and decide whether more Google devices can leave legacy paths
|
||||
4. Leave `CIA Via` alive until the legacy/quarantine path is truly drained
|
||||
5. Retire `Whiskey Neat Fuck Ice` before retiring `CIA Via`
|
||||
6. Only after `CIA Via` is empty and no longer required, disable and later delete it
|
||||
7. Add/enable a proper Guest SSID as a separate tidy-up step if still missing
|
||||
|
||||
## Things not to do
|
||||
- do not delete `CIA Via` just because the easy-value IoT devices already moved
|
||||
- do not disable both Trusted SSIDs in the same change block
|
||||
- do not rename and repurpose a live SSID in one step if disabling/creating separately would be clearer
|
||||
- do not infer that Google/cast is solved globally from one successful pilot reassociation
|
||||
- do not collapse Security into generic IoT unless there is a deliberate design change
|
||||
|
||||
## Practical one-page operator version
|
||||
If you want the shortest operator call:
|
||||
- Keep now: `Yer a Wifi Harry`, `UNEF's Playhouse`, `CIA Via`
|
||||
- Retire first: `Whiskey Neat Fuck Ice` once client list is clean
|
||||
- Retire last: `CIA Via` only after Google/legacy drain is complete
|
||||
- Add separately if needed: proper Guest SSID
|
||||
|
||||
## Resulting remaining live work
|
||||
Before any actual SSID cleanup, still do:
|
||||
- laptop-side Plex / cast / discovery validation for the existing Google pilot
|
||||
- one last live SSID/client inventory pull from the controller
|
||||
- a per-SSID client count check immediately before disable actions
|
||||
Reference in New Issue
Block a user