Harden UniFi restricted-lane gateway access

home/doris-dashboard/docs/unifi-broader-gateway-shield-result-2026-05-23.md

@@ -0,0 +1,66 @@
+# 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.