Re: FR: interface ListenAddress (Aka:Multihomed server issue)

[Jan De Landtsheer <jan@delandtsheer.eu>]

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

no, very simple …
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’s 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 = 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’s /30

when a client connects to 134.56.78.5/24, the wg server tells the client
that it’s destination is 123.45.67.1/30 for this link , and that gets 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 = (hidden)
EndPoint = 134.56.78.5:443
AllowedIPs =  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…

but I don’t know for sure… it seems to be a regression somewhere as I don’t
recall to have that problem before… I had to add this accept rule last
week, suddenly, as some peers could connect, but not transfer packets any
more.

Now I understand that wg finds it’s IP by following the shortest path, 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 <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
> 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
>
​

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