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

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.