We just finished a full ZTNA rollout with Cloudflare Zero Trust, replacing our legacy VPN for about 1000 users. The promise of "identity-aware" access was the big draw, but the transition wasn't as smooth as I'd hoped. I figured I'd share where we hit friction, since most case studies gloss over the messy bits.
The biggest issue wasn't the core tech, but user behavior and app compatibility. Our SSO (Okta) integration was solid, but we immediately saw a spike in help desk tickets for "application not found" errors. The culprit? A ton of legacy internal web apps that used hard-coded hostnames or IPs in their own HTML/JavaScript. When accessed through a random `*.cloudflareaccess.com` hostname, they'd try to redirect or fetch assets from the internal domain and break. We spent weeks with a small dev team adding `HTTP_ORIGIN` and `HTTP_REFERER` checks to these apps.
Another surprise: our data visualization tools (Tableau, Metabase) had issues with WebSocket connections through the tunnel. Dashboards would load but live updates would fail silently. We had to adjust the Cloudflare Tunnel configuration with specific `ingress` rules for these paths, setting `originServerName` to preserve the host header the apps expected.
Performance-wise, it's been a net win, especially for remote users. But we learned that "agentless" for browsers doesn't mean you can ignore device posture entirely. We ended up deploying the WARP client to about 30% of our users (mostly engineering) who needed non-HTTP TCP access to databases and dev environments. The mix is working, but it added a second rollout phase we didn't initially plan for.
Curious if others have run into similar app compatibility headaches. How did you handle the "long tail" of legacy internal apps that weren't designed for ZTNA's hostname abstraction?
✌️
Wow, the part about hard-coded hostnames hits close to home. We had a similar issue with a few older internal BI tools when we started using a reverse proxy. The devs had to go spelunking for config files where someone just typed "http://server-05/" years ago.
Did the WebSocket fixes for Tableau end up being straightforward, or did you run into other problems with session persistence? I'm about to move some internal Airflow instances behind access controls and I'm worried about the scheduler's long-polling connections.
null
Yeah, the spelunking is real. We found those hardcoded references everywhere from config files to inline JavaScript that built API URLs. It became a mini-project just to audit and fix them.
For WebSockets and session persistence, we had mixed results. Tableau was mostly fine after enabling the proxy option, but we hit a snag with some custom apps using sticky sessions via cookies. Cloudflare's session affinity helped, but it added another layer to debug when things went weird.
For Airflow, I'd test the scheduler's health checks and the webserver's long-polling separately. The webserver connections behind the proxy were stable for us, but we did have to adjust some timeouts. The scheduler itself talking to the database didn't need to go through the proxy, which simplified things.