Getting Meraki Content Filtering Right the First Time
You’ve got users to protect, apps to keep available, and not a lot of time. Here’s how to configure Meraki content filtering on an MX, apply it cleanly across users and devices, and verify it’s doing what you expect.
For many IT teams, content filtering is one of those set-and-forget tools that only gets attention when something breaks. But the truth is, it’s your first line of defense against risky domains, phishing attempts, and productivity drains that sneak past other controls. A well-tuned policy keeps your users safe without slowing them down, and makes sure the MX is earning its keep.
You’ll get a baseline policy you can deploy today, plus a simple way to manage exceptions without punching holes in security.
First, Pick Your Filtering Engine
Before you set a single rule, choose the engine that powers your decisions. This choice controls category accuracy, update frequency, and the depth of controls you’ll have later. Get this wrong and you’ll spend your week chasing false positives or missed blocks.
For most networks running firmware MX 17+, Meraki uses the Cisco Talos category engine, the modern, default filtering database. The BrightCloud engine is deprecated but may still appear for older MX models or firmware. Stick with Talos for better accuracy and more frequent updates.
Navigate to Security & SD-WAN > Content filtering
Start in the Meraki Dashboard at the network where your MX lives. Go to Security & SD-WAN > Content filtering. This is the home base for everything in this guide.
Enable the Content Filtering service
If content filtering isn’t enabled, turn it on here. This activates the policy engine at the MX so domain requests can be evaluated against Talos categories and your custom lists.
Confirm Cisco Talos (Modern) is active
If your firmware shows both options, choose the Talos-based categories. These are updated daily with stronger threat intelligence and more precise labeling. BrightCloud remains for legacy environments but is no longer being developed.
Why this matters: Better categorization means fewer surprises. Your ticket queue will thank you.
Configure the Blocked website response
Decide what users see when a site is blocked: a standard block page or a silent drop. Remember that for HTTP traffic, users will see the Meraki block page, but for HTTPS domains, browsers will show a connection error instead. Encryption prevents a custom page from displaying.
Applying Your Base Filtering Rules
With the engine selected, lay down your default stance. Think of this as your network-wide baseline: broad security categories and content categories that apply to everyone, everywhere.
You’ll start wide, then add precision using group policies for exceptions.
Set your default network‑wide Security blocks
Security blocks handle the obvious bad stuff—malware sites, phishing, cryptomining, and similar. Enable the highest sensible protections here. Keep them network‑wide so you don’t miss drive‑by threats on a looser VLAN.
Tips that reduce noise:
Emerging domains: Keep an eye on new or suspicious domains that Talos hasn’t categorized yet. Review logs to catch false positives or malicious new sites early.
Safe search: While Meraki MX doesn’t enforce SafeSearch directly in content filtering, you can apply DNS-based or Google Workspace-level enforcement for search content control.
Set your default network‑wide Content blocks
Choose categories you don’t want on company time—adult content, illegal content, known bandwidth drains, if that’s a concern, etc. Don’t overdo it on the first pass. Keep it focused and defensible.
Good starting points: Adult, Hate/Violence, Illegal, Gambling (if policy requires), and High‑Risk File Sharing.
Go to Network‑wide > Group policies
Baseline done. Now prepare for exceptions without weakening the default. Group policies let you tailor access for roles like Marketing, Design, or Developers, or for device classes like guest tablets.
Create a new Group Policy for an Exception Group
Create a policy named for the role or device group (e.g., Design – Media Access). Keep the description clear so that future you—or your teammate—knows why it exists.
Add only what’s different from the base: loosen a specific category, add a couple of allowed URLs, or tighten something that the group shouldn’t hit.
Apply specific filtering rules to that group
Inside the policy, set content filtering overrides. Examples:
Design – Media Access: Allow streaming media and image hosting sites needed for campaign QA.
Developers – Code Tools: Allow code‑sharing and package registries that the base policy blocks.
Guests – Tight: Keep the base security stance, block bandwidth hogs, and allow only a short list of destinations.
Apply the group policy to clients
Assign by client, VLAN, SSID, or via RADIUS attributes if you want the policy to follow the user. For small networks, SSID or VLAN assignments are simplest. In more mature setups, user‑based assignment via RADIUS gives you consistent policy enforcement across locations.
Handling Specific URL Overrides
Even the best category engine won’t map every edge case. You’ll need a clean, auditable way to make exceptions for a domain your team depends on—or block something before it’s re‑categorized.
Think of overrides as surgical: narrow, documented, and reviewed.
Add domains to the Allow list
Use the Allowed URLs and patterns section to add domains or specific URLs that are being wrongly blocked by category. Keep entries as broad as needed but not broader. Prefer domains over one‑off URLs when the whole site is required.
Example:
*.trainingvendor.com — entire training platform used by HR
assets.cdn.partner.com — specific CDN subdomain required for a web app
Add specific URLs to the Block list
Use Blocked URLs and patterns for targeted takedowns—think shadow IT tools or a risky file‑sharing endpoint that slipped through categories. Document the business reason in a change log.
Example:
*.unapproved‑storage.example — blocks a known data‑exfil path
badapp.io/* — blocks a tool your org has formally disallowed
Remember: the Allow list always wins
In policy evaluation, explicit Allow entries override category blocks. That’s handy for fixing false positives—and dangerous if someone adds a broad allow that negates security categories. Keep your allow list tight and reviewed.
Verifying and Fixing Your Policies
Don’t guess. Test and observe. A few minutes here saves hours of Slack noise and mystery tickets.
Start with the event log, then verify on a test machine with the right policy attached.
Filter the Network‑wide → Event log
In the Event log, filter for Content filtering events to see allowed/blocked decisions. Look for:
Unexpected blocks: A business‑critical app denied by an aggressive category.
Silent misses: Domains hitting security detections you didn’t enable.
Policy source: Whether the decision came from the Network default or a Group policy override.
Build a simple habit: check this log after any policy change.
Test a blocked and an allowed URL
On a test machine that reflects the target user’s policy:
Attempt to reach a site in a blocked category—confirm the block page (HTTP) or the browser error (HTTPS).
Attempt to reach a site you’ve explicitly allowed—confirm it loads.
If results don’t match expectations, confirm the device’s applied policy and that DNS is flowing through the MX.
Check for group policy conflicts
When a user has unexpected access, it’s usually one of three things:
Wrong policy assignment: They’re on a VLAN/SSID with a different group policy.
Stacked policies: An RADIUS‑pushed policy overrides the network default you were testing against.
Over‑broad allow: Someone added *.domain.com when only a subdomain was needed.
Tighten the allow, re‑test, and watch the event log to confirm.
What to Do When Your Meraki Stack Gets Complicated
Single MX? Easy. Multiple sites, multiple SSIDs, Auto VPN, and a mix of user- and VLAN-based policies? That’s where drift creeps in and changes get risky.
Keep control with a few guardrails:
Standardize your base: Document the default security and content categories that every network must have. Clone from a known-good template.
Policy naming discipline: Prefix group policies with the owner/intent (e.g., HR-Training, Dev-Registries). You’ll know who to contact before touching it.
Change windows: Batch non-urgent changes and apply them during a weekly window. Pair with a quick test plan.
Audit quarterly: Export policies, lists, and logs. Trim stale allows and confirm that temporary blocks were actually temporary.
If you’re managing dozens of networks, build a simple runbook for exceptions and who approves them. That keeps security and productivity aligned.
Need help keeping it all straight? Hummingbird Networks works with multi-site Meraki environments each day. We can help you build standardized templates, streamline policy rollouts, and tighten audit workflows, so you can spend less time in the dashboard and more time running your network.
Now, Make Your Filtering Policy Smarter
You’ve got the engine, the baseline, and clean exceptions. Don’t stop there. Static policies age fast, and attackers move faster than category databases.
Turn this setup into an ongoing practice:
Review logs weekly: Scan Content filtering events for new domains tied to your critical apps and for repeated user friction. Adjust categories or add narrow allows where justified.
Expire temporary entries: Time‑box one‑off allows and blocks. Set a calendar reminder to re‑evaluate in 30 days.
Watch new SaaS: New departments adopt new tools. Build a simple intake for app requests so you can allow what’s needed without opening floodgates.
Test on a pilot group: Before loosening a category for a department, test with two or three users. If nothing breaks, roll out broader.
Document business context: Every exception should have an owner and a reason. When it’s unclear why an allow exists, remove it and monitor.
Security isn’t one and done. Treat content filtering like any other control—tuned based on what your users actually do.
Need better network security? Explore how Meraki MX devices can maintain control and security across your network.
FAQs
1. How do Talos category updates affect live filtering policies on the MX?
Talos updates roll in continuously, and category shifts can cause a domain to move from “allowed” to “blocked” overnight. The MX pulls new intelligence without a reboot, so behavior can change mid-day. Teams that manage critical SaaS apps usually add those domains to an allow list after a vendor change or acquisition. A quick weekly review of the Content filtering event log keeps surprises away.
2. When should I use group policies instead of VLAN-based filtering?
VLAN filtering works for simple networks where devices stay put. As soon as users roam or departments share SSIDs, VLAN-based enforcement becomes noisy. Group policies give you cleaner segmentation and a predictable per-user or per-device stance. If your users move between buildings or sites, assign policies via RADIUS attributes so the filtering follows them.
3. Why do some blocked HTTPS sites show a browser error instead of a Meraki block page?
Encrypted traffic hides block pages. The MX can’t inject a warning into HTTPS without breaking the TLS handshake, so browsers show generic “connection not secure / failed to load” errors. That’s normal. If the site appears to load anyway, confirm the client isn’t using a non-MX DNS server or a split-tunnel VPN.
4. What’s the best way to validate that filtering rules are working across Auto VPN sites?
Policies sync at the network level, not across the entire organization. Each MX enforces the rules configured in its Dashboard network, even when Auto VPN connects them. To keep behavior consistent, document a standard baseline and clone from a known-good template. When you push changes, test from a remote site as well — event logs are local to each MX.
5. How do I prevent overbroad allows from weakening my entire filtering posture?
Allows override everything. The fastest way policies drift is through wildcard entries like *.example.com when only api.example.com was needed. Use narrow subdomains, document every entry, and schedule a monthly review to prune anything without an active business case. If an exception is temporary, label it with the expiration date in the description field.
6. Why do some users get access to a site even though it’s blocked for everyone else?
Most mismatches come from overlapping policy assignments. RADIUS-assigned group policies override VLAN and SSID policies, and client-specific policies override everything. Check the client page in Dashboard first. You’ll typically find a forgotten test policy, a stale MAC-based assignment, or a mis-tagged device.
7. How should I handle third-party SaaS tools that rely on large CDNs with constantly changing domains?
Modern SaaS platforms use dynamic CDNs that rotate hostnames, so category engines may temporarily mislabel them. Instead of allowing each CDN host, allow the official parent domain only if the vendor confirms it’s required. If not, switch to IP allow lists via firewall rules instead of content filter bypasses — they’re tighter and easier to audit.
8. What’s the recommended way to test policy changes without affecting production users?
Spin up a test SSID mapped to a non-production VLAN and apply the new group policy there. Use a test machine that mimics the target user role. Verify blocked and allowed categories, run SaaS apps the team depends on, and watch the event log in real time. Once confident, roll out the group policy to a pilot group before applying it network-wide.
