Files
truenas-stacks/home/doris-dashboard/docs/unifi-firewall-enforcement-result-2026-05-23.md
Fizzlepoof 462b39e572
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
secret-guardrails / gitleaks (push) Has been cancelled
docs: record unifi firewall enforcement and closeout
2026-05-23 02:08:15 +00:00

3.2 KiB

UniFi Firewall Enforcement Result — 2026-05-23

Purpose: record the actual first live enforcement change made after the read-only planning pass, plus the exact remaining work that was intentionally not guessed into production.

What was live-validated before the change

  • UniFi controller reachable at https://10.5.0.1
  • Live zone model confirmed from the controller API:
    • Internal = Management + Trusted + Servers
    • Untrusted = IoT + Camera + Old IoT
    • Hotspot = Guest
  • Existing custom policies before this change:
    • Allow Internal to Untrusted
    • disabled temp policy DORIS-TEMP
  • Existing UniFi built-in defaults already provided:
    • Guest internet-only / hotspot restrictions
    • Untrusted zone isolation from Internal, Hotspot, Dmz, Untrusted, and Vpn
    • broad Untrusted -> Gateway allow remained in place by default

Live change applied

Added one custom Policy Engine rule:

  • Block Untrusted to Gateway Admin Surfaces
    • source zone: Untrusted
    • source CIDRs:
      • 10.5.10.0/24
      • 10.5.20.0/24
      • 192.168.1.0/24
    • destination zone: Gateway
    • destination IP: 10.5.0.1
    • destination TCP ports: 22,80,443,8443,9443
    • intent: block IoT / Camera / Old IoT clients from reaching the UDM Pro admin surfaces while leaving DHCP, DNS, mDNS, and normal internet behavior to the existing zone defaults

Why this was the safe first enforcement slice

This closes the most obvious management-plane exposure left by the default zone policy without guessing at:

  • Protect/NVR helper ports
  • Google/cast discovery exceptions
  • local-vs-public NTP design
  • whether every restricted lane is already using the intended DNS target instead of the gateway

A broader Untrusted -> Gateway block was deliberately not applied because the current live DHCP/DNS details still need cleanup and verification.

Validation evidence

  • Dry-run from the PD runtime helper showed exactly one new policy create and no mutation to Allow Internal to Untrusted
  • Apply completed successfully through the same helper
  • Follow-up helper run removed the disabled temporary custom policy DORIS-TEMP
  • Post-apply custom policy readback now shows only:
    • Allow Internal to Untrusted
    • Block Untrusted to Gateway Admin Surfaces
  • Controller API access from PD remained healthy immediately after apply

Things intentionally left for later

Still not safe to guess into production without targeted validation:

  • final HOST-ADMIN-TRUSTED membership
  • full management shield for every internal lane
  • explicit Trusted admin allow objects before any broad Internal -> Gateway deny
  • exact camera/Protect helper ports
  • Google/cast discovery/control exceptions
  • final SSID retirement / simplification
  1. verify what DNS target the restricted lanes are actually receiving from DHCP today
  2. verify whether any restricted clients still need gateway access beyond DHCP/mDNS
  3. only then decide whether to convert this first surgical block into the broader management shield design
  4. do Google/cast validation from a laptop before any cast-related firewall or SSID cleanup
  5. finish SSID simplification after the cast/discovery behavior is understood