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

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.