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.
Topic
28 matching entries across Articles, TIL and Projects.
Long-form writing tagged Zero Trust.
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 Zero Trust.
For a training-compliance Access evaluator, I treat missing users, invalid requests and database errors as deny conditions instead of accidental allows.
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.
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.
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.
Cloud and SaaS services move between addresses. Policy often expresses intent more accurately when it follows the application hostname.
Before creating an emergency bypass, work out whether the failure is identity, posture, policy, DNS, tunnel or origin.
Projects and implementation patterns tagged Zero Trust.
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.