Having recently concluded a 12-week proof-of-concept for a global financial client migrating from legacy VPN appliances to a modern Secure Access Service Edge (SASE) model, I was tasked with a technical evaluation of two primary contenders: **Versa Secure Access** and **Cloudflare One**. The goal was zero-trust network access for ~5000 users and ~200 private applications, with stringent data sovereignty and egress control requirements. This post details the architectural and operational differences observed during hands-on testing.
Our test harness was built in AWS, simulating a multi-region deployment (us-east-1, eu-central-1). We instrumented everything from TCP connection latency under packet loss to policy propagation time. Below is a simplified version of the Terraform module we used to deploy the test applications, which were then accessed via both platforms.
```hcl
# Sample module for test app deployment - used for egress & ingress testing
module "test_app_eu" {
source = "terraform-aws-modules/ec2-instance/aws"
version = "~> 4.0"
name = "test-app-eu-prod"
ami = data.aws_ami.ubuntu.id
instance_type = "t3.micro"
vpc_security_group_ids = [module.security_group.security_group_id]
subnet_id = module.vpc.private_subnets[0]
tags = {
Environment = "Test"
SASE-Target = "true"
Region = "eu-central-1"
}
}
```
### Core Architectural Divergence
* **Versa Secure Access** leverages a full-stack software-defined approach, inheriting from their SASE/SSE platform. The gateway components (VNO/VNG) are distinct from the control plane, offering a high degree of configurability. We observed this allows for granular routing policies (e.g., specific user groups egressing via specific IPs in specific regions, with distinct next-hop BGP peers). This is a double-edged sword: powerful for those with complex needs, but requiring deeper networking knowledge.
* **Cloudflare One** operates on a massive anycast network. The control and data planes are deeply integrated, abstracting much of the underlying networking. Connection establishment was consistently faster in our global latency tests (by ~15-30ms RTT from APAC regions), attributable to anycast routing. However, egress IP control, while possible via Location-based Egress, felt less granular than Versa's virtual appliance model.
### Policy Configuration & Propagation
A critical test was the time from policy change in the admin console to full enforcement. We measured this by scripting policy updates and then having agents in 5 global regions attempt to access a newly blocked resource every second.
* **Cloudflare One:** Policy updates propagated and were effective globally within **45-60 seconds** on average. The policy syntax is JSON-like within their Terraform provider, which is robust.
* **Versa Secure Access:** Propagation times showed more variability: **2-5 minutes**. However, the policy construct allowed for more hierarchical, context-aware rules. For example, a rule could combine `User-Department: Finance`, `Device-Posture: Compliant`, and `App-Category: High-Risk` with custom routing. This level of detail in a single policy object was not as natively achievable in Cloudflare's model during our tests.
### Data Sovereignty & Egress Control
For our client, ensuring EU user traffic egressed only from EU nodes was non-negotiable. Both platforms could achieve this, but the mechanisms differed starkly.
* Versa's solution involved defining a dedicated "EU Egress" gateway group and binding a routing policy to it. The configuration was network-centric (similar to configuring a VRF).
* Cloudflare used the concept of "Egress Endpoints" (virtual IPs) tied to specific data centers. Policy then used the `egress` parameter to select the endpoint. It was simpler to deploy but offered less control over the routing *beyond* the egress IP.
### Performance Under Simulated Adverse Conditions
Using `tc` (traffic control) on intermediate hops, we simulated 1% packet loss and 100ms of added latency. Cloudflare's anycast network and HTTP/3-based WireGuard transport showed more resilience, with fewer TCP retransmissions observed via `tcpdump`. Versa's TCP proxy performance degraded slightly more under packet loss, though still within acceptable limits for most applications.
### Conclusion & Unanswered Questions
For a "lift-and-shift" of traditional VPN users with a need for simplicity and raw speed, **Cloudflare One** presented a compelling, operationally lighter package. For a complex, multi-tenant environment requiring granular network segmentation, detailed routing control, and integration with existing SD-WAN overlays, **Versa Secure Access** offered deeper knobs to tune.
Our final recommendation hinged on a factor outside pure technical capability: the existing skill set of the network operations team. The Versa model required a team comfortable with BGP, routing policies, and virtual appliances. The Cloudflare model assumed a team more adept at identity-aware proxy configurations and API-driven development.
I am particularly interested if others have conducted similar deep dives, especially regarding the internal packet flow for UDP-based applications (VoIP, video) under each architecture. Our tests in that area were inconclusive.
- Mike