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

Management Summary
A firewall controls which network connections are allowed, helping separate work devices, guests and smart-home equipment. UniFi groups network areas into zones to organise these rules. The important distinction is between answering an allowed request and starting a new connection in the opposite direction. The article explains why those are different permissions and why communication inside the same network may follow another path. Clear separation depends on the actual traffic route, not only a tidy settings display.
Contents
Reviewed: 24 October 2026. A zone groups network interfaces, such as VLANs or VPNs. A VLAN is a logically separated network. In the zone matrix, rows identify the source zone and columns the destination zone. The matrix is not proof that every permitted connection works or that every unwanted path is blocked. A useful review follows a concrete connection from its source to the service, then checks the reply and the rules that actually match.
A gateway routes traffic between networks. A firewall permits or blocks connections according to rules. ZBF means zone-based firewall. A VPN connects devices or networks through a virtual private connection. A switch connects wired devices, while an access point connects wireless devices to the network.
Minimum versions and the right gateway
Ubiquiti lists a UniFi Gateway or Cloud Gateway, Network 9.0+ and gateway software 4.1+. ZBF appeared in the 9.0.108 official release. Updating a controller alone is insufficient. [1]
An inventory should record the gateway model, its software and the Network application separately. A version number without its product name is ambiguous. Before migration, a saved configuration and a tested administrative access path make recovery practical. A version requirement also says nothing about whether an existing policy design is appropriate.
Return traffic needs an effective allowance
Auto Allow Return Traffic creates an additional policy; an existing matching policy can already provide it. State tracking records which packets belong to an existing connection. It does not mean all replies bypass rules. [1]
For example, a management computer may initiate a connection to an Internet of Things (IoT) device, such as a networked sensor. The reply to that connection is different from a new connection initiated by the IoT device. A broad IoT-to-LAN allowance would permit more than the original requirement. The useful test records both attempts: the permitted request with its response, and an independently initiated reverse connection that should fail.
An MQTT broker receives messages and distributes them to subscribed clients. A sensor publishing to that broker is a different requirement: the sensor starts the connection. Its destination address and configured service port belong in the plan. Calling that message a “response” in everyday language does not make it return traffic for an unrelated network connection.
The gateway is a destination, not a list of guaranteed services
The Gateway zone covers traffic to or from the gateway itself. Forwarded traffic between two other networks is a different case. For a client accessing a gateway service, the client zone is the source and Gateway is the destination. The service inventory must therefore identify services actually provided there. DNS looks up IP addresses for names. A client may use the gateway for this, but a separately hosted DNS resolver changes the destination. Likewise, allowing UDP port 123 to a gateway does not create an NTP service. NTP synchronizes device clocks. The configured time server must exist and answer. A port number identifies a service endpoint; permitting that port does not start the service.
A practical service list records source network, destination host, protocol, destination port and expected function. Testing address assignment, name resolution and time synchronisation separately helps locate failures. A successful ping alone does not validate these services.
Same zone is not the same as same network
UniFi supports intra-zone policies, including Internal-to-Internal. Separate networks whose traffic passes through the gateway can therefore be filtered even when assigned to the same zone. [1]
Devices communicating directly within one VLAN present a different path. Gateway policy is not a substitute for controls at the switch or access point. Ubiquiti distinguishes gateway segmentation, switch access-control lists (ACLs) and isolation of wireless clients at an access point (AP). The relevant control depends on where traffic passes and the hardware’s capabilities. [2]
Four test cases make the distinction concrete: devices in different zones; different VLANs in one zone; wired devices within one VLAN; and wireless clients on an access point. One successful isolation test does not establish the other three.
A review that produces evidence
- Documentation of each intended connection with a specific source and destination.
- Verification of both initiation directions and the policy responsible for replies.
- Identification of the actual path: gateway, switch or access point.
- Tests of required services and a small set of explicitly forbidden connections.
- Separate tests of IPv4 and IPv6 where both are enabled; a rule matching only one IP version does not establish isolation for the other.
- A record of versions, relevant rule order, observed results and a plan to restore the previous configuration.
The UniFi Zone Matrix Planner helps document intentions. It does not inspect deployed rules, verify gateway capabilities or prove isolation. The useful output is a plan paired with observations from the actual network.
Planner limitation: The current output treats return traffic as automatically allowed and understates rule order. Those simplifications do not describe the deployed firewall reliably. The actual return-traffic policy and rule order still need verification.