Separate IoT devices and keep selected services working

Outcome and prerequisites

Place smart devices on IoT VLAN 20 and let trusted users use an explicitly selected service. The worked example permits IPP printing from Main VLAN 10 to one printer, while preventing the printer from starting unrelated connections to Main. It also explains how to extend that approach to one casting receiver. You need a UniFi gateway, a working Main network, a VLAN-capable path to the AP, an IPP-capable printer and two test clients.

Use Main 192.168.10.0/24 and IoT 192.168.20.0/24, with .1 as each gateway and .100 to .199 as each DHCP pool. Reserve 192.168.20.120 for the printer. The procedures assume gateway routing. If a Layer 3 switch routes between the networks, enforce the corresponding controls there instead of assuming that the gateway sees every packet.

Procedure

  1. Write the required access before configuring it: Main may print to the selected printer; IoT may use internet services it needs; IoT must not initiate connections to Main; Guest cannot access either network. Record any device that needs a local hub so you do not accidentally separate dependencies without planning their communication.
  2. Create IoT under Settings and Networks with VLAN 20 and the example subnet. Keep DHCP enabled. For this exercise, leave IPv6 unconfigured on IoT until the IPv4 policy works. Keep the existing management LAN unchanged. Create a dedicated IoT WiFi and associate it with this network; use a compatible security mode for the actual devices. [1]
  3. Allow tagged VLAN 20 along every AP uplink. For a wired printer, set its switch port's native network to IoT and block tagged VLANs on that endpoint port. Connect the printer, find it in Client Devices and set a DHCP reservation for .120. Renew its lease and confirm the displayed address. UniFi's Fixed IP Address option is a DHCP reservation; the printer must still obtain its address by DHCP. [2]
  4. Prove that the printer works from a test computer temporarily on IoT. Print a document before introducing inter-network rules. This separates printer setup failures from routing or discovery problems. Record whether the printer uses IPP on TCP 631 or a different documented service. The example below applies specifically to IPP. [3]
  5. Use the zone policy method in Zone-based firewall guide to create an allow rule from Main to printer 192.168.20.120, TCP destination port 631. Permit established and related return traffic from IoT to Main. Below that exception, block new connections in both directions between the two networks. Keep internet and required gateway services working. Remove or modify any automatic network isolation rule that otherwise overrides this intended exception.
  6. First add the printer by its IP address and print again from Main. This tests the application path without depending on discovery. If the print succeeds, open the gateway mDNS proxy settings, choose Custom and select only Main and IoT. Include the printer's advertised IPP or IPPS discovery service as appropriate. Keep Guest and unrelated networks outside the scope. mDNS shares discovery advertisements; the separate firewall exception authorises the printing connection. [4]
  7. Test automatic printer discovery from Main. Reconnect WiFi or restart the print discovery process if cached results are misleading. Print a multi-page sample, cancel a queued job and check that status information behaves as expected. Permit additional printer services only when the chosen printer or application requires them.
  8. For casting, reserve an address for one receiver, such as 192.168.20.121. Add only its relevant discovery services to the mDNS scope. As a bounded diagnostic exercise, permit one test phone's reserved Main address to that receiver for TCP and UDP, with return traffic. Test discovery, playback, pause and reconnect. Tighten that exception using the receiver's documented service requirements and observed traffic. Some implementations need additional reverse sessions or discovery methods, so a universal AirPlay or Chromecast port list is inappropriate.

Verification and troubleshooting

Run four independent checks: Main-to-printer printing succeeds; Main-to-an-unapproved IoT service fails; a new IoT-to-Main connection fails; Guest-to-printer fails. Confirm the destination service is actually available before interpreting a blocked result. Repeat after reconnecting devices so an established session does not conceal an incorrect new-connection policy.

If direct IP printing works but discovery fails, examine mDNS scope, advertised services and multicast filtering. If the printer appears but printing fails, inspect the application rule and its order. If everything on IoT is unreachable, check VLAN tagging and DHCP before changing firewall policies.

For IPv6, create equivalent network and device exceptions using the real IPv6 addressing plan, then test both protocols. An IPv4 host exception does not automatically authorise or block its IPv6 address. To undo this exercise, return a device to its original WiFi or port network, renew its lease, remove its exceptions and narrow mDNS sharing again.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.