top | item 42133186

(no title)

insaneirish | 1 year ago

I feel like this whole thing buries the lede a bit.

Yes, turns out running overlay/VPN type things disrupts traffic patterns. This is a non-story.

But we're talking about using wireguard on a local network, so the actual interesting question is: why does it cause the performance to plummet? Is it an implementation issue or something more fundamental?

I expect some performance impact. I don't expect a three orders of magnitude impact (which is what 355 KB/s imputes).

discuss

order

thowawatp302|1 year ago

It’s TCP, so bandwidth-delay product, if the hairpin that gets the traffic back to the local lan does anything non-trivial.

EVa5I7bHFq9mnYK|1 year ago

I check the "Allow local network access" in Exit Nodes, then it transfers at max speed over local Ethernet.

windexh8er|1 year ago

This doesn't actually affect anything if you're accepting Tailscale SRs. The conflict the article states is accepting a route advertised by Tailscale for their local network (the SR route) while on the local network (same network as the SR route). This forces all traffic through the wireguard interface, then it's routed to the SR and then back out because the interface metric is better than the hardware because of the link speed advertised. This is the root of the bandwidth issue.

The "Allow local network access" is an IP filter that's put into place or not.