Different rules for different people: how policies and racks actually work, and the honest catch — per-group rules need the paid Policy Manager.
A flat network has one rulebook for everyone, and it always fits nobody: the accounts team needs the bank the students must never reach, and guests need internet but not the file server. On NG Firewall, different rules live in different racks — each rack is a stack of apps with its own settings, and policies decide which traffic flows through which rack. This page explains that model plainly, including the part brochures whisper: steering traffic per user or group is the job of Policy Manager, a subscription app.
Every rack holds its own copies of apps with its own settings: the Web Filter categories blocked in the staff rack say nothing about the guest rack. The default rack catches everything; additional racks exist so different traffic can be treated differently. When you read any NG Firewall setting, always ask 'in which rack?' — half of all 'the rule does not work' reports are a correct rule sitting in a rack the traffic never visits.
Policy Manager is the app that creates policies: rules that match traffic by conditions — source network or interface, user or group, time of day, day of week — and send it to a chosen rack. It is a subscription app (trial it free for 14 days like the others). Without it, you effectively run one policy for the whole network, which is fine for a tiny office and a hard limit for a school or a company with guests. Connecting users to identities can go further with Directory Connector (also paid), which reads groups from Active Directory so 'Accounts team' in a policy means the real AD group, kept current automatically.
Time conditions earn their keep quickly: the staff rack that relaxes social media at lunch is a policy condition, not a daily manual edit.
The technology takes minutes; the disagreements take weeks. Decide on paper who may reach what, get the owner of the business to approve the guest and staff rules, and only then build racks. Announce filtering before it starts — a gateway discovered by surprise reads as spying, while the same gateway announced reads as security. Keep a change log: date, rack, what changed, who asked. When a rule is questioned in three months, that log is the difference between administration and argument.
Watch racks, apps and rules being assembled in the real admin interface in the full setup video.
▶️ Watch Full VideoNot in the rack sense. Without Policy Manager the apps apply one set of settings to the traffic as a whole. You can still write individual Firewall rules for specific IP addresses, which covers a few fixed machines, but named-user and group-based steering into different racks is Policy Manager's job — that is the honest boundary of the free tier.
A policy can match simple facts — which network or interface the traffic came from, the time, the destination. Matching a named person or an AD group needs identity: users identified by Captive Portal sign-in, or Directory Connector reading your directory. Until one of those is in place, write policies per network segment (staff LAN, guest Wi-Fi) rather than per person.
Check Reports first: it shows which app in the guest rack blocked it and why. Loosen that one category or add the one site as an exception in the guest rack only — never by moving guests into the staff rack, which quietly hands them the staff rulebook and, often, LAN reachability.