Build a UniFi zone based firewall policy

Outcome and preparation

Create an understandable policy for three test networks while preserving administrator access. Main VLAN 10 belongs to a custom Trusted zone, IoT VLAN 20 to Devices and Guest VLAN 30 to Visitors. The existing management network remains in its current zone. This is a worked policy design, not a requirement to rename an established production network.

Use a supported UniFi gateway and a release with zone-based firewall support. Ubiquiti documents different menu paths by release: Settings and Zones or Policy Table in one layout, and Policy Engine then Zones in another. Locate Zones or Create Policy in your installed Settings interface. Record the actual Network and gateway versions in your change notes. [1]

Policy to implement

Source Destination New connection outcome
Main test computer 192.168.10.110 IoT printer 192.168.20.120 TCP 631 Allow
Main Other IoT services Block for this exercise
IoT Main and management devices Block
Guest Main IoT management and remote private networks Block
Main IoT and Guest Internet Allow normal outbound access
Guest and IoT Gateway administration Block specified management services
Existing administrator connection Gateway administration Preserve

Established responses to permitted sessions must remain possible. The table describes who can initiate a session; it does not authorise unrestricted new sessions in the reverse direction.

Procedure

  1. Download a backup and keep a wired administrator session on the original management LAN. Record current zone memberships and policies. Do not start by moving the management network or by blocking all access to the gateway.
  2. Create Trusted, Devices and Visitors zones, then assign only the intended test networks. Review every matrix direction after assignment. Source is the network where traffic originates and destination is where it goes. Connections to a gateway's own address belong to Gateway, whereas routed connections to another client use that client's zone. [1]
  3. Create the printer exception: source Trusted, source address 192.168.10.110, destination Devices, destination address 192.168.20.120, protocol TCP, destination port 631, action Allow. Give it a descriptive name such as Main test computer to IoT printer. Enable the return-traffic option if available, then inspect the resulting reverse policy.
  4. Before adding broad blocks, ensure established and related return sessions are permitted above any rule that could otherwise discard them. Where necessary, create an explicit Devices-to-Trusted state-based allow for established and related traffic. A return policy placed below an all-traffic custom block may not protect the response. Restrict subsequent deny rules to new sessions when that fits the policy.
  5. Add a Trusted-to-Devices rule blocking other new sessions after the printer exception. Add Devices-to-Trusted and Devices-to-management rules blocking new sessions. Create Visitors rules denying new access to each local zone and to private networks reachable through VPNs. Do not rely on a list of IPv4 private ranges as your entire policy because that does not cover IPv6 or every routed destination.
  6. Protect gateway administration using the source network and actual administrative ports. For this example, deny Guests and IoT access to HTTPS and SSH management on the gateway. Preserve its required DHCP and DNS services. Keep the existing administrator connection allowed. If an application needs another local management port, include that port in the appropriate restriction. Required ports depend on the hosted applications. [2]
  7. Keep the existing External policies unless the exercise specifically changes internet access. Apply IPv4 and IPv6 coverage to the general zone restrictions. Device-specific IPv6 exceptions require the device's real IPv6 addresses or a supported matching object. Preserve essential IPv6 control traffic instead of applying a blanket ICMPv6 denial. [3]
  8. Review the consolidated policy table for generated and manually created rules. Place specific exceptions above broader denials, check schedules and remove conflicting duplicate approaches. A policy name does not determine its behaviour; the actual matching criteria and order do. [4]

Verify the result

Use the matrix above as an acceptance checklist. Open a fresh printing session from .110, then try another actual service on the same printer and a new session from IoT back to Main. Check internet and DNS from every network. Attempt gateway administration from Guest and from the preserved administrator connection. Test both addresses where a target has IPv4 and IPv6.

On supported hardware, Traffic Flows can help identify the source, destination and policy involved. It is not available on every gateway, and its storage requirements matter. Where unavailable, use repeatable endpoint tests and the logging facilities your installation provides. [5]

Recovery

If a necessary service fails, disable the most recent custom rule and repeat the same test. Correct one policy at a time. Keep a record of the final order and the actual observed outcomes. Restore the saved configuration only when a targeted correction is impractical; restoring can also revert other changes made since that backup.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.