Roaming Mischief
Markus Woschank
markus.woschank at gmail.com
Fri Nov 17 19:46:53 CET 2017
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 <aaronmdjones at gmail.com> 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-----
More information about the WireGuard
mailing list