From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: jan@delandtsheer.eu Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 18f98da4 for ; Thu, 10 Aug 2017 16:35:10 +0000 (UTC) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 8ca10b2f for ; Thu, 10 Aug 2017 16:35:10 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id l82so8306499ywc.2 for ; Thu, 10 Aug 2017 09:57:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jan De Landtsheer Date: Thu, 10 Aug 2017 16:57:05 +0000 Message-ID: Subject: Re: FR: interface ListenAddress (Aka:Multihomed server issue) To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="94eb2c07b99eb5643b055669165e" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --94eb2c07b99eb5643b055669165e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable no, very simple =E2=80=A6 I have (for the sake of brevity) 2 interfaces: one is eth0 with ip 123.45.67.1/30 and I have on the box 123.45.67.2 as default gateway. on that link I bgp peer with 123.45.67.2 and announce my own /24, let=E2=80= =99s say 134.56.78.0/24 another eth interface (eth1) hosts several ip addresses and one of these is 134.56.78.5/24 for that interface I allow port 443 to accept packets for [Interface] ListenPort =3D 443 but I do not allow packets to connect to 123.45.67.1/30 on port 443 (as this iface is just my Provider=E2=80=99s /30 when a client connects to 134.56.78.5/24, the wg server tells the client that it=E2=80=99s destination is 123.45.67.1/30 for this link , and that ge= ts of course firewalled. So reluctantly I opened up port 443 on the uplink interface to accomodate this, erm, inconvenience. on client side I have a config : [Peer] PublicKey =3D (hidden) EndPoint =3D 134.56.78.5:443 AllowedIPs =3D 0.0.0.0/0 but when connection is established wg show says : peer: (hidden) endpoint: 123.34.56.1:443 allowed ips: 10.0.0.0/8 latest handshake: 36 seconds ago transfer: 468.40 MiB received, 17.88 MiB sent but now of course, when the third interface eth2 will arrive, with another subnet to another provider, my announced IP 134.56.78.5/24 may not be altered by the path taken, otherwise the clients need to reconnect=E2=80=A6 but I don=E2=80=99t know for sure=E2=80=A6 it seems to be a regression some= where as I don=E2=80=99t recall to have that problem before=E2=80=A6 I had to add this accept rule l= ast week, suddenly, as some peers could connect, but not transfer packets any more. Now I understand that wg finds it=E2=80=99s IP by following the shortest pa= th, but that is, in my case, counterproductive. It should reply with the IP it was spoken to (here 134.56.78.5) I think ;-) Jan On Thu, Aug 10, 2017 at 5:51 PM Jason A. Donenfeld wrote: Hey Jan, > > > When wireguard clients connect, their config shows their peer > > to be the Uplink IP address instead of the IP on the Public > > interface that was specifically assigned for wireguard (wgsrv) > > Do you mean to say that the _endpoint_ IP address of the WireGuard > peer is an IP associated with Uplink instead of with Public? If this > is the case, it might be some odd DNAT situation causing this to > happen for you? The peer's endpoint IP address is simply the src IP of > the most recently authenticated packet from the peer. It sounds like > there's something odd in place causing the src IP to be wrong? But I > can't think of how this would be WireGuard related. Unless I've > misunderstood something? > > Jason > =E2=80=8B --94eb2c07b99eb5643b055669165e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

no, very simple =E2=80=A6
I have (fo= r the sake of brevity) 2 interfaces:

one is eth0 with ip 123.45.67.1/30 and I have on the box 123.45.67.2= as default gateway.
on that link I bgp peer with 123.45.67.2 and announ= ce my own /24, let=E2=80=99s say 134.56.7= 8.0/24

another eth interface (eth1) ho= sts several ip addresses and one of these is 134.56.78.5/24

for that interface I allow port= 443 to accept packets for 

[Interface]
ListenPort =3D 443

but I do not allow= packets to connect to 1= 23.45.67.1/30 on port 443 (as this iface is just my Provider=E2= =80=99s /30

when a client connects to 134.56.78.5/24, the wg server tells the cl= ient that it=E2=80=99s destination is 123= .45.67.1/30 for this link , and that gets of course firewalled.
So r= eluctantly I opened up port 443 on the uplink interface to accomodate this,= erm, inconvenience.

on client side I have a config = :

[Peer]
PublicKey =3D (hidden)
EndPoint =3D 134.56.78.5:443
AllowedIPs =3D  0.0.0.0/0

but when connectio= n is established
wg show says :

peer: (hidden)
  endpoint: 123.34.56.1:443
  allowed ips: 10.0.0.0/8
  latest handshake: 36 seconds ago
  transfer: 468.40 MiB received, 17.88 MiB sent

but now of course,= when the third interface eth2 will arrive, with another subnet to another = provider, my announced IP 134.56.78.5/24<= /a> may not be altered by the path taken, otherwise the clients need to rec= onnect=E2=80=A6

but I don=E2=80=99t know for su= re=E2=80=A6 it seems to be a regression somewhere as I don=E2=80=99t recall= to have that problem before=E2=80=A6 I had to add this accept rule last we= ek, suddenly, as some peers could connect, but not transfer packets any mor= e.

Now I understand that wg finds = it=E2=80=99s IP by following the shortest path, but that is, in my case, co= unterproductive.
It should reply with the IP it was spoken to (here 134.= 56.78.5)

I think ;-)

Jan

On Thu, Aug 10, 2017 at 5:51 PM= Jason A. Donenfeld <Jason@zx2c4.com> wrote:

Hey Jan,

> When wireguard clients connect, their config shows their peer
> to be the Uplink IP address instead of the IP on the Public
> interface that was specifically assigned for wireguard (wgsrv)

Do you mean to say that the _endpoint_ IP address of the WireGuard
peer is an IP associated with Uplink instead of with Public? If this
is the case, it might be some odd DNAT situation causing this to
happen for you? The peer's endpoint IP address is simply the src IP of<= br> the most recently authenticated packet from the peer. It sounds like
there's something odd in place causing the src IP to be wrong? But I can't think of how this would be WireGuard related. Unless I've
misunderstood something?

Jason

=E2=80=8B
--94eb2c07b99eb5643b055669165e--