Skip to content
Notifications
Clear all

Rolled out Cloudflare One to 1000 users - what broke during deployment

3 Posts
3 Users
0 Reactions
0 Views
(@devops_rookie_2025)
Reputable Member
Joined: 2 months ago
Posts: 203
Topic starter   [#10933]

Hi everyone! I'm just starting out with our company's Zero Trust migration and we recently deployed Cloudflare One to our whole team of about 1000 users. Overall, it's been promising for securing access, but wow, we hit some unexpected snags during the rollout 😅

I'd love to hear if others experienced similar issues. Our two biggest headaches were:

1. **DNS resolution inside our private network broke** for some apps. We had to switch from Cloudflare Gateway's DNS to using our internal DNS servers for specific domains. The rule looked like this in the Gateway policy:
```json
{
"action": "local",
"description": "Use internal DNS for .internal.corp",
"filters": [
"dns.domain in {"*.internal.corp"}"
]
}
```
2. **Legacy applications that used IP-based "allow lists"** stopped working because the source IP seen by our servers was now a Cloudflare egress IP. We had to update firewall rules on-prem to allow Cloudflare's IP ranges.

Did anyone else run into these problems? Any beginner-friendly tips for smoothing out these kinds of issues in the future? Thanks so much for your help! 🙏



   
Quote
(@integration_maven)
Estimable Member
Joined: 4 months ago
Posts: 130
 

You're describing the two most classic Cloudflare One migration issues, and your DNS workaround is exactly right. We ran into that same internal domain problem, but it was for a legacy, non-standard DNS suffix like `.local.companyname`. The policy you wrote is the standard fix.

On the IP allow list problem, don't forget about Cloudflare's egress IP ranges. They're documented, but they do change. We set up a scheduled job to pull the latest JSON from their API and update our on-premise firewall objects automatically. It prevents a surprise break later on.

Did you also see any issues with client certificates or mTLS for internal APIs? That was a third, less common headache for us that only popped up a week after rollout.


IntegrationWizard


   
ReplyQuote
(@data_pipeline_guy)
Estimable Member
Joined: 4 months ago
Posts: 107
 

The scheduled job for egress IPs is smart. Most teams just manually update the firewall, then get burned six months later when something breaks at 2 AM. Classic ops debt.

mTLS was a nightmare for us too, but it wasn't Cloudflare's fault. It exposed that half our "internal" APIs were using certs from a long-departed CA. The outage map lit up like a Christmas tree. Zero Trust just did its job a little too well.


SQL is enough


   
ReplyQuote