Need to investigate the Double-Hop feature #88
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Need to check current functionality. Might want to make it so you can start a hop after already connected, or start treating the current connection as a hop and make the new server a main connection. Can look at the posts mentioned in the README, then maybe remove those posts as it's clutter. Might want to confirm fears about speed degradation. Lastly want to check online about demand for this feature and usefulness of this feature for privacy.
This work will be single provider for now until we expand into more provider support where it'll naturally be part of the integration testing.
Findings on the demand/privacy questions (the research half of this issue):
Privacy value is real, but lives almost entirely in the cross-provider form. Multi-hop's benefit is that no single server sees both who you are and where you're going. The standard criticism of first-party multi-hop (Nord Double VPN, Proton Secure Core, Mullvad multihop) is that one operator runs both hops — one court order, breach, or logging decision recovers both halves at once. Cross-provider chaining answers exactly that, and no first-party client can offer it by definition. Single-provider double-hop is the weak form: it still defends against a single compromised exit server and correlation at the exit, but not against the operator — and per the README only AirVPN and Windscribe even allow two concurrent connections from one account.
The threat model that needs it is narrow: adversaries able to compel or compromise a VPN provider (journalists, activists, state-level surveillance). Single-hop covers everyday use — ISP privacy, geo, public Wi-Fi. That said, "privacy-maximalist Linux user running a FOSS VPN GUI" overlaps that slice far better than the general VPN market does.
Demand is thin and shrinking. Upstream billed it as the headline unique feature in 2018, but major providers now ship first-party multi-hop, which absorbs the casual demand and leaves only the cross-provider case as differentiating. Being OpenVPN-only makes it invisible to WG-first users — in 2026, most new users.
Speed fears: expect confirmed, and it's physics, not a defect. Latency is additive (traffic transits hop A before exiting at B), throughput is bounded by the worse path, and userland OpenVPN crypto is paid twice. Roughly halved throughput and summed ping is the honest baseline. Needs a README sentence, not engineering.
README links (the 2010-era OpenVPN forum thread and the VPN-Chain repo): archaeology, fine to remove — the technique lives in
tunnel.pyandscripts/hop.shnow.Verdict: keep the feature; cross-provider chaining is its whole reason to exist. Don't polish the single-provider form beyond "not broken" — it's the weaker privacy story and restricted to two providers anyway. WireGuard support is the lever if double-hop is ever to matter to new users: split to #176.
Sources: NymVPN on double VPN, CyberInsider multi-hop roundup, PIA on multi-hop, ExpressVPN on multi-hop
Still open here: verify current functionality actually works, confirm the speed numbers while at it, and drop the README links.
Correction to the comment above: the "only AirVPN and Windscribe" restriction was a stale 2018-era README claim — ProtonVPN paid plans allow 10 simultaneous connections and same-provider double tunnels have been confirmed working on one. README reworded in #177, so Proton is a valid provider for the functionality test here.
Speed numbers confirmed live 2026-08-29 (same-region pair us-472 → us-548, single-stream download from nyc.download.datapacket.com, ping to 1.1.1.1):
Double-hop over single-hop: +7 ms, −13% throughput — far milder than the halved-throughput expectation above. Two reasons: ovpn-dco does the crypto in-kernel, so paying it twice is not the bottleneck, and latency is additive by the hop's actual distance, so a same-metro pair costs almost nothing. The physics story stands, DCO just shrinks it. README sentence should say: additive latency per hop, moderate throughput loss — not halved.