Just finished migrating our remote team off a clunky Sophos SSL VPN and onto Cloudflare Access. The tech side was smooth — a few Helm values and some YAML. But getting the team to trust "just a browser" instead of a VPN client? That was the real challenge.
Our old `SophosConnect` configs are finally gone. Now it's just an Access policy like this:
```yaml
- name: "k8s-dashboard-access"
rules:
- action: "allow"
resources:
- "cluster:prod/*"
identity:
- email: "team@example.com"
session_duration: "8h"
```
Had to run so many "this is not a VPN" workshops. Anyone else hit a wall with user mindset when moving from traditional VPN to zero-trust? How did you get buy-in?
yaml all the things
SRE at a ~300 person logistics shop. We run Jenkins on-prem with a mix of Cloudflare Access and WireGuard for different access patterns.
1. **TCO - Actual cash and hidden hours.** Sophos is licensed per appliance; figure $3-5k/year plus renewal. Cloudflare is $4-7/user/month on Teams. The trap? If your app isn't web-based, you're tunneling RDP/SSH through `cloudflared`. That's a hidden client install and config headache you just replaced.
2. **Actual zero-trust granularity.** Cloudflare rules are URL and identity only. Sophos (and any real VPN) sees the whole network segment. Cloudflare's model breaks if your app uses dynamic ports or broadcast traffic. We hit this with a legacy inventory system.
3. **Operational overhead swap.** You traded VPN server patching and HA configs for Terraform/API drift on Cloudflare. Their API is fine, but now your access control is a vendor console. A misclick can lock you out. Tested restoring from config backups? Sophos was a config file restore.
4. **Performance under real load.** For web apps, Cloudflare's proxy adds ~20-40ms latency but handles spikes fine. The tunnel daemon (`cloudflared`) for non-web stuff chokes on high-throughput data transfers. Moving large DB dumps over it? Saw throughput drop to ~30 Mbps vs. 150+ on the old IPSec tunnel.
My pick: Cloudflare for web-only, greenfield teams. If you have legacy thick-client apps or need full network-layer access, you'll regret it. Tell us your non-web app count and if you have a networking team that understands BGP.
-- old school
Oh, the mindset shift is real. It feels less secure to them because they're not "connecting" to the office anymore. The little green padlock icon in their system tray was a security blanket.
We framed it as upgrading from a front-door key to a personalized ID badge. The VPN gave you keys to the whole building. Now, your badge just gets you into the specific rooms you need, no matter where you're standing. That analogy finally clicked for a lot of our non-technical folks.
The biggest wins came from power users who hated the constant VPN drops. Showing them they could jump straight to the Grafana dashboard without launching a client first turned them into evangelists.
ian
That point about Terraform drift versus restoring a config file really hits home. We manage our Cloudflare policies with Terraform too, and while it's declarative, you're right that a state mismatch or a missed `terraform apply` can leave you with a dangerous gap between your repo and what's actually enforced.
It makes me miss the simple backup-and-restore of an appliance config sometimes. You've also got me thinking about the tunnel daemon for non-web traffic. We use it for some database admin interfaces, and the throughput can be unpredictable compared to a direct WireGuard link. Have you considered a hybrid model where you keep WireGuard for those high-throughput, non-web legacy systems and use Access strictly for web apps? It adds complexity but might be the pragmatic middle ground.
~jason
Yeah, the hybrid model idea is interesting. It seems like a lot of teams end up with this split because zero-trust can't cover every legacy use case.
How do you handle the user experience side of that? Do you train people on when to use WireGuard vs. Access, or do you try to make it invisible on the backend? I can see that getting confusing fast.