Retiring the VPN: How Cloudflare Is Replacing It With Zero-Trust Access
Remote work has pushed Cloudflare to re-evaluate how its internal services are protected. In recent years, the company has shifted away from the traditional approach of putting every internal service behind a VPN, moving instead toward a zero-trust architecture centered on Access, Cloudflare's identity-aware proxy. Access authenticates and authorizes users before they reach an internal application, replacing the old model where network-level access was granted once a VPN connection was established.
The migration is not complete. A number of services still rely on the VPN, and the company maintains that infrastructure with Spectrum, which fronts VPN endpoints and provides DDoS protection and performance benefits for any TCP/UDP-based protocol. This hybrid setup lets Cloudflare protect legacy VPN traffic while steadily moving services to Access.
Why the VPN Is Hard to Remove
Before Access, services were placed behind a Cisco ASA running AnyConnect. That setup enforced authentication and authorization at the network layer, but it had significant operational downsides: VPN infrastructure is difficult to set up, maintain securely, and scale. New hires needed to learn how to configure a VPN client, and the server-side management burden grew with every user.
The migration strategy has been incremental, moving services one by one, prioritizing the most critical ones first. A notable sticking point was source control, which relied on git+ssh. Developers had to establish a VPN connection before committing code. That obstacle was removed once Cloudflare introduced SSH support over Access, allowing the VPN to be dropped as a protection layer for source control systems.
The migration is now nearly complete. Only a few niche tools remain behind the VPN, and as of 2020, new employees are no longer given a VPN account by default during onboarding. Access logs show a steady increase in the number of users logging into protected applications each month.
Protecting the VPN With Spectrum
While the VPN remains necessary, it is a critical tool for remote workers, so uptime and performance matter. Placing Spectrum in front of the VPN improved both immediately, with no changes to the end-user experience. All VPN traffic now flows through the Cloudflare edge network, which guards against DDoS and reduces latency for users connecting from various locations.
Configuration was minimal, as only a small set of settings was required to make the setup work.
AnyConnect authenticates over HTTPS (TCP), after which the actual data is tunneled using a DTLS-encrypted UDP protocol. Early testing revealed a problem: authentication succeeded, but no data flowed through the tunnel. The culprit was the MTU (maximum transmission unit). Cloudflare had historically set an MTU of 1280 for IPv6 to avoid path MTU discovery problems, since IPv6-to-IPv4 tunnels and ECMP routing inside data centers could cause issues with "packet too big" messages.
Running a UDP-based VPN adds headers that increase packet size, so the 1280 MTU was too small. The team ultimately increased the MTU to 1420, a value that still runs today and enables Spectrum to fully protect VPN traffic.
A Steady Path Toward Retirement
Since adopting this approach, Cloudflare has kept VPN infrastructure safe and operational, allowing remote work to continue without disruption. The strategy has been to migrate services to Access one at a time, using Spectrum and the VPN in the interim to protect services that have not yet moved. Access is the long-term endpoint of this effort, while Spectrum keeps the remaining VPN services secure until they too are migrated.
