Kernaali ToolsWrite down who may initiate a connection
Use three networks with distinct subnets: Trusted, IoT and Guest. A sensible home/office design lets trusted users reach selected IoT services, prevents IoT devices from initiating sessions to trusted computers, and gives guests Internet access without local access. A camera-only network may need no Internet at all. The rules should express that difference.
| New connection | Example intent | Required exception |
|---|---|---|
| Trusted → IoT | Only selected controllers to devices | Specific service IPs and ports |
| IoT → Trusted | Block | Replies to permitted sessions remain allowed |
| Guest → local networks | Block | No casting access in this design |
| IoT / Guest → Gateway | Only necessary infrastructure | DHCP, designated DNS; no management |
| IoT / Guest → Internet | According to device purpose | Review outbound dependencies |
Choose the enforcement point
| Feature | Where it acts | Limit to remember |
|---|---|---|
| Network Isolation | Gateway-generated inter-VLAN firewall policy | Not a full same-VLAN client boundary |
| Zone-Based Firewall | Routed traffic at UniFi gateway | Requires correct zone assignment and return rules |
| Device Isolation / ACL | Supported switch path | Hardware and topology support matter |
| WiFi Client Device Isolation | Between wireless clients on the same AP | Not proof of isolation across all APs and wired paths |
For straightforward inter-VLAN blocking, Network Isolation can provide the initial policy. For selected controller-to-device access and VPN scope, explicit zone rules are easier to reason about. Avoid stacking overlapping mechanisms without knowing which one blocks a packet; an ACL can stop a flow before it reaches an otherwise correct gateway allow rule.
Guest access and same-VLAN tests
Enable AP client isolation where guests do not need peer communication, then verify the whole path. Test two clients on one AP, clients on different APs, and a wireless client against a wired host on the same VLAN. Add appropriate supported switch ACL isolation where required. A captive portal is an access workflow; it is not a substitute for traffic separation.
Check switch-model ACL support before relying on it. The current isolation documentation also notes that device/switch isolation controls depend on a network routed by a UniFi gateway or L3 switch. A third-party gateway design needs its own enforcement review.
Discovery is a separate permission
mDNS normally stays on the local link. UniFi’s mDNS proxy can repeat selected discovery across networks, but discovery alone does not allow the subsequent unicast service connection. For a trusted phone to control an IoT speaker, scope discovery to the needed networks/services and separately allow the controller-to-speaker traffic.
Do not make the Guest VLAN a participant merely because casting works elsewhere. Client isolation or multicast restrictions can prevent discovery on a single VLAN too. Document the intended exception, test with the actual product, and keep the rest blocked.
Prove the design
Run an allowed service test and a blocked new-session test for each row in your plan. Repeat on IPv6 where provisioned. Check management access from a trusted recovery device before committing gateway restrictions. If a feature breaks, locate the failed discovery or service flow instead of disabling every isolation layer.
Build the zone policy · Check VLAN transport · Protocol and port reference
These guides use the current UniFi Network concepts. Menu wording and location vary by release; check the policy’s actual scope and result. Kernaali Tools is not affiliated with Ubiquiti.
Technical references
Found an issue? Send a correction with a reproducible example.