# 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