High round-trip and jitter (direct vs tunnel)

SUPPORT QUESTIONS
1

Hi all,

I really like tailscale and currently checking out the free plan and plan to use the paid plan in my company. I did a few tests and discovered that round-trip time is much higher through the tunnel that directly. And I see also a lot of jitter. First I thought it use a relay for some reason but if I interpret the following output correct it doesn’t (there are no asterisk * around the relay “fra”).
And I don’t think the overhead of wireguard is so high or is it?

`
➜ ~ /Applications/Tailscale.app/Contents/MacOS/Tailscale status
[1ocRq] linux 100.121.101.119 jump tx= 77845 rx= 140574 fra 212.120.55.18:15789, [2a02:ab0:100:10::2]:41641, 10.1.10.2:41641

root@server ~ # tailscale status
[jBjTU] macOS 100.69.29.82 macbook tx= 46821 rx= 78570 fra 77.56.115.19:64022, [2001:470:b450:0:f9d1:2fd5:6d5d:b02e]:64023, 172.16.29.11:64022

root@server ~ # ping -c 10 100.69.29.82
PING 100.69.29.82 (100.69.29.82) 56(84) bytes of data.
64 bytes from 100.69.29.82: icmp_seq=1 ttl=64 time=30.4 ms
64 bytes from 100.69.29.82: icmp_seq=2 ttl=64 time=36.5 ms
64 bytes from 100.69.29.82: icmp_seq=3 ttl=64 time=31.1 ms
64 bytes from 100.69.29.82: icmp_seq=4 ttl=64 time=29.0 ms
64 bytes from 100.69.29.82: icmp_seq=5 ttl=64 time=101 ms
64 bytes from 100.69.29.82: icmp_seq=6 ttl=64 time=169 ms
64 bytes from 100.69.29.82: icmp_seq=7 ttl=64 time=101 ms
64 bytes from 100.69.29.82: icmp_seq=8 ttl=64 time=92.3 ms
64 bytes from 100.69.29.82: icmp_seq=9 ttl=64 time=34.8 ms
64 bytes from 100.69.29.82: icmp_seq=10 ttl=64 time=27.3 ms

— 100.69.29.82 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 27.326/65.449/169.318/45.923 ms

root@server ~ # ping -c 10 77.56.115.19
PING 77.56.115.19 (77.56.115.19) 56(84) bytes of data.
64 bytes from 77.56.115.19: icmp_seq=1 ttl=54 time=24.6 ms
64 bytes from 77.56.115.19: icmp_seq=2 ttl=54 time=13.2 ms
64 bytes from 77.56.115.19: icmp_seq=3 ttl=54 time=12.2 ms
64 bytes from 77.56.115.19: icmp_seq=4 ttl=54 time=14.0 ms
64 bytes from 77.56.115.19: icmp_seq=5 ttl=54 time=11.4 ms
64 bytes from 77.56.115.19: icmp_seq=6 ttl=54 time=11.1 ms
64 bytes from 77.56.115.19: icmp_seq=7 ttl=54 time=12.4 ms
64 bytes from 77.56.115.19: icmp_seq=8 ttl=54 time=11.3 ms
64 bytes from 77.56.115.19: icmp_seq=9 ttl=54 time=17.6 ms
64 bytes from 77.56.115.19: icmp_seq=10 ttl=54 time=13.4 ms

— 77.56.115.19 ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 11.126/14.169/24.672/3.941 ms
`

Does anyone have an idea?

Br,
Stefan.

1 Like
2

I just found out that tailscale preffer ipv6 over ipv4 and in this case it use the ipv6 tailscale relay. And I complete forgot that I use hurrican electric as a ipv6 tunnel broker in my home office. :wink: But this should not matter in my planned purpose of use. It looks that it also can’t get direct connection with ipv6 through the firewalls on both end. why is another question that I need to check out. In my opinion it should be possible to get through both firewalls with udp hole punching… but i need to look further into it…

Br,
Stefan

3

Hi Stefan,

One thing you can try is “tailscale netcheck” on both ends to see how your firewall is characterized. The key entries are UDP (if it’s not true, then UDP is blocked and there’s no chance of direct connection) and “MappingVariesByDestIP” (if it’s true, then it’s a “hard” NAT as defined by https://tailscale.com/blog/how-nat-traversal-works/). If you control the firewall, usually you can affect the values of these, which will make it possible to form a more efficient point-to-point connection.

2 Likes