Secure a UniFi small-business network: VLANs, firewall, guests and IoT

A VLAN alone does not secure the network

A camera, printer and accounting workstation do not need identical access. Separate networks are a starting point; effective communication rules determine the outcome. Joining a guest SSID should not grant access to the NAS or gateway administration.

This is a starting architecture, not a universal configuration to import. Addresses are fictional. Adapt flows to your applications, equipment and installed versions. The goal is to reduce propagation paths while retaining useful DHCP, DNS, printing, recording and controlled remote access.

Inventory before changing rules

Record gateway, switch and AP models and firmware, plus the UniFi Network version. Identify the actual router: a UniFi gateway, Layer 3 switch or third-party firewall. Gateway rules cannot control traffic routed elsewhere.

For each device, record owner, purpose, current network, reserved or static address, required ports, Internet destinations, update method and criticality. Keep this inventory private. Prepare a wired administration workstation and local recovery method before changing anything.

• Export a configuration backup and record compatible restore versions.
• Document uplink profiles and AP management VLANs.
• Identify DNS, DHCP, NTP, directory, NAS, printers, NVR, voice and VPN dependencies.
• Assign an owner and review date to every exception; distinguish an observed need from a temporary workaround.

An example small-business segmentation plan

This is a design example. VLAN numbers do not provide security. Avoid subnet overlap with remote sites and VPN users. Put the NVR in a controlled segment; its user interface and camera flows may have different requirements. Separate printers further when their rules differ from other IoT devices.

Configure ports without losing APs

UniFi port settings use Native VLAN for untagged frames and Tagged VLAN Management for permitted tagged VLANs. Give an untagged camera its intended native network without unnecessary tagged access. An AP uplink must carry its SSID networks and retain reachable management.

Change one pilot port. Check DHCP, DNS and AP adoption before copying the profile. An uplink error can isolate everything downstream. Retain the previous profile and local access: reverting a port is often faster than restoring the whole configuration.

• Ubiquiti — switch and port settings ↗

Choose the correct isolation layer

Ubiquiti distinguishes gateway network filtering, switch ACLs and wireless client isolation. These controls complement one another. Isolation within an AP does not prove isolation across APs or between wireless and wired devices.

Network Isolation offers simple inter-VLAN separation; explicit policies are preferable when precise exceptions are needed. Check model-specific ACL support before relying on switch isolation. Same-subnet devices may communicate without crossing the gateway, so test that case separately.

• Ubiquiti — network and client isolation ↗
• Ubiquiti — switch ACL capabilities and limitations ↗

Zone-based firewall: protect the gateway too

The zone-based firewall documentation requires UniFi Network 9.0 or later and a compatible gateway running 4.1 or later. Menus vary: Network 9.4 includes Settings > Zones or Policy Table. Inspect the actual policy matrix, not just zone names.

Create targeted permits before general denies. Handle Gateway-bound traffic separately: blocking management must not remove gateway-provided DHCP or DNS. Check return traffic, effective rule order, IPv4 and IPv6. Preserve essential IPv6 network mechanisms.

• Ubiquiti — zone-based firewall policies ↗

A traffic matrix to adapt, not blindly import

This matrix expresses security intent. Complete application ports using vendor documentation. Domain-joined workstations need more than DNS and HTTPS: inventory directory, Kerberos, policy and other dependencies before restricting domain-controller access.

Static IP allowlists can break Internet services using CDNs. Where reliable restrictions are impractical, document the compromise, log traffic and prioritize blocking sensitive internal destinations. Allowing replies does not mean allowing new connections in the opposite direction.

Guest and IoT Wi-Fi: separate security from compatibility

A captive portal can display terms of use but does not replace wireless encryption or internal access controls. Test a guest before and after authentication. Apply a reasonable bandwidth limit and avoid letting a noisy guest device determine business-network availability.

Use a separate IoT SSID when legacy devices require settings incompatible with employee Wi-Fi. Do not weaken the entire wireless network for one peripheral. Test WPA2/WPA3, PMF, band and roaming settings with actual devices; the related guide explores these trade-offs.

• Ubiquiti — hotspots and captive portals ↗
• Modern Wi-Fi and legacy IoT devices →

mDNS: discovering a printer does not grant service access

UniFi mDNS forwarding enables discovery between selected networks; custom mode limits relayed service types. Do not advertise every service to guests. Limit printing discovery to the networks that need it.

Discovery and application connectivity are separate tests. A printer may appear while print jobs fail. Printing by IP can also work without discovery. Permit the required printing flow to the specific address instead of removing segmentation to fix mDNS.

• Ubiquiti — mDNS and relayed services ↗

Cameras, NVR and remote access

Reserve necessary addresses and test a pilot camera: adoption, live view, recording, playback and updates. Do not assume adoption traffic is identical to video traffic. Build exceptions from documented version-specific requirements and observed logs.

Avoid directly exposing NVR or equipment administration to the Internet. Limit VPN scope too; connecting to a VPN does not make a workstation trustworthy. Separate video viewers from administrators, protect remote access with available authentication controls and remove former contractors' access.

• Local Home Assistant and UniFi Protect architecture →

Validate permitted and denied traffic

Run tests from each network using authorized devices. Failed ping does not prove a TCP service is unreachable. For a meaningful deny test, use a destination with a listening service and compare with an allowed test. These commands do not change configuration; adapt the addresses.

Record source, destination, protocol, expected and observed results, and the matching rule. Also test same-VLAN clients on different APs, a wired client, IPv6 where enabled and VPN users. These examples are not measurements from your network.

• Employee: authorized application and printing work.
• Guest: Internet works; NAS, management and peers are unreachable as intended.
• Camera: recording continues; employee workstations are inaccessible.
• IoT: necessary functions and updates work without general server access.
• Administration: local recovery access and usable logs remain available.

Get-NetIPConfiguration
Resolve-DnsName example.com -Server 10.60.20.1
Test-NetConnection 10.60.30.20 -Port 443
# From a guest: management must remain unreachable
Test-NetConnection 10.60.10.1 -Port 443
# Test actual application services separately

Roll out in waves and retain rollback

Follow a controlled sequence: backup, inventory, pilot network, pilot ports, exceptions, targeted denies, tests and expansion. Do not move AP management, all SSIDs and all rules at once. Have someone onsite if remote access could be lost.

Define rollback triggers beforehand: lost administration, missing DHCP, critical application outage or unacceptable video interruption. First revert the last changed rule or port profile. Full restoration is a recovery option, not a replacement for a change log.

After stabilization, review exceptions, administrative accounts, firmware and backups. Judge segmentation by the traffic it actually permits and denies, not the number of VLANs displayed in the console.