UniFi Zone-Based Firewall: Return Traffic, the Gateway Zone and Intra-Zone Traffic

The zone-based firewall replaced a list of rules per interface with a grid, and the grid is the honest picture. Every zone can talk to every zone, each pairing is its own decision, and the number of decisions grows with the square of the zones. Six zones are thirty-six directions.

A plan usually names eight of them. The remaining twenty-eight are not unplanned in the sense of being open – they inherit a default – but they are unexamined, and three of them decide whether the network is secure, whether it works, and whether the difference is noticeable.

From Rules per Interface to Cells in a Grid

The older model asked what may leave a network. The zone model asks, for every ordered pair of zones, what may cross – which is the same question posed thirty-six times instead of six. Zones ship predefined, among them Internal, Gateway, VPN, Hotspot, DMZ and External, and every VLAN lands in exactly one of them.

What makes the grid useful is also what makes it easy to misread: a cell says nothing about the cell mirrored across the diagonal. LAN to IoT and IoT to LAN are two separate decisions, and the whole point of the next section is that they are far less symmetric than they look.

Replies Are Not a Direction

The firewall tracks connections. A session that was allowed to open is allowed to answer, and the answer never consults the reverse cell – it matches the existing state and passes. Which means IoT to LAN can stay closed while a phone on the LAN talks to a bulb in the IoT zone all day.

zones n = 6          directions n² = 36
planned              ~ 8
diagonal             6   (inside a zone, no policy applies)

LAN 10.0.1.20:51344  →  IoT 10.0.30.7:80      allowed by LAN → IoT
IoT 10.0.30.7:80     →  LAN 10.0.1.20:51344   ESTABLISHED, no rule needed

The mistake this prevents is a common one and an expensive one: opening IoT to LAN so that replies work. Nothing needed it, and the cell that was opened now permits a compromised device to start its own connections into the network that was being protected. A cell is only ever needed by whoever speaks first.

The Zone That Must Not Be Closed

The gateway is a zone of its own, and almost everything a client needs before it can do anything lives there: DHCP, DNS, and NTP. Closing IoT to gateway is an appealing line in a plan – the IoT zone should not talk to infrastructure – and it produces a zone that associates, gets an address, shows full signal and resolves nothing.

The failure is silent in the worst way. Nothing reports an error; requests simply time out, so devices look slow rather than blocked, and the search starts with the wireless and the access point rather than with the one cell that caused it. If that direction is to be narrowed, it is narrowed by port – 53 and 123 to the gateway address – not closed.

The Diagonal Nobody Looks At

Traffic that begins and ends inside one zone never reaches a policy. Forty devices in an IoT zone are a flat network to one another, and the isolation the matrix appears to promise stops at the zone boundary. A bulb with an old firmware sees the other thirty-nine, and the firewall was never asked.

There are two ways out, and both live outside the matrix. Client isolation on the wireless network stops devices on the same SSID from reaching each other; splitting the zone gives the traffic a boundary to cross. And there is a third case that neither fixes: two devices on the same VLAN on the same switch exchange frames the gateway never sees, which is worth remembering before any rule is written to govern them.

Blocking and Rejecting Look Different from Inside

Every one of those rows also has a presentation, and that is what the two blocking actions are for. Block drops the packet without a word, so the client waits out its timeout – thirty seconds of nothing before an error that names the wrong cause. Reject answers immediately, and the application fails at once and says so.

For the boundary to the internet, silence is right: an unanswered probe reveals less than a refusal. For directions inside the network, refusal is right, because every one of those failures will be diagnosed by a person, and a timeout is the least informative thing a firewall can produce.

What the Matrix Cannot Express

Port forwards do not enter the grid the way the grid suggests. Traffic arriving from outside is translated before the zone policies see it, so what a policy examines is the destination after translation, not the public address that was dialled. Reaching the same service from inside by its public name is the related case and needs NAT reflection – a setting, not a cell.

Multicast is outside the model entirely. Discovery protocols such as mDNS do not travel between zones because a policy blocks them but because multicast does not route; a printer visible only in the LAN needs the mDNS repeater turned on for both zones, and no cell will substitute for it. And VPN clients arrive in their own zone, which means a working tunnel with no route to anything is not a broken tunnel – it is a row in the matrix that nobody filled in.