From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: rcwhelan@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d4bc9654 for ; Tue, 5 Dec 2017 13:58:28 +0000 (UTC) Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id cae9c93b for ; Tue, 5 Dec 2017 13:58:28 +0000 (UTC) Received: by mail-qt0-f174.google.com with SMTP id f2so895208qtj.4 for ; Tue, 05 Dec 2017 06:05:15 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Ryan Whelan Date: Tue, 5 Dec 2017 09:05:14 -0500 Message-ID: Subject: Re: Another allowed-ips question To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="f403043b217cee3cb9055f985262" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --f403043b217cee3cb9055f985262 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 22, 2017 at 6:51 PM, Jason A. Donenfeld wrote: > Hi Ryan, > > Sorry for the delayed response. The high volume and churn of > development recently has gotten me a bit behind on the mail queue and > rather confused. > > You wrote: > > what i'm struggling with is if they are unable to communicate directly > and build routes to one another via an intermediary router (which is also > connected to each 'client' via wireguard). > > If I understood you correctly, you're looking at this situation: Peer > A connects to Peer S. Peer B connects to Peer S. A wants to talk to B, > through S. In this case, the allowed-ips of S on A lists B's internal > IP, and the allowed-ips of S on B lists A's internal IP address. In > other words, you have A/B state that "I trust S to send me the traffic > of B/A." > > Does this answer your question? > > Regards, > Jason > Sorry for my latent reply- I was traveling all last week and have been doing a bad job keeping up on my email I think you understand the setup, mostly. The missing piece is that A and B need to connect directly to one another as well. (Its kind of like a triangle). The idea is that the link between A and B is 'primary' but if they are unable to communicate with one another directly, they will 'fall back' to using the 'Server' (S). A and B will both likely be behind NATs, so is likely that at some point they will both be behind symmetric-nats and be unable to communicate directly, needing the fallback route provided by the server. That said, i think i have a working setup. there are 2 interfaces created. one called 'server0' and one called 'direct0'. On the server interface there is a single peer with an allowed-ips of fc00::/7 and on the direct interface, there is a peer for each of the other devices we want to connect to directly. Each peer on the direct interface has an allowed-ips that matches the addr of the corresponding peer. (/128). That provides 2 routes between peers- route selection is just matter of picking an interface. Hopefully something that will be done via a routing daemon. Hopefully the above makes sense. I think i have a screenshot that will paint a clearer picture if needed. (not sure if i can paste pictures into the mailing list) ryan --f403043b217cee3cb9055f985262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 22, 2017 at 6:51 PM, Jason A. Donenfeld &= lt;Jason@zx2c4.com= > wrote:
Hi Ryan,

Sorry for the delayed response. The high volume and churn of
development recently has gotten me a bit behind on the mail queue and
rather confused.

You wrote:
>=C2=A0 what i'm struggling with is if they are unable to communicat= e directly and build routes to one another via an intermediary router (whic= h is also connected to each 'client' via wireguard).

If I understood you correctly, you're looking at this situation:= Peer
A connects to Peer S. Peer B connects to Peer S. A wants to talk to B,
through S. In this case, the allowed-ips of S on A lists B's internal IP, and the allowed-ips of S on B lists A's internal IP address. In
other words, you have A/B state that "I trust S to send me the traffic=
of B/A."

Does this answer your question?

Regards,
Jason

Sorry for my latent reply- I was = traveling all last week and have been doing a bad job keeping up on my emai= l

I think you understand the setup, mostly.=C2=A0 = The missing piece is that A and B need to connect directly to one another a= s well. (Its kind of like a triangle).=C2=A0 The idea is that the link betw= een A and B is 'primary' but if they are unable to communicate with= one another directly, they will 'fall back' to using the 'Serv= er' (S).=C2=A0 A and B will both likely be behind NATs, so is likely th= at at some point they will both be behind symmetric-nats and be unable to c= ommunicate directly, needing the fallback route provided by the server.

That said, i think i have a working setup.=C2=A0 ther= e are 2 interfaces created.=C2=A0 one called 'server0' and one call= ed 'direct0'.=C2=A0 On the server interface there is a single peer = with an allowed-ips of fc00::/7 and on the direct interface, there is a pee= r for each of the other devices we want to connect to directly.=C2=A0 Each = peer on the direct interface has an allowed-ips that matches the addr of th= e corresponding peer. (/128).

That provides 2 rout= es between peers- route selection is just matter of picking an interface.= =C2=A0 Hopefully something that will be done via a routing daemon.

Hopefully the above makes sense.=C2=A0 I think i have a sc= reenshot that will paint a clearer picture if needed.=C2=A0 (not sure if i = can paste pictures into the mailing list)

ryan

--f403043b217cee3cb9055f985262--