Blog · 2026-09-20
Cisco Umbrella tells you nothing. Here is how to get the reason anyway.
If you point Cisco Umbrella at a custom block page, the browser lands on your URL carrying nothing. No blocked domain. No category. No identity. No reason. Umbrella's own block page shows all of that because Umbrella renders it — the moment you redirect, you forfeit it.
That is the reason most MSPs either live with Cisco's page or put up a branded dead end that says "blocked" and nothing else. A block page with no information is not a security control, it is a wall with a logo on it.
The part nobody reads
In the Umbrella block page editor there is a radio labelled "Blocked requests should be treated:" with two options, The Same and Differently. Almost nobody picks Differently, because on the face of it it just means "write four messages instead of one".
What it actually does is split the block page into four independent contexts — Content Setting, Destination List Setting, Phishing Setting, Security Setting — and give each one its own full option set, including its own redirect URL.
So you hand the customer four URLs that differ only in the last path segment:
https://blocked.example.com/b/acme-hq/content
https://blocked.example.com/b/acme-hq/destlist
https://blocked.example.com/b/acme-hq/phishing
https://blocked.example.com/b/acme-hq/securityNow the reason arrives in the path, from Cisco, at page load, with no API call and no latency. A gambling block and a malware block are different pages, because they are different URLs. That is the whole trick.
It matters more than it sounds
"This site isn't available on this network" and "this site was trying to steal your password" are not variations on a theme. One is an inconvenience the reader should shrug at; the other is a near miss they should tell someone about. Serving both from the same grey box trains people to ignore the second one.
Getting the domain back
The reason is free. The domain still is not — for that you have to go and ask Umbrella's Reporting API what this public IP was just blocked for, after the fact. We do it as a progressive enhancement: the page renders immediately from the URL, then fills in the domain a beat later if the answer arrives. The page is complete without it, because sometimes it does not arrive.
Two things to tell the customer first
- Umbrella disables redirects entirely on any policy that has bypass users or codes applied to it. If you use block page bypass, you cannot use a custom page on that policy.
- A blocked https site shows a certificate warning before it can reach your page. That is true of every custom block page from every vendor — you are redirecting a domain you do not own a certificate for. Managed endpoints with the Umbrella root CA installed are the only way around it.
Neither is a dealbreaker. Both are much better heard from you in advance than discovered by the customer on a Tuesday.