TCP Setup Time is the VPN Metric Nobody's Measuring
And it’s the one that breaks modern infrastructure.
If you've ever benchmarked a VPN, you've probably done it the same way everyone else does: spin up `iperf3`, push as much TCP as the pipe will carry, and write down a Mbps number. It's a clean test. It's also the wrong number to chase for most of what runs on modern infrastructure.
APIs, dashboards, monitoring, control planes, CI agents, and database health checks. These aren't bandwidth-bound workloads. They open lots of short-lived connections, do a small amount of work, and tear down. For that pattern, throughput tells you almost nothing. Setup time tells you everything.
Xiid® benchmarked Terniion’s SealedTunnel technology against WireGuard, Tailscale, OpenVPN, IPsec, and a direct public path from an intentionally constrained edge client (Ubuntu on an older Xeon, behind WiFi, on a consumer/satellite-class uplink) into six AWS and GCP endpoints. The throughput results were competitive. The setup time results weren't even close.
Seven to twenty-two milliseconds. Across every path.
TCP setup time, median milliseconds across three runs. Lower is faster.
Across every path tested, SealedTunnel's setup time stayed inside a 7-to-22 ms band. Everything else lived between 47 and 258 ms, with the long-haul AWS Singapore path pushing every traditional transport past a quarter-second.
The mechanism is straightforward. The application connects to a local STLink binding while the encrypted tunnel path is already established. So a new connection from your code to the local binding completes at near-loopback speed, regardless of how far the remote endpoint actually sits.
This is not raw network RTT, and we don't claim it is. The practical effect is what matters: application-level connection setup completes in single-digit milliseconds even across an intercontinental path.
Setup time compounds fast.
A request budget of 250 ms per TCP setup sounds tolerable until you put it in context. A modestly chatty service: think of a dashboard refreshing widgets, a health-check sweep, or an integration that polls a REST endpoint; can open a thousand connections in a minute. At 250 ms each, that's over four minutes of pure connection setup before a single byte of payload moves. Push the same workload through SealedTunnel and the same thousand connections cost about twenty seconds.
That's the difference between a dashboard that feels live and one that feels broken. It's the reason a teammate three time zones away thinks the system is down when it's just shaking hands.
On the path where edge links break, throughput nearly doubled.
For completeness: SealedTunnel stayed inside the same practical throughput envelope as every other tested transport on US paths. On the long-haul AWS Singapore path, it pulled meaningfully ahead — 5.79 Mbps median TCP, versus 1.99-3.08 Mbps for the rest.
Intercontinental paths are where constrained edge links suffer most. In this run, SealedTunnel's path through the connector service delivered a better effective TCP route than even the direct public link.
Speed is the bonus. Architecture is the product.
And connection time is the visible win. SealedTunnel requires no open inbound ports on the protected endpoint. The tunnel is outbound-only. The endpoint is non-addressable from the public internet so there are no IPs to expose, no listeners to scan, no NAT traversal contortions. Access is process-to-process, not subnet-to-subnet, so a compromised endpoint cannot pivot across the network. There is nothing on the other end to pivot into except the specific service you mapped.
For organizations securing remote sites, field systems, regulated workloads, or critical infrastructure, that's the result that matters. The speed result is a nice surprise on top of it.
Pick SealedTunnel when these are true.
Reach for it when any of these describe your situation:
You can't open inbound ports, whether for regulated, field, or critical-infrastructure access.
Your workload is connection-chatty: APIs, dashboards, monitoring, short-lived service calls.
You're operating over messy edge links: NAT-heavy, satellite, and branch sites with consumer uplinks.
You need to limit lateral movement to specific services, not whole subnets.
Want the full methodology, raw data, and limitations in the Xiid edge-to-cloud benchmark paper? Read it, then run it yourself. A setup-time gap this wide either holds up or it doesn't.