Another allowed-ips question

Another allowed-ips question

[Ryan Whelan]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

I'm working on a system where Wireguard machines can connect directly to
one another as well as communicate with one another via an intermediary
router (or 'server').

When 2 machines directly connect to one another, the allowed-ips setting is
obviously a non-issue; 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).  Unless
the 'server' NATs the traffic, the allowed-ips setting will prevent the
'clients' from communicating.  Am i missing something?

I'm trying to avoid building a wg interface for each peer connection if
possible, but i'm failing to see any other way around it.  Either NAT at
the intermediary router or create an interface per-peer.

Are there other options?

[-- Attachment #2: Type: text/html, Size: 966 bytes --]

Re: Another allowed-ips question

[Reuben Martin]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Nov 18, 2017 5:44 PM, "Ryan Whelan" <rcwhelan@gmail.com> wrote:

I'm working on a system where Wireguard machines can connect directly to
one another as well as communicate with one another via an intermediary
router (or 'server').

When 2 machines directly connect to one another, the allowed-ips setting is
obviously a non-issue; 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).  Unless
the 'server' NATs the traffic, the allowed-ips setting will prevent the
'clients' from communicating.  Am i missing something?

I'm trying to avoid building a wg interface for each peer connection if
possible, but i'm failing to see any other way around it.  Either NAT at
the intermediary router or create an interface per-peer.

Are there other options?


I have something kinda similar. I set up vxlan connections overtop of the
wireguard connections and added the vxlan interfaces to bridges.

-Reuben

[-- Attachment #2: Type: text/html, Size: 1578 bytes --]

Re: Another allowed-ips question

[Jason A. Donenfeld]

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

Re: Another allowed-ips question

[Ryan Whelan]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

On Wed, Nov 22, 2017 at 6:51 PM, Jason A. Donenfeld <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:
> >  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

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]