# UniFi Broader Gateway Shield Result — 2026-05-23

Purpose: record the live broader `Untrusted -> Gateway` shield after the restricted-lane DHCP DNS cutover.

## Live outcome
Applied the broader restricted-lane gateway hardening successfully.

Restricted source lanes covered:
- `IoT` (`10.5.10.0/24`)
- `Camera` (`10.5.20.0/24`)
- `Old IoT` (`192.168.1.0/24`)

## Custom policies now present live
1. `Block Untrusted to Gateway Admin Surfaces`
   - blocks TCP admin surfaces on `10.5.0.1`
   - ports: `22,80,443,8443,9443`

2. `Allow Untrusted to DNS Resolver`
   - preserves restricted-lane DNS to `10.5.30.53:53`
   - direction: `Untrusted -> Internal`
   - protocol: `tcp_udp`

3. `Block Untrusted to Gateway Default Services`
   - blocks general restricted-lane access to the gateway zone

4. `Allow Untrusted to Gateway DHCP`
   - preserves DHCP while the broader gateway shield is active
   - UDP `68 -> 67`

5. `Allow Untrusted to Gateway mDNS`
   - preserves mDNS multicast behavior
   - UDP `5353 -> 224.0.0.251:5353`

## Important implementation note
During staging, one hidden dependency became obvious:
- after moving restricted-lane DHCP DNS to `10.5.30.53`, those clients still needed an explicit `Untrusted -> Internal` allow for the DNS resolver

So the broader shield was not considered complete until that allow was added live.

## Verified live after apply
Read back from the UniFi Policy Engine on PD and confirmed the following custom rule order exists live:
- idx 108: `Block Untrusted to Gateway Admin Surfaces`
- idx 109: `Allow Untrusted to DNS Resolver`
- idx 110: `Block Untrusted to Gateway Default Services`
- idx 111: `Allow Untrusted to Gateway DHCP`
- idx 112: `Allow Untrusted to Gateway mDNS`

## Net effect
For `IoT`, `Camera`, and `Old IoT`:
- gateway admin surfaces are blocked
- general gateway access is blocked
- DNS to `10.5.30.53` is preserved
- DHCP is preserved
- mDNS is preserved

## What is still not proven by controller reads alone
This does not by itself prove every device behavior is perfect.

Still validate with real clients:
- renew at least one DHCP lease per restricted lane
- confirm DNS resolution works through `10.5.30.53`
- confirm gateway UI/admin access is blocked from those lanes
- treat any additional exception as earned only by a real failing client

## Bottom line
The broader restricted-lane `Untrusted -> Gateway` shield is now live, with explicit DNS, DHCP, and mDNS preservation in place.