3 ms·

This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a

by cyphar 7y ago

This is not always required. WireGuard peers can roam freely very similarly to Mosh (if one peer receives an authenticated message from one of its peers from a different IP address, it will update the gateway of that peer and will send all subsequent packets to that IP address). But to be fair, this doesn't work perfectly (especially if you have certain firewall rules that block UDP packets if they're not part of the what the firewall thinks is the same "connection", if both peers change their IP at the same time, or if the peer whose IP changed was rebooted or reconfigured before the other peer received a packet from its new IP addreds) but it really does work surprisingly well. For those (important) corner-cases, I would imagine that higher-level tooling such as NetworkManager would do the DNS checks you're talking about.

jcrawfordor 7y ago
Right, the free roaming tends to be on "the other side" though. This is a bit confusing to talk about because Wireguard does not have a concept of "client" and "server" and either side can nominally initiate the tunnel. However, in roaming configurations, typically only one side will have the information to initiate the connection (endpoint) and so there's a tendency to call this the "client." The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment). Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.

by cyphar 7y ago

jcrawfordor 7y ago

Right, the free roaming tends to be on "the other side" though. This is a bit confusing to talk about because Wireguard does not have a concept of "client" and "server" and either side can nominally initiate the tunnel. However, in roaming configurations, typically only one side will have the information to initiate the connection (endpoint) and so there's a tendency to call this the "client." The non-roaming end (end with a known endpoint) will update the IP of the roaming end every time a handshake occurs. The issue the OP is getting at though is when both ends are roaming. In this case the, er, "more roaming" peer needs some way to find the other peer. There are a lot of technically interesting ways that we could solve this problem, but in practice it's pretty much always solved by dynamically updating a DNS record. I would say Wireguard handles this scenario about as well as anything else (maybe a little worse, see sibling comment). Another approach would be using a "meet-me" relay with a fixed IP, such as TURN. This also has the advantage of handling NAT on both sides (which would be a common issue with a roaming-to-roaming situation). I can't think of any reason it's impossible to run Wireguard through TURN but I can't find any examples of anyone doing so, likely in part because the TURN client is usually embedded in the application and is a bit complicated. Still, might be a hobby project to implement it for Wireguard.