TopherMayor/hermes-ice
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e4d91aadf968847e84a84f31c806d8f408ac4488
hermes-ice/homelab/docs/unifi-network-optimization-plan.md
Hermes Agent e4d91aadf9 Initial commit: homelab infrastructure wiki 
- Full Obsidian vault content
- Host configs (ice, grizzley, ubuntu, proxmox, truenas, panda, hyte)
- Media stack documentation
- Traefik HA setup
- Automation scripts
- Bachelor party planning
2026-05-24 16:08:40 -07:00

363 lines
24 KiB
Markdown
Raw Blame History

---
project:
name: UniFi Network Performance and Security Optimization Plan
status: planning
category: infrastructure
source: homelabagentroot
created: 2026-03-16
updated: 2026-03-17
description: Planning-only document for UniFi segmentation, firewall optimization, and host placement based on live controller data
goals:
- Define a recommended target zone matrix for trusted, guest, IoT, staging, server, and VPN traffic
- Identify firewall policies to keep, tighten, or retire without applying live changes yet
- Map homelab hosts and service classes to the best VLAN and SSID strategy
priority: high
tags: [unifi, network, firewall, performance, security, planning]
---
# UniFi Network Performance and Security Optimization Plan
## Overview
This document captures recommended UniFi network improvements based on a live controller review performed on 2026-03-17 and a same-day pull of the latest authoritative host repositories.
This is a planning document only.
- No firewall policies, zones, VLAN assignments, SSIDs, or client placements were changed while preparing this document.
- Current-state notes are based on live UniFi data available from the local controller at `https://192.168.1.1`.
- Host placement recommendations were cross-checked against the latest pulled host repos for `ubuntu`, `grizzley`, `ice`, `proxmox`, `truenas`, and `panda`.
- Existing cleanup work in [[../tasks/unifi-firewall-cleanup-plan.md|UniFi Firewall Cleanup Plan]] should be treated as historical context, not the final source of truth for the current live posture.
## Live Snapshot
### Controller and Inventory
- Controller: UniFi Cloud Gateway Ultra (`UDRULT`)
- UniFi Network version: `10.1.85`
- UniFi devices currently visible: `4`
- Live clients currently visible: `43`
- Wireless networks currently visible: `3`
- VPN servers currently visible: `1` (`UGC WireGuard`)
### Current Network and Zone Mapping
| Network | Subnet | VLAN | Current Zone | Notes |
|--------|--------|------|--------------|-------|
| Default | 192.168.1.0/24 | native | Management | Contains core infrastructure today |
| Family of D. | 192.168.10.0/24 | 10 | Internal | Trusted user devices now separated from Management |
| Will of D. (Guest) | 192.168.20.0/24 | 20 | Guest | Good logical placement |
| Will of D. IoT | 192.168.30.0/24 | 30 | IoT | Good logical placement |
| Staging | 192.168.40.0/24 | 40 | Staging | Good logical placement |
| Production | 192.168.50.0/24 | 50 | Servers | Good logical placement |
| UGC WireGuard | 192.168.4.0/24 | n/a | Vpn | Keep as a dedicated VPN trust boundary |
### Implementation State
First-wave UniFi changes were applied on 2026-03-17:
- `Family of D.` was moved from `Management` into `Internal`
- `Management` was reduced to `Default` only
- New `Internal` user-defined allow rules were created for:
- `Internal -> Servers HTTPS`
- `Internal -> Servers HTTP`
- `Internal -> IoT`
- `Internal -> Staging`
- Logging was enabled on selected user-defined edge and VPN policies:
- `Allow External to Web Proxy`
- `Vpn to Management`
- `MBA VPN to Management`
- `Vpn to Servers`
- `Vpn to IoT`
- Logging was also enabled on selected user-defined east-west policies for observability:
- `Management to Servers`
- `Management to IoT`
- `Management to Guest`
- `Internal to Servers HTTPS`
- `Internal to Servers HTTP`
- `Internal to IoT`
- `Internal to Staging`
- `IoT to Jellyfin`
- `IoT to Traefik`
- Staged reservation cleanup succeeded for:
- `ubuntu` -> `192.168.1.61`
- `proxmox` -> `192.168.1.11`
- `grizzley` -> `192.168.10.145`
- `ice` -> `192.168.10.178` and `192.168.50.197`
- `homeassistant` -> `192.168.30.196`
- First host-side migration execution succeeded for `truenas` by moving its default route to `192.168.50.1` while preserving reachability on both `192.168.50.12` and `192.168.1.12`
- First host-side migration execution also succeeded for `proxmox` and `ubuntu` by moving their active default routes to `192.168.50.1` while preserving SSH reachability on both their legacy and server-side addresses
- Final legacy-address removal has now succeeded for `proxmox`, `ubuntu`, and `truenas` on the old `192.168.1.x` paths
- Dual-network cleanup succeeded for `grizzley` and `ice` by removing active Wi-Fi participation on `Family of D.`
- Staging-side `192.168.40.x` host paths have been removed from `truenas`, `grizzley`, and `ice`
Two system-defined port-forward policies were not modified because the controller rejects edits to them via the integration API:
- `Allow Port Forward HTTP`
- `Allow Port Forward HTTPS`
### Immediate Current-State Risks
- Several homelab hosts still appear on more than one network, or have records that suggest multiple interfaces. That is useful when intentional, but it reduces the value of zone-based policy if it is not tightly documented.
- The stale secondary TrueNAS reservation at `192.168.1.145` has now been cleared, and the legacy `192.168.1.12` host address has been removed.
- UniFi client inventory can still lag behind host-side changes when a single MAC participates in multiple VLANs; current stale observations should be treated as controller state lag unless they persist after refresh/age-out.
- The remaining host-side cleanup question is whether the infrastructure `192.168.30.x` service-side addresses are all intentionally needed; they were retained in this wave as the conservative default pending per-service validation.
- Logging is now enabled on selected user-defined edge and VPN policies, but many block rules and system-defined edge rules still do not log.
- Internet-facing exposure still exists for reverse proxy traffic, including `HTTP` and `HTTPS`, and should be reviewed for minimum required surface area.
## Authoritative Host Repo Alignment
The latest pulled host repos describe the intended authoritative network identity below. Where live UniFi observations differ, that drift should be treated as a design and documentation issue to resolve before major firewall cleanup.
| Host | Authoritative Repo Intent | Live UniFi Observation | Planning Impact |
|------|---------------------------|------------------------|-----------------|
| ubuntu | `192.168.50.61`, primary Docker host, primary Traefik, Gitea, Vaultwarden, Authentik, OpenCode | currently visible at `192.168.1.61` | Highest-priority host placement drift because many public and internal services depend on it |
| grizzley | `192.168.50.84`, Pi edge ingress | currently visible at `192.168.10.145`, with another extra live record | Edge ingress should not share a user-trust segment unless explicitly intended |
| ice | `192.168.50.197`, control-plane OpenCode | visible at `192.168.50.197` and `192.168.10.178` | Dual placement weakens the meaning of `Servers` versus user-trusted access |
| proxmox | `192.168.50.11`, hypervisor | currently visible at `192.168.1.11` | Hypervisor should remain in an infrastructure-only network |
| truenas | `192.168.50.12`, storage-only host | visible at `192.168.1.12` and also referenced as `192.168.50.12` | Storage admin paths should be explicit and documented if multi-homed |
| panda | Home Assistant UI at `192.168.30.196`, SSH endpoint at `192.168.50.196` | live Home Assistant client at `192.168.30.196`; separate admin SSH endpoint not shown in client list | This is a valid split-access pattern and should be preserved intentionally |
### What The Latest Host Repos Change In This Plan
- `ubuntu` is more security-sensitive than the first draft implied because its latest host repo now clearly tracks hardened public edge, `Gitea`, and `Vaultwarden` state. That raises the priority of narrowing public exposure and protecting admin paths.
- `grizzley` and `ice` are clearly intended to be `Servers`-zone infrastructure nodes in their host repos, so their current appearances on `Family of D.` should be treated as drift unless there is a deliberate dual-network design.
- `panda` is not simply an IoT appliance. The latest host repo explicitly documents an app endpoint on `192.168.30.196` and a separate SSH/admin endpoint on `192.168.50.196`, which supports keeping Home Assistant functionally close to IoT while retaining a cleaner administrative path.
- `proxmox` is not just a hypervisor endpoint. Its latest repo also documents server-side infrastructure such as `traefik-lxc` at `192.168.50.115`, `alpine-adguard` at `192.168.50.157`, and other server-segment workloads that should stay out of user and guest networks.
- `truenas` latest repo content is partially historical, but the broader homelab catalogs and current host metadata still point to `192.168.50.12` as the intended storage address. The plan should therefore prefer the `Production`/server-side path over the current `Default` visibility.
## Recommended Target Zone Matrix
### Recommended Zone Roles
| Zone | Recommended Networks | Purpose |
|------|----------------------|---------|
| Management | Default | Admin workstations, controller access, network gear, hypervisor, storage |
| Internal | Family of D. | Trusted daily-use family devices |
| Guest | Will of D. (Guest) | Visitor and untrusted personal devices |
| IoT | Will of D. IoT | Smart home and appliance-style devices |
| Staging | Staging | Lab, test, and temporary workloads |
| Servers | Production | Public and internal homelab application hosts |
| Vpn | UGC WireGuard | Remote admin and controlled remote access |
| External | WANs | Internet |
### Recommended Connectivity Matrix
| From -> To | Management | Internal | Guest | IoT | Staging | Servers | Vpn | External |
|------------|------------|----------|-------|-----|---------|---------|-----|----------|
| Management | Allow | Limited | Limited | Allow | Allow | Allow | Allow | Allow |
| Internal | Deny by default | Allow | Deny | Limited | Limited | Limited | Deny | Allow |
| Guest | Deny | Deny | Allow | Deny | Deny | Deny | Deny | Allow |
| IoT | Deny | Deny | Deny | Allow | Deny | Limited | Deny | Allow |
| Staging | Limited | Limited | Deny | Deny | Allow | Allow | Deny | Allow |
| Servers | Limited | Return only | Deny | Limited | Allow | Allow | Deny | Allow |
| Vpn | Limited | Deny by default | Deny | Limited | Limited | Allow | Allow | Allow |
### Matrix Interpretation
- `Management` should be the only zone with broad administrative reach.
- `Internal` should access `Servers` through specific app ports and URLs, not broad all-port access.
- `Guest` should have internet access only.
- `IoT` should keep internet access plus narrow exceptions for services such as media streaming, reverse proxy access, and Home Assistant as needed.
- `Vpn` should be treated as a separate zone, not as implicit `Management`. Default VPN access should reach only the minimum required destinations.
## Firewall Recommendation Set
The live policy export reported `236` total policies. The visible slice used for this review showed `102` `ALLOW` and `98` `BLOCK` policies in the first `200` entries. Recommendations below focus on the posture that was visible live and should be validated against a full export before any change window.
### Keep
Keep these rule patterns, assuming they are already scoped correctly to the intended hosts and ports:
- System defaults such as `Block Invalid Traffic`, `Block All Traffic`, and `Allow Return Traffic`
- `Guest -> External`
- Intra-zone traffic where explicitly needed (`Internal`, `Guest`, `IoT`, `Servers`)
- Reverse proxy ingress to the public web entry point over `HTTPS`
- Narrow published access for `Gitea` and `Vaultwarden` behind the hardened public edge on `ubuntu`
- Narrow `IoT -> Servers` exceptions for media and automation services such as Jellyfin, Traefik, and Home Assistant
- `Vpn -> Servers` for approved administrative and remote-access workflows
### Tighten
These items present the best mix of security and operational benefit:
1. Separate `Family of D.` from `Management`
- Move `Family of D.` out of `Management` and into `Internal`
- Do this before treating `Management` rules as a true admin trust boundary
2. Restrict VPN reach
- Keep `Vpn -> Servers` for normal remote admin
- Narrow `Vpn -> Management` to only the ports and hosts needed for network and infrastructure administration
- Narrow `Vpn -> IoT` to specific automation and troubleshooting needs only
3. Reduce internet-facing exposure
- Keep `HTTPS` ingress for the reverse proxy
- Keep `HTTP` only if it is still required for redirect handling or ACME validation
- Replace any broad `External -> Servers` or `External -> Web Proxy` rules with host and port scoped rules where possible
- Prioritize review of the `ubuntu` edge because that host now clearly carries `Traefik`, `Gitea`, and `Vaultwarden` in the latest host repo
4. Reduce rule overlap and duplication
- Review overlapping VPN rules such as `Vpn to Servers` and `Allow WireGuard to Services (Fixed)`
- Review repeated return-path rules such as the visible duplicate `Management to IoT (Return)` entries
- Prefer one clearly named policy per intent over multiple partially overlapping policies
5. Turn on useful logging
- Enable logging on selected block rules and edge-facing allow rules
- Minimum recommended logging targets: `External -> *`, `Vpn -> Management`, `Vpn -> Servers`, and denied `Guest` or `IoT` inter-zone attempts
### Retire After Validation
Retire or replace these rule patterns only after confirming there is no hidden dependency:
- Broad all-port `Internal -> Servers` allow rules
- Broad all-port `IoT -> Servers` allow rules that are no longer needed once application-specific exceptions exist
- Duplicate return-path rules that do not add new behavior
- `HTTP` port-forward exposure if `HTTPS` plus redirect/ACME alternatives cover the same use case
- Legacy rules tied to decommissioned hosts, empty zones, or old service names
### Naming and Policy Hygiene
Use policy names that always match the real source, destination, and purpose.
Recommended naming pattern:
`<source zone> -> <destination zone> | <service or intent> | <action>`
Examples:
- `Internal -> Servers | HTTPS apps | ALLOW`
- `IoT -> Servers | Jellyfin 8096 | ALLOW`
- `Guest -> Internal | default deny | BLOCK`
- `Vpn -> Management | admin https | ALLOW`
## Recommended Host and Service Placement
### Core Homelab Hosts
| Asset | Current Observed Placement | Recommended Placement | Access Model | Notes |
|------|-----------------------------|-----------------------|--------------|-------|
| UniFi gateway and AP management IPs | Default | Management | Admin only | Keep network gear on the management network |
| Proxmox | Default (`192.168.1.11`) | Management or dedicated infrastructure VLAN, wired | Management and VPN only | Latest host repo still treats Proxmox as infrastructure-only; also protect its hosted `traefik-lxc` and `adguard` style workloads |
| TrueNAS | Default (`192.168.1.12`), plus preferred lookup for `192.168.50.12` | Management primary, optional secondary storage path only if intentional | Management and selected servers | Prefer the documented `192.168.50.12` server-side identity and document any secondary path explicitly |
| Ubuntu primary Docker host | Default (`192.168.1.61`) | Servers long-term, or documented dual-home during migration | Internal via reverse proxy, Management for admin | Latest host repo confirms this host carries the primary public edge plus `Gitea`, `Vaultwarden`, Authentik, and core apps |
| Grizzley | Family (`192.168.10.145`), plus another live record | Servers, wired | Reverse proxy and admin paths only | Latest host repo intent is Pi edge ingress and control traffic, not consumer trusted-client placement |
| Ice | Production (`192.168.50.197`) and Family (`192.168.10.178`) | Servers primary, optional dedicated management path only if justified | Management and approved service paths | Latest host repo intent is control-plane infrastructure, so current family-network presence should be treated as drift until justified |
| Panda / Home Assistant OS | live Home Assistant endpoint at `192.168.30.196`; latest host repo also documents SSH at `192.168.50.196` | Keep app plane in IoT; keep admin plane on server/management side | Management, Internal, and selected IoT flows | This split model is preferable to exposing full Home Assistant administration on a user or guest network |
### Additional Server-Segment Assets From Latest Host Repos
| Asset | Documented Address | Recommended Zone | Notes |
|------|--------------------|------------------|-------|
| Proxmox `traefik-lxc` | `192.168.50.115` | Servers | Keep isolated from `Internal` except through intended app ports |
| Proxmox `alpine-adguard` | `192.168.50.157` | Servers or Management | DNS infrastructure deserves tighter access than general apps |
| Home Assistant SSH admin endpoint | `192.168.50.196` | Management or Servers | Keep SSH/admin access distinct from the IoT-side app endpoint |
### Service Placement Guidance
| Service Class | Recommended Zone | Client Access Pattern |
|--------------|------------------|-----------------------|
| Reverse proxy / ingress (Traefik) | Servers | `Internal`, `Management`, and approved `Vpn` clients over `80/443` |
| Public identity and secrets apps (`Authentik`, `Gitea`, `Vaultwarden`) | Servers | `Management` and `Internal` over `HTTPS`; expose externally only through tightly scoped edge policies |
| Storage and virtualization admin (TrueNAS, Proxmox) | Management | `Management` and limited `Vpn` only |
| Media services (Jellyfin and related) | Servers | `Internal` by default, `IoT` only for TVs, streamers, and casting targets that need it |
| Home automation (Home Assistant) | IoT app plane plus management-side SSH/admin plane | `Management`, selected `Internal`, selected `IoT` |
| Test workloads | Staging | `Management`, selected `Internal`, and `Servers` as required |
### Client and SSID Placement Guidance
| Client Type | Recommended Network | Recommended SSID Strategy | Notes |
|-------------|---------------------|---------------------------|-------|
| Primary family phones, tablets, laptops | Internal (`Family of D.`) | `Family of D.` | Trusted user devices should not live in `Management` |
| Visitors | Guest | `Will of D.` | Keep internet-only |
| TVs, speakers, streamers, thermostats, hubs, plugs, lamps | IoT | `Will of D. IoT` | Keep appliance devices isolated and use narrow service exceptions |
| Baby monitors | IoT | `Will of D. IoT` | Current live placement in `Family of D.` should be reviewed and likely moved |
| Admin workstation(s) | Internal by default; optional future dedicated admin SSID/VLAN | `Family of D.` today | Add a dedicated admin network only if there is a real operational need |
## Performance Recommendations
### Wireless Design
- Keep SSID count low. The current three-SSID model is reasonable and should scale better than adding more SSIDs unless there is a strong operational need.
- Keep `Family of D.` optimized for higher-performance personal devices on `5 GHz` and `6 GHz` where supported.
- Keep `Will of D. IoT` focused on reliability rather than peak throughput. Many smart devices behave better on `2.4 GHz`, and mixed-band IoT SSIDs should be reviewed carefully for compatibility issues.
- Keep guest traffic off trusted SSIDs. That protects airtime and reduces unnecessary broadcast and discovery noise on the primary user network.
- For voice and discovery reliability, use `Multicast to Unicast` on user SSIDs that need iPhone calling or nearby device discovery.
- Keep `Multicast and Broadcast Blocker` off on user SSIDs unless there is a specific, tested reason to suppress discovery traffic.
- If roaming quality matters for voice devices, prefer `Fast Roaming` plus `BSS Transition` on trusted SSIDs and validate client behavior after each change.
### Verified SSID Posture
The live UniFi controller was updated on 2026-04-13 to support iPhone WiFi calling and gate control traffic.
| SSID | Multicast to Unicast | Fast Roaming | BSS Transition | Multicast/Broadcast Blocker |
|------|----------------------|--------------|----------------|-----------------------------|
| `Will of D.` | enabled | enabled | enabled | off |
| `Will of D. IoT` | enabled | disabled | enabled | off |
| `Family of D.` | enabled | enabled | enabled | off |
| `Will of D. IoT 2.4G` | enabled | n/a | enabled | off |
This aligns the trusted SSID with the same multicast and roaming posture already used on `Family of D.`.
### Wired and Infrastructure Placement
- Prefer wired-only placement for infrastructure hosts wherever possible.
- Reduce or eliminate unintended dual-homed infrastructure. A host that sits in multiple trust zones is harder to reason about and easier to misconfigure.
- Keep reverse proxy, server, and storage paths off Wi-Fi entirely.
### Network Hygiene That Helps Performance Too
- Move non-user appliance devices, especially the visible baby monitors, out of `Family of D.` and into `IoT`.
- Keep media exceptions narrow so background service discovery does not become broad east-west traffic.
- Review AP client distribution and radio settings only after collecting AP-side statistics, since transmit power and minimum RSSI changes should be data-driven.
## Security Recommendations
### Highest-Priority Changes to Plan
1. Re-establish `Management` as a real infrastructure-only trust boundary
2. Turn on useful firewall logging for edge and deny rules
3. Move live host addressing closer to the authoritative host repo intent for `ubuntu`, `grizzley`, `ice`, `proxmox`, and `truenas`
4. Narrow VPN access to the smallest practical set of hosts and ports
5. Review and minimize all public `HTTP` exposure, especially around the `ubuntu` public edge
6. Remove or consolidate duplicate and overlapping allow rules
### Medium-Priority Changes to Plan
1. Re-home server-class hosts so they align with the intended `Servers` zone
2. Review whether Home Assistant should remain in `IoT` or move to a dedicated automation segment later
3. Audit wildcard DNS usage to confirm only intended clients can reach sensitive admin applications
4. Decide whether `panda`'s split app/admin path should become the standard pattern for other appliance-style services
## Proposed Rollout Order
No changes have been applied yet. When this work is scheduled, the lowest-risk order is:
1. Export and back up current zones and policies
2. Enable logging on selected deny and edge allow rules
3. Reconcile live host IP placement with the latest authoritative host repos
4. Correct the `Management` versus `Internal` network assignments
5. Move obvious consumer/IoT devices out of `Family of D.`
6. Review and remove duplicate or overly broad firewall policies
7. Re-home server-class hosts where needed
8. Re-test reverse proxy, media, Home Assistant, VPN, and admin paths after each change set
## Open Questions Before Execution
- Should the Ubuntu primary Docker host stay on `Default` for operational simplicity, or should it move fully into `Servers`?
- Are the extra `grizzley` and `ice` live placements intentional dual-homing, or leftover records/interfaces to clean up?
- Should `proxmox` and `truenas` keep any `Default`-side presence, or should they be normalized to their documented `192.168.50.x` identities?
- Is public `HTTP` still required for any production workflow?
- Does Home Assistant need to remain on `IoT`, or is the current split model of IoT app access plus management-side SSH the desired long-term pattern?
## Decision Summary
If no larger redesign is desired, the minimum high-value outcome is:
- `Management` = infrastructure only
- `Internal` = family/trusted user devices
- `Guest` = internet only
- `IoT` = appliances with narrow exceptions
- `Servers` = homelab application hosts
- `Vpn` = remote access with explicit least-privilege rules
That structure provides the clearest improvement in both security and troubleshooting without requiring a full network rebuild.
Reference in New Issue View Git Blame Copy Permalink