From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: rspazzol@redhat.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id a7e2eb70 for ; Sun, 16 Sep 2018 18:54:35 +0000 (UTC) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 129f8f60 for ; Sun, 16 Sep 2018 18:54:35 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id p6-v6so11316551ljc.5 for ; Sun, 16 Sep 2018 11:56:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180916165458.GA31165@matrix-dream.net> References: <20180916165458.GA31165@matrix-dream.net> From: Raffaele Spazzoli Date: Sun, 16 Sep 2018 14:56:04 -0400 Message-ID: Subject: Re: what to do when the peers use different IPs to transmit and receive To: =?UTF-8?B?SXZhbiBMYWLDoXRo?= Content-Type: multipart/alternative; boundary="000000000000d0f0600576019bf0" Cc: wireguard@lists.zx2c4.com List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000d0f0600576019bf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'll try to make an example cluster 1 node 1 has private IP1 and VIP1 cluster 2 node 2 has private IP2 and VIP2 each node uses it's private ip for outbound connections. each node can receive inbound connection on its VIP. so the wireguard config file for node1 is going to look like: [peer] endpoint: VIP2:port and for node 2: [peer] endpoint: VIP1: port the problem is that after the handshake, wireguard updates the config to the following (for example for node2): [peer] endpoint: IP1:port but IP2 cannot route to IP1... I think a well configured SNAT rule may work, although is not elegant because it forces the cluster to exchange information about their private IPs. This should not be needed and in the cloud private IPs are ephemeral.... anyway thanks for the advice, I am going to try to use it in my prototype. I still think there is need for a better technical approach for a long term solution. Thanks, Raffaele Raffaele Spazzoli Senior Architect - OpenShift , Containers and PaaS Practice Tel: +1 216-258-7717 On Sun, Sep 16, 2018 at 12:54 PM, Ivan Lab=C3=A1th wrote: > Hi, > > On Sun, Sep 16, 2018 at 08:21:02AM -0400, Raffaele Spazzoli wrote: > > ... then the IP that a node uses for its outbound > > connection is not the same that its peer need to use for its inbound > > connections. > > Who uses what for whose connection? You lost me here. > Looks like a broken network to me. Does TCP even work? > > Anyway, SNAT/DNAT should be able to fix things up, if you want to go > that route. > > Regards, > Ivan > --000000000000d0f0600576019bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll try to make an example
cluster 1 node 1 has p= rivate IP1 and VIP1=C2=A0
cluster 2 node 2 has private IP2 and VI= P2

eac= h node uses it's private ip for outbound connections.=C2=A0
each node can receive inbound connection on its VIP.

so the = wireguard config file for node1 is going to look like:

[peer]
endpoint: VIP2:port

=
and for node 2:
= [peer]=C2=A0
endpoint: VIP1: port

the problem is = that after the handshake, wireguard updates the config to the following (fo= r example for node2):
[peer]
endpoint: IP1:port

but IP2 cannot route to IP1...

I think a well conf= igured SNAT rule may work, although is not elegant because it forces the cl= uster to exchange information about their private IPs.
This should not be needed and in the cloud private IPs are ephe= meral....

anyway thanks for the advice, I am going to try to use it=C2=A0 in my p= rototype.=C2=A0

I still think there is need for a better technical approach for a= long term solution.


=
Thanks,
Raffaele

Raffaele Spazzoli
Tel: +1 216-258-7717


<= /div>

On Sun, Sep 16, 2018 at 12:54 PM, Ivan Lab= =C3=A1th <labawi-wg@matrix-dream.net> wrote:
Hi,

On Sun, Sep 16, 2018 at 08:21:02AM -0400, Raffaele Spazzoli wrote:
> ... then the IP that a=C2=A0 node uses for its outbound
> connection is not the same that its peer need to use = for its inbound
> connections.

Who uses what for whose connection? You lost me here.
Looks like a broken network to me. Does TCP even work?

Anyway, SNAT/DNAT should be able to fix things up, if you want to go
that route.

Regards,
Ivan

--000000000000d0f0600576019bf0--