---
project:
  name: UniFi Execution Plan
  status: active
  category: infrastructure
  source: homelabagentroot
  created: 2026-03-17
  updated: 2026-03-17
  description: Exact staged UniFi zone and firewall change plan derived from current live state and authoritative host repos
  goals:
    - Apply the minimum set of high-value zone and policy changes safely
    - Preserve application reachability while tightening security boundaries
    - Provide an execution sequence that supports rollback and verification
  priority: high
  tags: [unifi, firewall, zones, execution, planning]
---

# UniFi Execution Plan

## Current Status

Implemented on 2026-03-17:

- `Family of D.` moved from `Management` to `Internal`
- `Management` reduced to `Default` only
- New `Internal` allow rules created for `Servers` (`80/443`), `IoT`, and `Staging`
- Logging enabled on selected user-defined edge and VPN policies
- Staged DHCP reservations enabled for `grizzley`, `ice`, and `homeassistant`
- First host-side migration step completed for `truenas`: default gateway moved from `192.168.1.1` to `192.168.50.1`
- `proxmox` default gateway moved from `192.168.1.1` to `192.168.50.1`
- `ubuntu` default gateway moved from `192.168.1.1` to `192.168.50.1`
- `proxmox` legacy `192.168.1.11` address removed from `vmbr0`
- `ubuntu` legacy `192.168.1.61` address removed from `enp6s18`
- `truenas` legacy `192.168.1.12` address removed from `enp6s17`
- `grizzley` Wi-Fi config removed
- `ice` Wi-Fi config removed
- staging-side `192.168.40.x` addresses removed from `truenas`, `grizzley`, and `ice`

Still pending:

- later interface cleanup for legacy `truenas`, `proxmox`, and `ubuntu` addresses that still remain active
- later interface cleanup for staging-side addresses that still remain active on `truenas`, `grizzley`, and `ice`
- cleanup of stale UniFi controller observations for the removed Ubuntu legacy address
- cleanup of stale or lagging UniFi controller observations for removed Wi-Fi paths on `grizzley` and `ice`
- decide whether remaining infrastructure-side `192.168.30.x` addresses should persist long-term
- deny-rule logging expansion
- public `HTTP` exposure review
- duplicate-rule cleanup and broader rule tightening
- maintenance-window execution of the one-host-at-a-time migration runbook

## Reservation Update Notes

The UniFi controller accepted staged reservation updates for:

- `grizzley` -> `192.168.10.145`
- `ice` Wi-Fi -> `192.168.10.178`
- `ice` wired -> `192.168.50.197`
- `homeassistant` -> `192.168.30.196`
- `ubuntu` -> `192.168.1.61`
- `proxmox` -> `192.168.1.11`

The active `truenas` reservation at `192.168.1.12` remains valid.

Follow-up change:

- the stale secondary TrueNAS fixed-IP reservation at `192.168.1.145` has been cleared; the remaining task is to decide how many live TrueNAS interfaces should persist long-term
- Wi-Fi reservations for `grizzley` and `ice` were cleared after host-side Wi-Fi removal
- Staging access rules were disabled after staging-side host addresses were removed

## Scope

This plan focuses on the first safe wave of changes:

- restore `Management` as an infrastructure-only trust boundary
- keep `Internal` for trusted user devices only
- preserve `Guest` internet-only access
- preserve `IoT` with narrow app exceptions
- maintain `Servers` as the homelab application segment
- treat `Vpn` as explicit least-privilege remote access

## Phase 1: Zone Corrections

1. Remove `Family of D.` from `Management`
2. Ensure `Family of D.` is mapped to `Internal`
3. Keep `Default` in `Management`
4. Keep `Production` in `Servers`
5. Keep `Will of D. IoT` in `IoT`
6. Keep `Will of D. (Guest)` in `Guest`
7. Keep `UGC WireGuard` in `Vpn` unless there is a deliberate reason to merge admin semantics elsewhere

## Phase 2: Logging Improvements

1. Enable logging on edge-facing allow rules:
   - `External -> Web Proxy`
   - `External -> HTTPS`
   - `External -> HTTP` if retained
2. Enable logging on key deny rules:
   - `Guest -> Internal`
   - `Guest -> Servers`
   - `IoT -> Internal`
   - `IoT -> Management`
3. Enable logging on sensitive admin rules:
   - `Vpn -> Management`
   - `Vpn -> Servers`

## Phase 3: Rule Tightening

1. Review and narrow broad `Internal -> Servers` rules to app ports only
2. Review and narrow broad `IoT -> Servers` rules to explicit media and automation ports only
3. Review `Vpn -> Management` and reduce to the smallest needed host/port set
4. Remove duplicate return-path rules once stateful behavior is confirmed
5. Remove or disable `HTTP` exposure if no longer required for redirect or certificate workflows

## Phase 4: Host Placement Follow-Through

1. Normalize infrastructure hosts to their intended addresses where possible
2. Keep split-plane exceptions documented explicitly, such as `panda`
3. Revisit firewall rules after host addressing settles so the final policy set matches reality

## Verification Checklist

- `Management` clients can reach infrastructure admin interfaces
- `Internal` clients can reach approved apps over `HTTPS`
- `Guest` clients have internet access only
- `IoT` clients can reach only approved services such as Jellyfin, Traefik, and Home Assistant where required
- VPN clients retain the minimum access needed for admin work
- Public apps remain reachable through the intended hardened edge

## Rollback Principles

- export before each major edit
- change one zone or rule set at a time
- verify from at least one host in each affected zone
- keep a saved copy of previous zone membership and rule ordering