From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: markus.woschank@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id bb028c8d for ; Fri, 17 Nov 2017 18:42:23 +0000 (UTC) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 2a449d57 for ; Fri, 17 Nov 2017 18:42:23 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id v123so2277179oif.12 for ; Fri, 17 Nov 2017 10:46:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <593d6d3a-550e-a14d-4c1d-f7ee8e731d87@gmail.com> From: Markus Woschank Date: Fri, 17 Nov 2017 19:46:53 +0100 Message-ID: Subject: Re: Roaming Mischief To: Aaron Jones Content-Type: text/plain; charset="UTF-8" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , After some more thoughts, in the scenario that you are describing, where does persisting the state on the roaming peer help? The roaming peer has the fixed peer's address in his configuration (his IP does not change), and the remote side did not suspend. Am I missing something here? Markus On 17 November 2017 at 18:36, Aaron Jones wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 17/11/17 17:23, Markus Woschank wrote: >> Please prove me wrong and supply an example where it makes sense >> to have a roaming peer's endpoint set, where the roaming peer >> _really_ roams (changes it's IP) and where on >> reboot/reset/whatsoever the originally set endpoint IP in the >> configuration magically makes any sense again. >> >> Markus > > "Originally" is the fallacy. wg-quick(8) can persist the current state > of the interface to the configuration file on shutdown, and restore it > on reboot. This is precisely what you would enable in an actual roaming > scenario. > > Roaming means that the current endpoint (at shutdown time) would be > persisted, and if the reboot doesn't take very long, it is highly > likely that the (new) endpoint does still make sense, particularly > because UDP is used which means new sessions can usually resume as if > nothing happened, even through a NAT (though if you are also behind a > NAT, source port randomisation may trip you up if you don't have it > forwarded through the remote one, but that's beside the point). > > - -- > Aaron Jones > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJaDx4MAAoJEIrwc3SIqzAS36sQAK6RCyxC1QZROnrGT40YxjUq > cu/2yY/jUvyhN+O7vaPslw74A+DQGCmFyjSYjr7bw6zzS1fV0nH9IKa+3gRUmPke > Q9qEIdw+z39bNbpqWewBFYkIEBXj00/M50+CzWEKncrnbbAG8oUKxtM3sgjuNTpd > uDBe2yzxeYORkUt/WhFz4GR9bggmyNR8AzHBZ8MedSuceLgQQ+65G7+LZ2jixna+ > 3jpO7BGdQxM4hv+oTgHJ2IlTjK+LjCJ0HnR2j+sFas9KvZFXbNEi46bS3/+HZ8w5 > fncVTZyh8Ez+GC6lCX4UfdMyTKc3U72XdL42LaoW+biketJ9S5GyY1MeDMVhtBWR > h/rO4aiRGZMUkxdpS4geUQ1tIPnLzIDN42tORrszE80o8Fd5iF/mj2IyXVRLkvj2 > iyaERFeyTgKw3jvjPFKXeRjgUgGfwFtqpdA+ycXtI8heO/8GxZIqlrVwgpRyD/iA > JuCAucCF1HQtLJp51QfvJ3eEH2JmZvGgDk2COLhKt0hH6Wr4p/nDRasA9NS2HJEe > xJKKvERPTNSsmA+0a/WLRGrSPDxJJVLy0nQW9c/9dtwUZspUGJ7DHfSutCuShy6r > OSkTITSuZk7fjtEfVF1X7nV8F6GIVq8Xu7gk4B7EkekW6Z/QD9x7+PniLhjTkha7 > +uGtIXqsnKaQ6miBKduu > =PxWC > -----END PGP SIGNATURE-----