Staff need freedom to work, students need a fence, and guests need a short leash and nothing more. Here is the full build, in the order an experienced admin would actually do it.
This is the practical build that the concept pages point at: three policies on one firewall — Staff, Students, and Guests — using the same steps as the video (create policy, set parent, install modules, write assignment rules, respect the default). The example is a school, but swap the names and it is an office with departments and a visitor Wi-Fi just as easily. Work top to bottom and test each group before building the next one.
| Policy | Matched By | Web Filter Stance |
|---|---|---|
| Staff | Staff room subnet or reserved IPs | Standard categories, social media allowed |
| Students | Lab and classroom subnet | Strict — social, games, proxies and downloads blocked |
| Default | Nobody — it catches guests and unknowns | Strictest sensible set, short and safe |
That is genuinely all the creation there is. Resist making a separate Guests policy for now — in this design guests and unknown devices are exactly what the default policy is for, and one less rack is one less thing to maintain.
Open the Staff policy and install the Web Filter module inside it, the same way the video installs modules into the HR policy. Because this instance belongs to the staff rack alone, you can now make staff-grade choices without touching anyone else: leave professional and social categories reachable, keep the genuinely dangerous categories — malware, phishing, proxies — blocked, and add your organisation's must-never-block sites to the pass list. Keep the list of changes short and deliberate; a staff policy that differs from default in twelve ways is twelve things to explain later.
Open the Students policy and install its own Web Filter instance. Here the stance flips: block social media, games, streaming and anonymiser/proxy categories, and think carefully about file downloads and webmail if your school's rules require it. The honest warning that belongs in every student build: Web Filter categories are a fence, not a vault. They stop casual access on the school network; they do nothing about a phone on mobile data, and determined students treat every filter as a puzzle. Set the policy to match your actual safeguarding rules — no stricter, no looser — and write those rules down outside the firewall too.
Now configure the policy you did not create. Open the Default policy's Web Filter and set it to the strictest stance you are comfortable defending: guests get browsing, webmail and maps; everything questionable stays blocked. Remember what the default also catches — the new staff laptop that has not been given a reservation yet, the printer you forgot, the director's new tablet. Strict but functional is the target. If the default is so tight that normal work breaks, people will demand holes in it, and holes in the default policy are holes for everyone.
Go to Policy Manager's Rules tab and add the group rules, most specific first:
If staff are matched by individual IP or MAC addresses the way the video demonstrates, reserve those addresses in DHCP the same day, or the build starts rotting the first time a lease changes.
Testing is a step, not a hope. Sit at a staff PC and open a staff-allowed site and a blocked category — both results must match the staff policy. Repeat from a lab machine against the student stance. Finally, join the network as a stranger — a personal phone, no reservation, no rule — and confirm you get the default's strict behaviour. Only when all three tests pass is the build finished. Note the date and the three results somewhere; when someone later says "it changed", you will want proof of how it behaved on day one.
The video builds exactly this pattern with an HR policy — creating it, installing the Web Filter module, and assigning its users by IP and MAC.
▶️ Watch Full VideoEither works, but using the default as the guest policy is simpler and safer for small networks: anything unknown automatically gets the guest treatment. Create a separate guest policy only when guests need something the default should not have, such as a captive portal specific to them.
With IP or MAC based rules, the machine decides, so they get the student policy on that machine. If that happens often, the real fix is username based rules with Directory Connector, so the policy follows the person rather than the desk.
As strict as your written school rules say — and not stricter just because the categories exist. Over-blocking drives students to mobile data and personal hotspots, where you have no visibility at all. A filter matched to real rules, consistently applied, protects better than a maximal one everyone routes around.