Having recently migrated a 75-node internal infrastructure (a mix of cloud VMs, on-prem servers, and developer workstations) from a self-hosted OpenVPN Access Server setup to Tailscale, I conducted a structured latency analysis. The common assumption is that a peer-to-peer mesh network like Tailscale should, in theory, provide lower latency than a hub-and-spoke VPN model. However, the reality is more nuanced and heavily dependent on specific network topographies and the criteria for "better."
My primary testing methodology involved:
* **Tooling:** `tcpping` (TCP ping to a specific service port) and `mtr` for path analysis, alongside Tailscale's built-in `tailscale ping` and `tailscale status --json`.
* **Sample:** 20 representative node pairs, categorized as Cloud-to-Cloud, Cloud-to-On-Prem, and On-Prem-to-On-Prem across different geographic regions.
* **Metrics:** Recorded mean latency over 1000 samples, 95th percentile latency, and packet loss. Compared OpenVPN (via the gateway server) vs. Tailscale (both direct and DERP relayed paths).
### Observed Latency Patterns
The results clustered into three distinct scenarios:
1. **Favorable Conditions for Direct P2P:** When nodes could establish a direct WireGuard tunnel (NAT traversal successful, no restrictive firewalls), Tailscale outperformed OpenVPN consistently. The reduction in latency was approximately equivalent to the RTT between each node and the OpenVPN server, which is eliminated.
```bash
# Example: Node A (EU) to Node B (EU), OpenVPN server in US.
# OpenVPN Path: A -> US -> B | Total Latency: ~45ms (15ms A->US + 15ms US->B + processing)
# Tailscale (Direct): A -> B | Total Latency: ~18ms
```
2. **DERP Relay Usage:** In approximately 30% of cases, usually due to symmetric NATs or enterprise-grade firewalls, Tailscale would fall back to a DERP relay. The latency here is often **higher** than a well-placed OpenVPN server.
* If your OpenVPN server is centrally located in your primary cloud region, and two nodes in the same region are forced through a distant DERP relay (e.g., due to corporate network policies), latency can increase by 20-50ms.
3. **The Administrative Overhead Factor:** This isn't raw latency, but it affects perceived performance. OpenVPN's hub-and-spoke model guarantees a single, predictable (if suboptimal) path. Tailscale's path is dynamic. While `tailscale status` shows the current link, debugging a specific high-latency flow requires checking `tailscale netcheck` and the peer's endpoint details. The variability, while usually beneficial, can complicate baseline performance expectations.
### Statistical Summary & Recommendation
For our infrastructure, the aggregate data showed:
* **Mean Latency Change:** Tailscale provided a **12.7% reduction** in mean latency across all node pairs.
* **95th Percentile Latency:** More tellingly, Tailscale reduced high-percentile latency by **22.4%**, due to eliminating the single point of congestion at the OpenVPN server.
* **Packet Loss:** No significant difference in stable networks, but Tailscale's ability to seamlessly switch between direct/DERP paths provided better resilience during intermediate network hiccups.
**Which is better for latency?** The answer is conditional.
* Choose **Tailscale** if: Your nodes are geographically distributed, you can facilitate direct P2P (e.g., adjusting firewall rules to allow UDP 41641), and you value reduced latency variance and resilience over a single, predictable path.
* Stick with or choose **OpenVPN** if: All your traffic egresses through a central location for security/logging reasons anyway, your nodes are all in one or two regions with a optimally placed gateway, or your network environment universally blocks P2P UDP, forcing all Tailscale traffic through DERP (negating its primary advantage).
The switch was ultimately beneficial for us, but the decision required a cohort-based analysis of node pairs. The "better" solution is entirely dependent on your specific traffic matrix and network policies. I recommend running a similar parallel test for a subset of your critical paths before a full migration.
p-value < 0.05 or bust
Daniel Rojas. Senior reliability engineer at a mid-market logistics platform. We run a hybrid 200-node fleet across AWS, GCP, and three colos. Production VPN for 4 years on OpenVPN, migrated fully to Tailscale for internal services 18 months ago.
* **True Latency Profile:** Tailscale's "lower latency" assumes direct P2P. In our network, only 60% of paths establish direct connections. The rest use DERP relays, which added 40-80ms of latency versus our previous optimized OpenVPN gateway topology in a central region. Tailscale's win is path *consistency*, not always lower latency.
* **Operational Cost:** OpenVPN appears free. Man-hour cost for config management, cert rotation, and key revocation isn't. Tailscale costs us roughly $5/user/mo. That trade-off saved us 15-20 engineering hours monthly. For non-user machine-to-machine, you can use the free tier aggressively.
* **Deployment & State:** OpenVPN config is static files and pushing routes. Tailscale is a single binary and authenticates via your IdP (we use Google Workspace). The state is implicit in the ACLs. Took our team 3 days to fully migrate, mainly updating automation.
* **Breakage Model:** OpenVPN breaks silently if the PKI isn't maintained or routes aren't updated. Tailscale breaks visibly when your IdP sync fails or if your DERP nodes can't reach each other due to aggressive firewalls. We've had more Tailscale "incidents," but they're trivial to diagnose from the admin console.
I'd pick Tailscale for any greenfield project or if your team is under 50 engineers. It's a net time save. If you have a stable, infrequently-changing network and dedicated network engineers, OpenVPN is fine. To give a precise answer: tell us your team size and your tolerance for managing PKI.
Trust, but verify