pjhtech ToolsAllow one trusted computer to reach an IoT HTTPS service, then block other traffic between those two networks. This example modifies an existing routed configuration; create the VLANs and DHCP scopes first with the VLAN guide.
Select the networks’ actual zones
Use a supported UniFi Gateway with zone-based firewalling enabled (introduced in Network 9.0.108; gateway 4.1 or newer). Open Settings → Zones in Network 9.4, or Settings → Policy Engine → Zones in 9.3. The matrix rows are source zones and columns are destination zones.
In Settings → Networks, open Trusted and IoT and read their zone assignments. The example keeps both in Internal: Trusted is 10.42.10.0/24; IoT is 10.42.30.0/24. An Internal-to-Internal policy therefore needs network or IP selectors to distinguish them. If your networks use different zones, select those actual zones instead.
Allow one Trusted client to the IoT service
The service runs on IoT host 10.42.30.20 TCP 443; trusted controller 10.42.10.25 is its only permitted initiator. Both hosts use their VLAN gateway for the return route. First confirm the service is reachable from a permitted client, so a later timeout can be compared with a working listener.
Open Settings → Zones → Create Policy (9.4), or Settings → Policy Engine → Zones → Create Policy (9.3). For the service allow, choose source and destination zone Internal; source IP 10.42.10.25; destination IP 10.42.30.20 with destination port 443; action Allow; protocol TCP; IP Version IPv4. Leave source port at Any.
The allow does not work: move it and its replies above the blocks
Create the policies below and use Reorder in the policy table to place them in this sequence above broader matching allows. Custom rules can override built-in policies, including automatically generated return policies. An existing broad allow above these rules must be narrowed or moved after checking its other users.
| Order | Source → destination (both Internal) | Action and matching |
|---|---|---|
| 1 | 10.42.10.25 → 10.42.30.20:443 | Allow; TCP; IPv4 |
| 2 | IoT network → Trusted network | Allow; Connection State Established and Related; all protocols; IPv4 |
| 3 | Trusted network → IoT network | Block; all protocols and states; IPv4 and IPv6 |
| 4 | IoT network → Trusted network | Block; all protocols and states; IPv4 and IPv6 |
Keep the established/related return allow above both blocks. If using Auto Allow Return Traffic, check the generated policy’s position: a custom block above it can still drop the reply. Retain an equivalent existing return rule instead of adding a duplicate.
The IPv4 service exception leaves IPv6 blocked between these networks. If the service must use IPv6, create an equivalent allow for its actual IPv6 endpoints and an IPv6 established/related return rule before the blocks.
IoT can still open the gateway’s management page
These rules filter routed traffic between Trusted and IoT. The router itself is the separate Gateway destination zone. To block IoT management access while retaining current DHCP and DNS behavior, create an IoT network → Gateway block matching TCP destination ports 22 and 443, IP Version Both, above matching broad allows. Include another management port only if your gateway actually exposes that service there. This service-specific block is not a deny-all Gateway policy.
For Guest, use Network Isolation and client isolation or explicit policies covering each local destination that Guest must not reach. Retain required IPv6 control traffic. Changing only IoT-to-Trusted does not isolate Guest or same-VLAN clients.
Test what the rule is meant to stop
From a Windows client at 10.42.10.25, run Test-NetConnection 10.42.30.20 -Port 443 in PowerShell and check TcpTestSucceeded: True, then open the service using its correct HTTPS hostname. Then attempt a fresh connection to a different, known-listening IoT service; it must fail. From an IoT test host, try a new connection to a known-listening trusted service; it must fail while the allowed HTTPS session still receives replies. A timeout to a closed port cannot establish firewall isolation.
Repeat from an excluded trusted client and, if deployed, over IPv6. In the policy editor, Syslog Logging can send matching flow records to an already configured collector; use source, destination, port and action to identify an unexpected match. Finally test DHCP renewal, DNS and a new management login from Trusted.