> One more thing about this part, the way wg is designed, one endpoint > can change its ip, and when it sends anything over the tunnel the > remote peer will update its idea of your clients ip+port. Then X > seconds later, the remote endpoint can change its ip+port and as soon > as it sends any packet over the link to your new ip+port, it will > reestablish the tunnel again, then you can switch ip later on and so > forth, as long as you don't both change ips at the same time.
Ah, so the responder can change IPs mid-session and update the initiator? I see where this could be useful in a dynamic DNS situation where the TTL is such that the DNS record of the responder hasn't yet updated. > The expectation is definitely that if a peer changes its > ip+port, and doesn't send anything to update its remote peer, the > remote peer will be sending packets into the void until the tunnel can > be re-established correctly again. This is the part I'm having trouble wrapping my head around. As long as traffic is attempting to flow, the responder will never stop trying to reestablish the handshake, even in scenarios where it is impossible. The irony is that what you described makes wg ideal for mobile networks with CG-NAT and frequently changing IPs. But I feel it ignores this common use case. For example, take a mobile device that has entered an aircraft (assume it's Ryanair-tier so no wifi). This device will be incommunicado for at least a few hours, and when it regains connectivity, there is a high probability it will receive a different IP address. Therefore, for the responder to keep reaching out to the last known dynamic IP for hours on end seems like a waste of packets.... While the responder doesn't *know* the initiator's IP is dynamic and subject to change, it knows it's not explicitly defined as an endpoint in its config so an assumption can be made it's at best unreliable. For comparison, MOBIKE places the responsibility for failure recovery onto the initiator per RFC 4555 and there is an expectation the responder will give up at some user-defined value. A potential workaround to this is to have a cron job which monitors the latest handshake time and restarts the interface if it ages beyond a reasonable value (say 5 minutes). I believe keepalives are required to be enabled for this to work properly. My hope is that as the wg protocol matures, this be considered a feature enhancement whereby you can place a maximum aged handshake into the .conf file, after which it will give up shouting into the void, rather then resorting to ugly hacks such as the script mentioned above. Appreciate the extended discussion on this. Regards Lloyd
