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 9d8fc83e for ; Fri, 17 Nov 2017 22:07:19 +0000 (UTC) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id f01ba22c for ; Fri, 17 Nov 2017 22:07:19 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id f135so2661623oib.0 for ; Fri, 17 Nov 2017 14:11:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <593d6d3a-550e-a14d-4c1d-f7ee8e731d87@gmail.com> <630c9955-ae3a-bf10-02ae-e5aa7eee6e64@gmail.com> From: Markus Woschank Date: Fri, 17 Nov 2017 23:11:49 +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: , > where you need to make sure that while one peer is down the other doesn't move. This is obviously wrong, should be: "where you need to make sure that only one side changes it's network while one is down." On 17 November 2017 at 23:06, Markus Woschank wrote: >> My example is most useful when both endpoints are roaming and either >> endpoint needs to be able to initiate sessions. It's not a very >> common scenario I'll give you that, but the current full roaming >> support does enable it seamlessly (when you also enable keep-alives). > > Thank you for clarifying. > > This really sound like an unusual situation, where you need to make > sure that while one peer is down the other doesn't move. > I wonder if this could not, should the need arise, be solved in another fashion. > > From experience I have another concern towards the current mechanism. > When configuring two peers pointing at each other and by mistake > setting one endpoint IP to a wrong value (typo in the IP) there is a > good chance this mistake may not be noticed for quiet some time, if > the correctly configured endpoint initiates the connection most of the > time. The user (me), believing to have correctly configured the link, > may be taken by surprise at a later point in time when the link is not > established, as he expects, when the wrongly configured side tries to > initiate it after say a reboot. This is more of a concern to me than > supporting to roaming peers. > > Also the thought of something like `wg showconf wg0 > > /etc/wireguard/wg0.conf` happening at shutdown frightens me a little. > Because if the command fails for whatever reason the configuration > will be truncated and after the reboot completes the link will be > non-functional (conf vs state). > > Please don't interpret my comments the wrong way, I grew to love > wireguard. Just trying to state the kinks (IMO) I see, and this is one > of them. > I still vote for: if an endpoint is specified, don't allow the peer > from another source - no config syntax change needed ;). > > Markus