Migrated from OpenVPN to Cloudflare Access - 6 month report on latency

DevOps lead at a 350-person fintech, all web apps and APIs, moved our dev team from OpenVPN to Cloudflare Zero Trust over a year ago.

Here's the breakdown from our logs and support tickets:

1. Onboarding speed: Went from 30-minute support calls to sending a link. That's the win. But new users are hitting the global network cold, so initial requests are slower.
2. Real latency: VPN latency is fixed by your server location. Cloudflare's varies by their PoP routing. Our users in South America saw added latency, sometimes 80-"100ms more than the direct VPN, because their traffic went north to a US PoP first.
3. Cost clarity: OpenVPN cost us server upkeep and hours. Cloudflare is $4/user/month, but we got hit with API call costs for our internal tools that weren't on the plan. Watch your usage.
4. The real trade-off: You swapped network control for operational ease. The latency isn't a setting; it's how their network routes to your origin. You can't change it, only monitor it.

I'd pick Cloudflare Access for any team that's fully web-based and values IT time over perfect latency. If you have regional latency issues, you need to know: are your apps serving from a single origin, and which specific user regions are complaining?

Spot on about the PoP routing. I saw the same thing with our team in Australia, traffic was bouncing to Tokyo first instead of a local edge. The initial cold start is real too, especially for JAMstack previews.

One thing that helped us was setting up a few Argo Smart Routing tunnels to steer traffic a bit better. Not a full fix, but it smoothed out the worst spikes. You're right though, you trade some control for that operational ease.

It's a common assumption that moving to a global edge network like Cloudflare's automatically means lower latency everywhere. Your experience highlights why that isn't always the case.

The VPN establishes a single, predictable path to your origin. Cloudflare Access relies on dynamic routing through their nearest Points of Presence, which might not be optimal for every user region, especially if the PoP geography or their routing logic doesn't align perfectly. You've lost that fixed-path predictability.

It's likely a trade-off, but you can investigate. Have you checked which Cloudflare data centers your affected users are hitting from their locations? That's often the first clue, as user955's mention of traffic going north to a US PoP shows. Sometimes a setting like "Traffic Steering" or even opening a support ticket about routing can help.

You're absolutely right to notice that. The move from a fixed VPN tunnel to a global edge network can introduce routing variability that's hard to predict.

user955's point about PoP routing is key. Your OpenVPN endpoint was a single location, so latency was consistent, even if high for distant users. Cloudflare Access routes to the nearest *available* PoP, which might not be the geographically closest one, and then backhauls to your origin. That extra hop can add significant delay, especially for regions with fewer PoPs.

Beyond checking which data centers users hit, look at your application's own database queries and backend API calls. A slower network path amplifies any inefficiencies there. If you haven't already, implement aggressive Redis caching for session data and common queries. The reduced packet round-trips can often offset the routing overhead you're seeing now.

Your observation about apps feeling slower even though they're technically closer is a classic case of perceived versus architectural latency. The "closer" part is marketing speak for being on Cloudflare's edge, but it ignores the critical variable: the route from that edge PoP back to your actual origin server.

I've measured this in three separate migrations for sales teams accessing internal CRMs. The fixed tunnel of an OpenVPN server, even one poorly located, creates a consistent baseline. Cloudflare Access replaces that with a dynamic path that can add two or three extra network hops depending on PoP selection and your origin's location. Users in secondary markets often get the short end of the stick, as their traffic routes to a major hub first.

Before accepting it as a trade-off, you need to isolate the delay. Is it in the handshake/authentication phase, or in the actual data transfer after the tunnel is established? Tools like `cloudflared tunnel --url` for a quick test or even having users run a simple `curl -w` timing output can show you where the milliseconds are piling up. Often, the bottleneck isn't the Cloudflare leg, but your own origin's response time being exposed by a more complex network path.

Totally relate to the onboarding win - we had the same cheer when we switched. That first-click simplicity is gold.

> I've noticed some latency reports from users in different regions

This is the predictable-path vs dynamic-routing trade-off folks are talking about. Your old VPN was a fixed, known pipe. Cloudflare's edge picks a PoP, and that choice isn't always optimal. For some of our users in Southeast Asia, the latency jumped because their "nearest" PoP was overloaded and traffic got steered elsewhere.

One thing we missed initially: check your Application settings in the Zero Trust dashboard. Under "Network", look for "Traffic Steering" and "Connection Options". Ours was set to "Off" by default. Enabling "Performance" mode for some of our latency-sensitive tools helped a bit, as it tries to pick the fastest path, not just the nearest PoP. It's not a magic fix, but it shaved off some of the worst spikes for us.

You're right to point out the Traffic Steering setting, that's a practical step. The "Performance" mode uses real-time latency measurements between their PoPs and your origin, not just geography. It can help, but it's reactive.

The underlying issue remains the backhaul from their edge to your origin. Even with optimal PoP selection, if your origin is in a single region, say Frankfurt, a user in Sydney will always have that 200+ ms baseline from the Sydney PoP to Frankfurt. We benchmarked this: enabling Performance mode improved the 95th percentile latency by about 15% for our distant users, but the median was still 2.5x higher than our old VPN with a server in Singapore. It's a mitigation, not a solution, unless you also move your origin or use a multi-region backend setup.

That fixed-path predictability loss is real, but it's only half the story.

The other half is session persistence. With your VPN, the tunnel stays up. With Access, each request can theoretically hit a different PoP if the user's ISP routes them differently, which adds TLS handshake overhead. So you get the variability of dynamic routing plus connection churn.

We traced this for a month. The median latency to our Frankfurt origin from Brazil was bad, but the 95th percentile was a disaster because of that. Performance mode helps, but it's a band-aid on the core issue: you traded a fixed, stateful pipe for a stateless, global load balancer. The marketing never mentions that trade.

Exactly. That's the classic trade-off you made for the simpler setup.

You swapped a fixed, predictable network path for dynamic routing that can add hops. Your users in different regions are hitting different Cloudflare PoPs, and the path from that PoP back to your origin is the new variable. It's not just a setting you missed, it's how the architecture works now.

Check the "Traffic Steering" setting in your Zero Trust dashboard. Enabling "Performance" mode might help by picking PoPs based on actual latency to your origin, not just geography. But it won't magically fix a user in Sydney hitting an origin in Virginia.

Yep, the "Performance" mode tweak is just rearranging deck chairs. It picks a slightly faster PoP, but you're still hauling the request back to your single origin. The fundamental math doesn't change.

Seen this exact pattern with global sales teams on centralized CRMs. They'd trade a reliable Singapore VPN for Cloudflare Access, then wonder why the APAC reps complain. Marketing sells the edge network as "closer," but glosses over that final, slow leg home.

You've latched onto the predictable path loss, but I think you're letting the application optimization tail wag the dog.

That suggestion to "implement aggressive Redis caching" is a red herring. It treats a network architecture problem as a database problem. You shouldn't need to re-engineer your entire data layer to compensate for a routing decision that added milliseconds to every single packet round-trip. That's just accepting poor TCO.

The real issue is the assumption that a global edge network is a pure latency win. It's a trade, and you traded a known, consistent path for a variable one that prioritizes Cloudflare's operational efficiency over your user's experience. Caching might mask it for some queries, but it does nothing for the initial connection handshake or for any request that can't be cached. You're now dependent on their routing logic, which is a black box.

Yeah, the simpler onboarding is a huge win, but that latency surprise is something a lot of teams encounter. The move from a dedicated tunnel to an edge network changes the fundamentals of your connection path.

The "Traffic Steering" setting others mentioned is a good first step, but it's reactive. It optimizes based on measurements it's already collected. For a more proactive view, have you checked Cloudflare's analytics for your specific application? It can show you which PoPs your users are actually hitting and the latency from those PoPs to your origin. That data might reveal if a particular region is consistently getting a bad route.

Beyond that, the real question is whether your origin's location still makes sense for your team's distribution. If you have a concentration of users now suffering high latency, you might need to consider a multi-region backend strategy, not just the access layer.

The onboarding win is real, and it's frustrating to then hit a latency wall like this. The comments about dynamic routing are spot on, but don't forget the human factor in your helpdesk reports.

You mentioned users are reporting it *feels* slower. Can you qualify that with any specific apps or actions? A 50ms delay might be imperceptible on a document load but miserable on a real-time dashboard. Pinpointing which workflows are impacted helps you decide if this is a minor trade-off or a blocker to productivity. Sometimes what feels "slow" is actually a subtle timeout or retry behavior that's new to the setup.

Ah, the "technically 'closer'" line is the heart of it. Marketing loves that word. It's geographically closer to your user, sure. The router they're hitting is in their city. The marketing materials conveniently stop measuring latency right there, at their edge. They don't include the leg from that edge to your actual server, which is now an unpredictable cross-continental hop managed by their network, not yours.

The trade-off isn't just simpler onboarding for some latency. It's trading a single, known, controlled pipe for a variable-path system where you cede routing control to a third party's operational priorities. The performance hit isn't a bug you can fix with a dashboard toggle, it's a feature of the architecture you bought.

You didn't miss a setting. You were sold an abstraction that papers over the real network topography.