UniFi Zone-Based Firewall: Building Policies Between Networks on a UniFi Gateway

Do you know which of your networks can actually reach each other right now — not what you intended when you created them, but what the gateway permits? If your UniFi gateway runs Network 9.0 or later, the answer lives in the zone matrix, and it is worth reading before you add another VLAN.

The zone-based firewall changed how UniFi gateways express traffic policy, moving from direction-based rule lists to policies written between groups of networks. This guide covers the default zones, how allow and block policies are ordered, and how return traffic is handled — it assumes your VLANs already exist, and if they do not, start with our UniFi VLANs explainer.

A zone is a named container of networks and interfaces that share a trust level. Instead of writing a rule against each VLAN, you assign each network to a zone and then write policies from one zone to another.

Before Network 9.0, UniFi firewall rules were organized by direction — LAN In, LAN Out, LAN Local, WAN In, and so on — which meant you had to know where in the packet path each rule would be evaluated. That approach worked, but even a simple "keep IoT away from my laptops" goal took a block rule plus an established/related exception placed in exactly the right spot.

The zone model swaps that directional thinking for a source zone and a destination zone. Every policy you write answers one question: when traffic starts in this zone and heads for that one, what should happen?

Keep in mind that the gateway still runs a stateful firewall underneath. Zones are an organizing layer on top of connection tracking, so the familiar connection states — new, established, related, and invalid — still govern what gets through.

Here's how the pieces fit together:

• Zones. Groups of networks, VPN interfaces, or WAN interfaces that share a trust posture. Every network belongs to exactly one zone at a time.
• Zone matrix. A grid in the UniFi Network application that shows the effective default action for every source and destination pair. It is the fastest way to see what your policies add up to.
• Policies. Individual allow, block, or reject entries written for a specific zone pair. Each can match on networks, IP addresses, MAC addresses, specific client devices, ports, protocols, application categories, and schedules.
• Predefined policies. System-created entries that keep core services such as DHCP, DNS, and the console reachable. They also supply the defaults you see in the matrix.

All of these work together, and the matrix is the view you will return to most often. Accordingly, the first habit worth building is opening the matrix before and after every change, so you can see the effect of a policy rather than infer it.

If you are upgrading an existing gateway, the Network application offers to migrate your legacy rules into zone-based policies. Treat that migration as one-way, take a backup before you run it, and review every migrated policy afterward — converted rules are often broader or more redundant than you would write by hand.

A new or migrated UniFi gateway ships with a set of built-in zones. Each one has a defined job and a default relationship to the others.

The built-in zones and their typical posture are summarized below:

Zone	What it contains	Typical default posture
Internal	The Default LAN plus any network you create, until you move it	Reaches External and other Internal networks freely
External	All WAN interfaces, including a secondary WAN	Cannot initiate into internal zones; replies are allowed back
Gateway	The gateway itself — DNS, DHCP, NTP, SSH, and the local console	Reachable for core services from internal zones
VPN	WireGuard, OpenVPN, and site-to-site VPN networks	Treated as trusted remote access
Hotspot	Guest and captive-portal networks	Internet access only; blocked from Internal
DMZ	Segments you deliberately expose, such as a server network	Blocked from initiating into Internal

The detail that surprises most people is the Internal zone. Because every new network lands there by default, a freshly created IoT VLAN can talk to your Default network freely until you move it — layer-2 separation still needs a layer-3 firewall decision.

This is why custom zones matter. You can create zones such as IoT, Cameras, or Management, move networks into them, and the matrix then treats each one as its own trust boundary.

Guest networks deserve a note of their own. When you configure a network as a guest or hotspot network, UniFi places it in the Hotspot zone, which already blocks access to internal networks — our guide to UniFi guest networks covers the portal and client-isolation settings that sit alongside it.

Note that the External zone includes every WAN interface. If you run two uplinks, a policy written toward External applies no matter which link is active, which keeps your rules stable through a gateway WAN failover.

The VPN zone works the same way for remote clients. WireGuard and OpenVPN users land there, so if you want a remote laptop to reach only your NAS and not your whole LAN, write VPN-to-Internal policies rather than relying on the trusted default — our UniFi remote access guide walks through the VPN side.

Policies are evaluated top to bottom, and the first match decides the outcome. Order therefore matters as much as what each policy says.

Within any zone pair, the gateway evaluates your custom policies before it falls back to the predefined defaults. In practice, a custom allow placed above a custom block carves out an exception, while the same allow placed below the block never fires.

The Network application lets you reorder custom policies within a zone pair. Remember that the predefined defaults act as the floor — whatever your custom policies do not match falls through to the matrix posture for that pair.

The three actions behave differently, and choosing the right one saves troubleshooting time later:

• Allow. Permits matching traffic. It can also permit the matching return traffic automatically, which is covered in the next section.
• Block. Drops matching packets silently. The sender receives no response and eventually times out.
• Reject. Drops matching packets but sends back a refusal, such as a TCP reset or an ICMP unreachable message. The client fails fast instead of waiting.

For traffic between internal zones, Reject is usually the more practical choice. After all, a smart hub that gets an immediate refusal logs a clear error, while one that gets silence may retry for minutes and appear broken for unrelated reasons.

For traffic arriving from External, Block remains the better default. There is no reason to confirm to an unsolicited scanner that anything is listening.

The ordering principle we follow is narrow-to-broad. Here's the sequence we use on a typical zone pair:

1. Specific allows first. For example, allow the Home Assistant host to reach the IoT zone on the ports its integrations need.
2. Specific blocks next. For instance, block a particular camera from reaching External if it should never phone home.
3. Broad block last. Block everything else from the source zone to the destination zone, if the matrix default does not already do so.

Following this sequence keeps exceptions at the top of the list, where the next person troubleshooting will look first. What's more, it makes each policy's purpose obvious from its position, which matters once a zone pair holds more than a handful of entries.

Reusable port and IP groups help here as well. Rather than repeating the same five ports across three policies, define the group once and reference it, so a later change happens in one place.

Return traffic is the reply half of a connection that was already allowed. A stateful firewall tracks each connection, so when a trusted laptop opens a session to a printer, the printer's replies belong to that session and can pass.

In the zone model, return handling shows up in two places. First, the zone matrix marks some pairs with an allow-return posture, meaning new connections from that side are blocked but replies to connections opened from the other side are permitted.

Second, allow policies include an option to automatically allow return traffic. With it enabled, the gateway permits established and related packets flowing back from the destination zone for that policy, so you never write a mirror-image rule.

Here is where that matters. Suppose your trusted clients should reach the IoT zone, but IoT devices should never initiate a connection into Internal:

• Internal to IoT: Allow, with return traffic. Your phone can open a smart plug's local API, and the plug's replies come back.
• IoT to Internal: Reject. A compromised plug cannot open a new connection to your laptop or NAS.

Because return traffic is tied to connection state, the reject on IoT-to-Internal does not interfere with those replies. That is the stateful firewall doing exactly what it should.

The mistake to avoid is writing a broad IoT-to-Internal allow just to fix a broken integration. Before you do, check whether the device actually initiates the connection — some do, such as a device pushing events to Home Assistant over a webhook or MQTT — and if so, scope the allow to a single destination host and port.

Policies can also match on connection state directly. Adding a block for invalid-state packets near the top of a sensitive zone pair drops malformed or out-of-sequence traffic before it reaches your broader rules.

Keep in mind that device discovery is a separate problem from return traffic. Multicast discovery such as mDNS does not cross routed networks on its own, so casting and smart-home discovery across zones depend on the gateway's mDNS settings — see our notes on Matter and Thread on a UniFi network for the discovery side.

With the zones and ordering rules in hand, a practical layout comes together in a handful of steps. The example below assumes four networks: Default for trusted clients, IoT, Cameras, and Guest.

First, decide where each network belongs. Here's the layout we recommend as a starting point:

• Default stays in Internal. Laptops, phones, and your Home Assistant host live here as the trusted segment.
• IoT moves to a custom IoT zone. Smart plugs, TVs, speakers, and hubs sit behind a zone boundary instead of sharing Internal.
• Cameras move to a custom Cameras zone. This keeps camera traffic contained and lets you control whether cameras reach the internet at all.
• Guest stays in Hotspot. The built-in posture already gives guests internet access without a path inward.

Next, move each network into its zone and open the matrix. Confirm that the new pairs between IoT, Cameras, and Internal show a block posture before you write a single exception.

Then add the exceptions, working narrow-to-broad:

1. Internal to IoT: Allow with return traffic. Trusted devices can control IoT gear, and replies flow back.
2. IoT to Gateway: Allow DNS and NTP. If you restrict the Gateway zone for IoT, place allows for DNS on port 53 and NTP on port 123 above the broader block, and leave DHCP untouched so devices can still get an address.
3. IoT to Internal: Allow a single host and port, only where needed. For example, permit MQTT to the Home Assistant host if your devices publish to a broker.
4. Cameras to External: Block or Reject. Third-party cameras that should record locally have no reason to reach cloud endpoints.
5. Cameras to the recorder: Allow. If your UniFi Protect console runs on the gateway itself, cameras reach it through the Gateway zone; if the recorder sits on another network, scope an allow to that single address.

This set gives you isolation by default and access by exception. For the Home Assistant specifics — which integrations need which ports — see our walkthrough on running Home Assistant with an IoT VLAN on UniFi.

Once you have more than a few zones, name policies by intent rather than by mechanism. A name such as "HA to IoT – control" tells you in six months why the policy exists, while "Allow 10.20.0.0/24" does not.

A policy is not finished until you have tested it from both sides. Connect a client to each network in turn and try to reach something that should be blocked, then something that should be allowed.

Logging makes this faster. Policies can be set to log matches, and with logging enabled, hits show up in the gateway's logs or a syslog destination you configure — so you can see which policy caught a packet instead of guessing.

The most common mistakes we see include but are not limited to:

• Leaving new VLANs in Internal. The network exists, the SSID works, and nothing is actually isolated.
• Blocking a zone from Gateway entirely. Clients lose DNS and time sync, and the symptom looks like a Wi-Fi problem.
• Writing mirror-image allows. A reverse allow for replies is unnecessary when return traffic is enabled, and it opens a path for new connections too.
• Putting a broad block above a specific allow. The exception never fires, because the first match wins.
• Forgetting IPv6. If your networks hand out IPv6 addresses, confirm each policy covers both IP versions, or the block only applies to half your traffic.
• Expecting firewall policy to fix discovery. Multicast needs the mDNS settings, and the firewall only decides what happens after discovery succeeds.

All of these share a root cause: trusting the intent of a configuration rather than checking its effect. That is why the matrix and a quick test from each network are worth the few minutes they take.

On performance, zone policies are lightweight compared with deep inspection. If you are sizing hardware, the bigger throughput question is usually intrusion prevention, which our breakdown of UniFi IDS/IPS throughput covers in detail.

If you are still choosing hardware, our guide on how to choose a UniFi gateway and the UniFi gateway gear roundup compare the current lineup. Once the gateway is in place, build the zones first, write the exceptions second, and let the matrix confirm what you built.