From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: luizluca@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3488d3bc for ; Sat, 14 Apr 2018 19:01:57 +0000 (UTC) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 537a71d4 for ; Sat, 14 Apr 2018 19:01:57 +0000 (UTC) Received: by mail-ot0-f178.google.com with SMTP id w2-v6so2369445otj.12 for ; Sat, 14 Apr 2018 12:16:16 -0700 (PDT) MIME-Version: 1.0 From: Luiz Angelo Daros de Luca Date: Sat, 14 Apr 2018 19:16:04 +0000 Message-ID: Subject: Sharing peer data To: wireguard@lists.zx2c4.com Content-Type: multipart/alternative; boundary="00000000000095271c0569d3d26e" List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --00000000000095271c0569d3d26e Content-Type: text/plain; charset="UTF-8" Hello, In a setup node A <> node B, node A <> node C, C might talk to B passing through A. Would it be possible that A could share B and C info (ip and pubkey) in other to them to talk to each other directly? It would be similar to ip redirect. Node A must be trusted by both for that. Regards, -- Luiz Angelo Daros de Luca luizluca@gmail.com --00000000000095271c0569d3d26e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,

In a setup node A <> node B, node A <>= ; node C, C might talk to B passing through A. Would it be possible that A = could share B and C info (ip and pubkey) in other to them to talk to each o= ther directly? It would be similar to ip redirect. Node A must be trusted b= y both for that.

Regards,
--

Luiz Angelo Daros de Luca
luizluca@gmail.com

--00000000000095271c0569d3d26e-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Jason@zx2c4.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 47cebc86 for ; Sat, 14 Apr 2018 23:01:02 +0000 (UTC) Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 363e97eb for ; Sat, 14 Apr 2018 23:01:02 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 79a56048 for ; Sat, 14 Apr 2018 22:52:11 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 731e2521 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Sat, 14 Apr 2018 22:52:10 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id 188-v6so11438035oih.8 for ; Sat, 14 Apr 2018 16:15:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: "Jason A. Donenfeld" Date: Sun, 15 Apr 2018 01:15:20 +0200 Message-ID: Subject: Re: Sharing peer data To: Luiz Angelo Daros de Luca 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: , Hi Luiz, You could indeed arrange for something like this, either directly -- if both IPs are accessible or if A is able to punch a hole -- or relayed, if you can't establish a direct session. This is similar to what Tinc does. Namely, this falls in the category of, "making a full mesh from a partial mesh." I say, "you could", because currently this is something people are generally doing manually with WireGuard. However, there's a GSoC project for making a minimal mesh networking utility for WireGuard, which I hope pans out, and maybe even Tinc integration. So we'll see what happens in this space. Jason From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: luizluca@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 21ae611a for ; Sun, 15 Apr 2018 03:04:39 +0000 (UTC) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 33cafae1 for ; Sun, 15 Apr 2018 03:04:39 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id 26-v6so2089172ois.9 for ; Sat, 14 Apr 2018 20:19:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luiz Angelo Daros de Luca Date: Sun, 15 Apr 2018 03:18:49 +0000 Message-ID: Subject: Re: Sharing peer data To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="000000000000ffdad20569da9021" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000ffdad20569da9021 Content-Type: text/plain; charset="UTF-8" Thanks Jason, Yes, something very similar to tinc. I imagine having two or more static/known peers (redundancy) configured on every node. Once connected, they discover the others. It's good to know there is a GSoC for something like it. -- Luiz Angelo Daros de Luca luizluca@gmail.com --000000000000ffdad20569da9021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jason,

Yes, something very similar to tinc. I ima= gine having two or more static/known peers (redundancy) configured on every= node. Once connected, they discover the others.

I= t's good to know there is a GSoC for something like it.
--
=

Luiz Angelo Daros de Luca
luizluca@gmail.com

--000000000000ffdad20569da9021-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: smntov@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id ddf4d319 for ; Sun, 15 Apr 2018 09:53:56 +0000 (UTC) Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 402edd6a for ; Sun, 15 Apr 2018 09:53:56 +0000 (UTC) Received: by mail-wr0-f175.google.com with SMTP id z73so18242481wrb.0 for ; Sun, 15 Apr 2018 03:08:19 -0700 (PDT) Return-Path: Message-ID: <1523786895.1990.5.camel@gmail.com> Subject: Re: Sharing peer data From: ST To: "Jason A. Donenfeld" Date: Sun, 15 Apr 2018 13:08:15 +0300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sun, 2018-04-15 at 01:15 +0200, Jason A. Donenfeld wrote: > Hi Luiz, > > You could indeed arrange for something like this, either directly -- > if both IPs are accessible Which IPs do you mean here? Public IPs or private VPN IPs (i.e. those defined within WireGuard configuration)? I got an idea how to do that using SFTP... I'll write about it in a separate email... Just one question: let's assume B and C got the required information about each other's IPs/public keys from A. Will they now communicate directly without relying on A in whatever way?... It is important to know for the case when A is a server with metered paid traffic... Will the communication between B and C affect the traffic of A or not? Thank you! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: luizluca@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id c14e9768 for ; Mon, 16 Apr 2018 01:32:44 +0000 (UTC) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 2dcf4522 for ; Mon, 16 Apr 2018 01:32:44 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id h11-v6so3764282oic.3 for ; Sun, 15 Apr 2018 18:47:12 -0700 (PDT) MIME-Version: 1.0 References: <1523786895.1990.5.camel@gmail.com> In-Reply-To: <1523786895.1990.5.camel@gmail.com> From: Luiz Angelo Daros de Luca Date: Mon, 16 Apr 2018 01:47:01 +0000 Message-ID: Subject: Re: Sharing peer data To: ST Content-Type: multipart/alternative; boundary="0000000000008ad6850569ed665c" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --0000000000008ad6850569ed665c Content-Type: text/plain; charset="UTF-8" > > Just one question: let's assume B and C got the required information > about each other's IPs/public keys from A. Will they now communicate > directly without relying on A in whatever way?... It is important to > know for the case when A is a server with metered paid traffic... Will > the communication between B and C affect the traffic of A or not? In my point of view, it is something that all nodes must agree to accept (a non-default option). Of course, if node A wants to measure traffic, it ahould not allow it, forcing all traffic from B to C to pass through it. I imagine something like: Node A: hey node B, I noticed that you are sending traffic to another remote node (node C). You can continue to send traffic through me but, in parallel, could you please try to contact node C directly? It is currently using ip x.x.x.x and its pubkey is aaaaaa. -- Luiz Angelo Daros de Luca luizluca@gmail.com --0000000000008ad6850569ed665c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just one question= : let's assume B and C got the required information
about each other's IPs/public keys from A. Will they now communicate directly without relying on A in whatever way?... It is important to
know for the case when A is a server with metered paid traffic... Will
the communication between B and C affect the traffic of A or not?

In my point of view, it is something that all = nodes must agree to accept (a non-default option). Of course, if node A wan= ts to measure traffic, it ahould not allow it, forcing all traffic from B t= o C to pass through it.

I imagine something like:<= /div>

Node A: hey node B, I noticed that you are sending= traffic to another remote node (node C). You can continue to send traffic = through me but, in parallel, could you please try to contact node C directl= y? It is currently using ip x.x.x.x and its pubkey is aaaaaa.
--

Luiz Ang= elo Daros de Luca
luizluca@gmail.com

--0000000000008ad6850569ed665c--