Tailscale: High performance hit from using Tailscale (Wireguard)

Created on 9 Aug 2020 · 8Comments · Source: tailscale/tailscale

Describe the bug

Drop off in throughput when using the tailscale IP/VPN is much higher than expected.

To Reproduce
Steps to reproduce the behavior:

Two computers connected by 5 Ghz wifi with IPs in 192.168.x.x and also connected via tailscale
use scp to copy across a 512MB file from one to the other.
Using unencrypted link speed is circa 40MB/s but using TS links, the speed drops to 20MB/s (speeds similar both directions)

Expected behavior

Tailscale (WG) file transfer would be slightly slower than direct/unencrypted link but not half

Version information:

Device: both are x64 hosts.
OS: Windows (WSL) and Ubuntu
OS version: Windows 10, Ubuntu 18.04
Tailscale version: Tailscale 1.0.3

L5 All users P2 Aggravating T3 PerformancDebugging

Source

kellytrinh

Most helpful comment

It's not related, no. The lower metric is deliberate, because we want the secure transport to override any local routes. Otherwise, I could reconfigure my coffee shop's wifi to trick your Tailscale into sending your secure traffic to my local honeypot. The issue you're raising is a separate (and thorny!) problem of how to securely prove to tailscale that it's safe to skip routing through Tailscale in specific networks.

We're thinking about how to do this, but it's a difficult balance to strike between security and usability.

Meantime, this bug is still a good umbrella for performance optimizations on wireguard-go and the Tailscale stack in general.

danderson on 13 Aug 2020

👍4

All 8 comments

Is this related to #144 ? I did a similar test and found that the route metric on windows was lower for the tailscale route than the local directly connected lan route (therefore, it took the tailscale route - thus taking more time - 2x in my test case). This only seems to be a problem on windows.

codepoet4 on 11 Aug 2020

We're thinking about how to do this, but it's a difficult balance to strike between security and usability.

Meantime, this bug is still a good umbrella for performance optimizations on wireguard-go and the Tailscale stack in general.

danderson on 13 Aug 2020

👍4

Did this behaviour change with more recent versions? Tailscale used to be very fast but since I updated on Mac OS a few days ago (and unRAID too btw), a lot of things just time out. It's really annoying, because it used to work flawlessly.

Edit: Seems subnet routed IPs are slow but direct IPs are not.

Jamie4224 on 23 Aug 2020

@Jamie4224, email support@ with your account details or Tailscale IPs giving an example src/dst pair that is failing, and the time it was failing, and we'll look at logs.

bradfitz on 24 Aug 2020

👍1

@bradfitz Thanks! Will do that!

Jamie4224 on 24 Aug 2020

@Jamie4224, your issue is unrelated to this issue and is more of a configuration/build/connectivity issue, and not a CPU/throughput issue. We can work on your issue over email. I'll collapse these comments here as to not distract from OP's issue.

bradfitz on 24 Aug 2020

Oh, we also have https://github.com/tailscale/tailscale/issues/414 open. This might be a dup.

bradfitz on 27 Aug 2020

Just adding my own ping test....

I have WG and TailScale set up between my laptop and a server.
WG ping summary:

8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 10.098/11.253/12.359/0.675 ms

TailScale ping summary:

8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 13.283/14.891/17.396/1.434 ms

which is a decent hit. I mean, day to day it isn't that big a deal but we do often throw large amounts of data down our VPN so worth trying to resolve.