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

24 KiB
Raw Blame History

project
project
name status category source created updated description goals priority tags
UniFi Network Performance and Security Optimization Plan planning infrastructure homelabagentroot 2026-03-16 2026-03-17 Planning-only document for UniFi segmentation, firewall optimization, and host placement based on live controller data
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
high
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 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