truenas-stacks/home/doris-dashboard/docs/unifi-firewall-gap-list-2026-05-22.md

UniFi Firewall Gap List

Purpose: compare the intended segmentation design against the current staged UniFi firewall artifacts without making any live traffic changes.

Evidence used:

• Desired design: home/doris-dashboard/docs/network-firewall-rule-order.md
• Current groups baseline: home/doris-dashboard/docs/baselines/unifi-firewallgroup-baseline-2026-05-22-post-stage.json
• Current custom policy baseline: home/doris-dashboard/docs/baselines/unifi-firewall-policies-custom-2026-05-22-post-ui-probe.json

Executive summary

Current state is scaffolding, not finished enforcement.

What exists now:

• network/address groups for the major lanes
• a handful of port groups
• one enabled custom outbound-style policy: Allow Internal to Untrusted
• one disabled temp policy: DORIS-TEMP

What does not yet exist in the captured custom-policy baseline:

• the actual inter-VLAN segmentation matrix
• the management shield
• the quarantine posture for Legacy CIA
• the lane-specific allow/deny structure described in the design doc

So the honest answer is:

• groups/objects: mostly present
• real custom segmentation policy: largely still missing

1. Present in the current staged baseline

Network groups present

• NET-MGMT
• NET-TRUSTED
• NET-SERVERS
• NET-IOT
• NET-GUEST
• NET-CAMERAS
• NET-LEGACY-CIA
• NET-RFC1918-ALL

Port groups present

• PORT-DNS
• PORT-DHCP
• PORT-NTP
• PORT-WEB-ADMIN
• PORT-SSH
• PORT-MDNS

Custom policies present

1. Allow Internal to Untrusted
   • enabled
   • effectively basic internal -> internet/outside allowance scaffolding
2. DORIS-TEMP
   • disabled
   • temporary/non-production artifact, not part of the final design

2. Missing object inventory compared to the design

The rule-order design expects these host/device groups, but they do not appear in the captured firewall-group baseline:

• HOST-ADMIN-TRUSTED
• HOST-CORE-SERVICES
• HOST-PROTECT-SERVICES
• HOST-DNS
• HOST-NTP
• HOST-IOT-HELPERS
• HOST-CAMERA-HELPERS
• HOST-LEGACY-EXCEPTIONS

The design also mentions port groups not seen in the captured baseline:

• PORT-PROTECT
• PORT-CAST

Impact:

• exact narrow allow rules for management, Protect, helper traffic, and Google/cast exceptions cannot be cleanly expressed yet using the intended group model

3. Missing rule sections compared to the design

Section A: Core state handling

Missing or not evidenced in the captured custom-policy baseline:

• ALLOW Established/Related
• DROP Invalid

Section B: Management protection

Missing or not evidenced:

• ALLOW Trusted Admin -> Management Admin Surfaces
• ALLOW Trusted Admin -> Gateway Infra Utilities
• DROP IoT -> Management
• DROP Cameras -> Management
• DROP Guest -> Management
• DROP Legacy CIA -> Management
• DROP Any Internal -> Management

Meaning:

• the intended management shield is not yet represented in the captured custom-policy set

Section C: Trusted human lane

Missing or not evidenced:

• ALLOW Trusted -> Servers Approved Access
• ALLOW Trusted -> Cameras Admin/Viewer Access
• ALLOW Trusted -> IoT Control Exceptions

Meaning:

• the design’s explicit human/operator access model is not yet staged in a visible way

Section D: Server/helper traffic

Missing or not evidenced:

• ALLOW Servers -> IoT Approved Helpers
• ALLOW Cameras -> Protect Services
• ALLOW IoT -> Approved Server Helpers
• ALLOW Legacy CIA -> Approved One-Off Exception

Meaning:

• no captured evidence yet of the narrow internal service exceptions the design wants

Section E: DNS/NTP baseline for restricted lanes

Missing or not evidenced:

• ALLOW IoT -> DNS
• ALLOW Cameras -> DNS
• ALLOW Legacy CIA -> DNS
• ALLOW IoT -> NTP
• ALLOW Cameras -> NTP
• ALLOW Legacy CIA -> NTP

Meaning:

• the restricted-lane minimum-function posture is not yet fully expressed in custom rules

Section F: Internet access for constrained lanes

Partially present at best:

• there is one broad custom policy, Allow Internal to Untrusted

Still missing as lane-specific explicit policy:

• ALLOW Guest -> Internet
• ALLOW IoT -> Internet
• ALLOW Cameras -> Internet Updates
• ALLOW Legacy CIA -> Internet

Meaning:

• outbound access is only evidenced in a broad/global way, not in the lane-specific shape called for by the design

Section G: Broad internal denies for restricted lanes

Missing or not evidenced:

• DROP Guest -> RFC1918/Internal
• DROP IoT -> Trusted
• DROP IoT -> Servers
• DROP IoT -> Cameras
• DROP Cameras -> Trusted
• DROP Cameras -> Servers
• DROP Cameras -> IoT
• DROP Legacy CIA -> Trusted
• DROP Legacy CIA -> Servers
• DROP Legacy CIA -> Cameras
• DROP Legacy CIA -> IoT

Meaning:

• the core segmentation barriers between the restricted lanes and the rest of the network are not yet evidenced in the captured policy set

Section H: Optional discovery exceptions

Correctly absent for now:

• no evidence of broad Google/cast discovery exception rules
• this is good; the design explicitly says these should only appear after real failure testing

4. Practical interpretation

If the captured baselines are still current, then the environment appears to be in this state:

1. The naming/object foundation is mostly there.
2. The network has at least one custom outbound-style policy.
3. The actual inter-VLAN enforcement plan is still largely unimplemented.
4. The current state is safer than random ad-hoc rules, but it is not yet the finished segmentation design.

5. Safe next implementation order

Before any live firewall apply, the safest order is:

1. Create the missing host groups

   • HOST-ADMIN-TRUSTED
   • HOST-DNS
   • HOST-NTP
   • HOST-PROTECT-SERVICES
   • helper/exception groups as needed

2. Add the minimum safe rule skeleton first

   • ALLOW Established/Related
   • DROP Invalid
   • management shield block set
   • explicit Trusted admin -> Management allows
   • Trusted -> Servers allow

3. Add the restricted-lane minimum-function rules

   • DNS
   • NTP
   • outbound internet as appropriate

4. Add the broad internal deny matrix for Guest / IoT / Camera / Legacy CIA

5. Only after that, consider narrow discovery exceptions if the Google/cast pilot proves they are actually needed

6. What is safe to say right now

Accurate phrasing:

• firewall scaffolding exists
• the object/group layer is mostly staged
• a basic outbound custom policy exists
• the full inter-VLAN segmentation matrix is not yet fully implemented

Inaccurate phrasing to avoid:

• “the firewall is done”
• “inter-VLAN isolation is fully in place”
• “Legacy CIA is already fully quarantined by policy”

7. Recommended next operator action

Next safe action, still non-disruptive:

• define the missing host groups and map real devices/services into them on paper or in staging notes first

Next live-action phase after that:

• apply the minimum safe rule skeleton in a rollback-friendly order, validating management reachability after each step