Configuring Zone-Based Firewall Policies in UniFi: Traffic Control Between Security Tiers

Overview

This article configures firewall policies to control traffic between zones. You'll create policies that allow specific traffic (admin access, Plex) while the zone defaults block all other cross-zone communication. UniFi's zone-based firewall¹ simplifies policy management by grouping VLANs into security tiers.

Before You Begin

Prerequisites

• VLAN Architecture completed (4 zones, 10 VLANs configured)

What We're Setting Up

How Zone Policies Work

In v3-01, we set zone-to-zone defaults to Block All (except intra-zone). Now we create specific policies to allow required traffic. We also tighten Core → Core from Allow All to specific policies - cameras don't need NAS access, and the NAS doesn't need camera access. Policies are evaluated top-to-bottom - first match wins¹.

Zone recap from v3-01:

Policy Design Notes

How is Lab protected? Lab is blocked by default from all zones (v3-01 zone defaults). Access requires explicit policies specifying zone, device, and port. Admin Devices from Core get full access (kubectl, talosctl, all ports), while Trusted only gets Plex (port 32400). A compromised Trusted device can stream media but can't touch cluster APIs.

Why Admin Access from Core? Your bastion (Mac Bastion Host) uses the Bastion port profile on the Network VLAN (Core zone). This policy allows on-site management of all VLANs without needing Tailscale.

Why Trusted → Lab for Plex? All Trusted VLANs need Plex - Apple TV and entertainment devices (Things-Trusted), phones and laptops (Unrestricted-Trusted), and filtered devices (Restricted-Trusted). Content filtering (article 02a) happens at DNS level, not firewall².

Why tighten Core → Core? The Allow All policy from v3-01 kept your flat network functional while migrating devices. Once devices are in their designated VLANs (Phase 2), replace it with specific policies: Bastion to Drive (admin access) only. Camera → NVR traffic still works - it's local traffic to the UDM, not routed³.

Why Trusted → Isolated for IoT? Devices like Philips Hue bridges live on Things-Isolated because they shouldn't access your network. But your phone needs to control them locally (faster than cloud, works offline). Allowing Trusted → Isolated lets you initiate connections while Isolated devices still can't reach Trusted - they can only respond to your requests.

Source vs Destination Filters

UniFi policies have asymmetric filter options:

Source = primary control. Use Device filter to restrict which devices can initiate traffic.

Destination = design around it. Since Device filter isn't available, we use:

• Single-device VLANs (Drive has only UNAS, so Network: Drive = UNAS)
• Port restrictions (only specific service ports allowed)
• Zone targeting (Gateway zone has only the UDM)

Return traffic is automatic. The "Auto Allow Return Traffic" checkbox (default: on) handles responses - no need for reverse rules on request/response protocols like HTTP or NFS.

Bidirectional protocols need explicit rules. mDNS discovery requires rules in both directions because both sides initiate new connections (not just responses).

Why does order matter? Policies are evaluated top-to-bottom - first match wins. Allow rules must be placed above the zone's Block All default, or traffic will be blocked before reaching your allow rule. Use the "Reorder" link to adjust policy order after creation.

What Zone Policies Don't Control

Zone policies only control routed inter-VLAN traffic⁴. Traffic to the UDM itself (local traffic) bypasses zone policies:

• Camera → NVR: Cameras talk to the UDM's interface on their VLAN (192.168.3.1) - local traffic, not routed
• DHCP/DNS: Built-in protections ensure these services work regardless of zone policies⁵
• UniFi Protect, Network, etc.: Services running on the UDM are accessed via local traffic

This is why cameras work without explicit firewall rules - they communicate with the NVR on the same subnet, not across zones.

Create Firewall Policies

Navigate to Settings → Policy Engine → Zones (table icon). Click a zone pair cell in the matrix, then Create Policy.

Admin Access

From your bastion (Bastion port profile, Network VLAN), verify:

ping 192.168.5.10   # UNAS on Drive
ping 192.168.20.x   # Device on Things-Trusted
ping 192.168.25.x   # Device on Things-Isolated

Plex Access

IoT Control

This allows phones and laptops on Trusted VLANs to control IoT devices like Philips Hue on Things-Isolated. The Isolated zone's default (Block All + Allow Return) ensures IoT devices can only respond - they cannot initiate connections to Trusted devices.

From a device on Unrestricted-Trusted, verify:

ping 192.168.25.x   # Device on Things-Isolated

Verify Default Deny

The zone defaults from v3-01 block all other cross-zone traffic. Verify from a device on Unrestricted-Trusted:

# Should fail (cross-zone blocked)
ping 192.168.5.10   # NAS on Drive VLAN (Core)

# Should succeed (gateway is local traffic)
ping 192.168.1.1    # UDM gateway - not routed

From a device on Things-Isolated, verify full isolation:

# Should fail (cross-zone blocked + L2 isolation)
ping 192.168.20.x   # Things-Trusted (different zone)
ping 192.168.25.x   # Same VLAN (L2 isolation blocks)
ping 192.168.30.x   # Unrestricted-Trusted (different zone)

Next Steps

Firewall policies control cross-zone traffic. The cluster can now be migrated to the isolated Lab VLAN.

See: Talos Migration

Resources