Building a Better Cloudflare Gateway Block Page
How I used a Cloudflare Worker to enrich Gateway blocks with policy, device, user, category and Cloudflare One Client context while keeping the page resilient and secure.
Guide
A reading guide to running Cloudflare Zero Trust at enterprise scale — the migration, the policy model underneath it, and the operational detail that only appears once real users depend on it.
Cloudflare Zero Trust is not a product you install. It is a set of decisions about identity, device trust and application access that you keep making for years after the rollout is declared finished — and most of the difficulty lives in those decisions rather than in the configuration that expresses them.
What follows is everything published here on the subject, grouped into routes rather than listed by date. The order matters, because these problems arrive in a particular sequence and it is not the one you would choose. Broad access comes before narrow policy, because people have to keep working. Denials become a support problem before they become a design problem. Policy-as-code arrives late, usually just after a manual change has gone somewhere it should not have.
This is enterprise experience rather than a homelab walkthrough. The material comes from a multi-year programme replacing a legacy corporate VPN across a distributed organisation, discussed publicly in a Cloudflare webinar and on stage at Cloudflare Connect. Every configuration example is synthetic; no production architecture, tenant detail or policy appears anywhere on this site.
The programme before the product. Read these three in order if you are deciding whether to start.
Where most implementations quietly go wrong: policy written against addresses that were never stable.
The half of the access decision that is not identity, and the routing behaviour it depends on.
A control that fires without explaining itself becomes a support ticket saying the internet is broken.
Gating access on an external system, and what must happen when that system cannot be reached.
Getting changes out of the dashboard and into something reviewable, repeatable and reversible.
Two pieces about the running service rather than the build.
These carry the same tag because newcombe.dev is itself a Worker. Separated so they do not muddle the material above.
Long-form writing tagged Cloudflare.
How I used a Cloudflare Worker to enrich Gateway blocks with policy, device, user, category and Cloudflare One Client context while keeping the page resilient and secure.
How I built a repeatable AWS, Azure and Google Cloud lab to explore Cloudflare Access, Gateway, WARP routing, device posture and external evaluation as one integrated Zero Trust system.
I used Terraform to fetch public domain feeds, turn them into Cloudflare Zero Trust lists and enforce them with a Gateway DNS policy that remains reviewable as code.
Authentication proves identity, but it does not prove a user has met a business requirement. I used Cloudflare Access External Evaluation, Workers and D1 to add training compliance to the access decision.
A custom Cloudflare Access denial page can turn a generic block into useful identity, device, posture and network diagnostics without exposing sensitive control-plane details.
A small Cloudflare Worker can provide a controlled front end for Gateway allow-list changes while KV supplies recovery, synchronization and operational visibility.
How to model, validate and deploy Cloudflare device posture checks as reusable configuration without coupling policy intent to environment-specific object IDs.
Practical lessons from an enterprise ZTNA deployment: foundations, staged migration, policy automation, legacy applications, change management, and measurement.
Enterprise browsers move enforcement into the user session. Network-centric Zero Trust still owns critical controls such as DNS, routing and non-browser traffic. The interesting architecture is often the combination.
Zero Trust is not resilient just because it is cloud-hosted. Identity, posture, policy, tunnels, DNS and SaaS authentication all create failure domains that need deliberate recovery paths.
A practical pattern for consuming AWS/Azure network feeds, calculating desired state and safely synchronising Cloudflare Zero Trust lists with PowerShell.
When private sites and DNS exceptions multiply, WARP device-profile configuration becomes data. Source control can become the input and PowerShell the generator.
As Zero Trust policy grows, the engineering problem shifts from configuring a dashboard to safely compiling, validating and deploying policy across environments.
Static IP and subnet rules become fragile when SaaS platforms and CDNs move underneath you. Domain-aware egress policy aligns network controls with application intent.
Short notes and fixes tagged Cloudflare.
For a training-compliance Access evaluator, I treat missing users, invalid requests and database errors as deny conditions instead of accidental allows.
Short-lived Cloudflare API failures can justify a retry, but diagnostic Workers still need a bounded attempt count and a useful fallback value.
Cloudflare Gateway can provide a rule ID to a custom block page, but resolving that UUID to the rule name makes support diagnostics much more useful.
When a Zero Trust diagnostic page needs the virtual IPv4/IPv6 assigned to a device, the active device registration is the useful object to query.
For dynamically generated security pages, I use a per-response nonce so required inline script/style can run without falling back to a broad unsafe-inline CSP.
A CF-Ray header alone does not prove a request came from Gateway, so my Worker requires Gateway-specific query context before rendering diagnostic output.
An HTTP data source can retrieve an external domain feed, but the useful pattern is to validate and normalize it before Terraform materializes enforcement objects.
When Terraform already knows the cloud subnets, those values can become inputs to WARP routing instead of being copied into a second manually maintained list.
In my Gateway allow-list Worker, Cloudflare lists remain the enforcement state while Workers KV stores backup and synchronization metadata.
The small deployment workflow behind this site: test Astro locally, push to GitHub and let Cloudflare build the production site.
The simple 301 redirect pattern I use to keep one canonical hostname for a site.
Cloud and SaaS services move between addresses. Policy often expresses intent more accurately when it follows the application hostname.
DNS resolution and packet routing are related, but a WARP configuration often needs you to reason about them separately.
Before creating an emergency bypass, work out whether the failure is identity, posture, policy, DNS, tunnel or origin.
Projects and implementation patterns tagged Cloudflare.
A Cloudflare Worker that turns an Access denial into a support-friendly diagnostic page with identity, device, posture, WARP, network and recent-access context.
A Cloudflare Worker that provides a narrow, Access-protected workflow for validated Gateway allow-list changes with DNS/HTTP targeting and Workers KV backup.
A Terraform project that consumes remote domain feeds, normalizes them into Cloudflare Zero Trust lists and builds a Gateway DNS blocking policy from the generated data.
A Cloudflare Worker that enriches Gateway blocks with rule names, request category, user, device, Cloudflare One Client addresses and support correlation data.
A Terraform-managed Zero Trust engineering lab spanning AWS, Azure and Google Cloud with Cloudflare Access, Gateway, WARP routing, device posture and optional Worker integrations.
An Access External Evaluation Worker that uses D1-backed training state to require mandatory training completion before protected applications can be opened.