Recently I’ve had to do some travel in areas with poor connectivity (mostly train but also a bit of car). We actually have a home tailnet, with several exit nodes, etc; mostly for convenience but also for NAT traversal for the at-home services; you know the usual. Anyway, I complained that the exit node on a VM on our router (named lily-white) actually wouldn’t let any traffic through, which forced me to switch exit nodes to one of my dedicated servers. This seemed to cause some confusion, lead to Hélène (my wife) to ask me why I have an exit node enabled on the train: shouldn’t this extra hop be strictly worse for connectivity? While I have her a satisfactory answer on the spot, I figured I’d also write it down here too.
So why does rural connectivity suck? #
You might have noticed that when you’re outside of urban areas, you still have several connectivity bars up. Indeed you are connected to a tower. So why does browsing work so poorly? Let’s start with the first, more common answer: speed.
When you’re travelling through an area, the actual amount of data that can get to you varies based on your movement. If you’re going faster, you’ll be able to pass less data through. This leads to a very low bandwidth (especially when speeds significantly exceed 100km/h, as they do in a TGV), as well as very high packet drop. This is a recipe towards nothing ever getting through to you.
We have packet loss at home! #
You might contest this: you might have occasionally high packet loss at home (my condolences, I’m glad my home connection works great unless it’s completely down), but the experience isn’t as bad. The low bandwidth argument is unconvincing because no data is managing to finish getting through at all, in fact. You would be right to contest this! We can go to the other problematic component.
Since you’re moving quickly, you are actively negotiating with different towers as you keep moving along. The mobile towers typically are not configured with any sort of predictive pass over in mind, so unless you fully get the packet while you’re under one tower (unlikely due to the low bandwidth), your device will simply have to start over with the next one.
What’s worse is that you are likely to experience an IP change as you switch from one tower to another, since to the network this is likely to look like a disconnect and then a new connection. They’re not often fully handled in software, so it’s reasonable to expect the hardware acceleration to simply hand you a new lease and be done with it. That means, though, that your IP is now different, and the old packet from the old tower is no longer heading towards you, and you have to go all the way back to asking the requesting server to issue you a completely new stream. For example, instead of having to retry many times for each given chunk of a web page you might want to load, you now have to restart loading the entire page after having received a chunk of it. You’ve certainly seen the classic “network disconnect” or “the server has stopped responding” errors.
So how does an exit node help? #
Well, remember that a Tailscale exit node is fundamentally wireguard with some magic sprinkles. It remembers your identity since that is what it’s based on, and automatically switches how it will route your tunnel when it receives a UDP packet from your end. Your device will automatically send such a UDP packet when network conditions change. This can then be “resumed” unlike TCP because it’s not a stream based protocol. In the meanwhile, the requesting server will actually see the exit node’s IP, and so nothing will change for it. The practical consequence is that even if your IP changes, if you’re using a wireguard-based default route VPN (which is what a Tailscale exit node is), you no longer have the above failure condition. Even if things go poorly (and they will, repeatedly), you’ll be able to continue loading a given resource chunk by chunk (albeit with many retries) until you either get there, or a lengthier timeout is hit.
As I put it to Hélène: with the exit node, I get the packets eventually even if slowly; without it I don’t.