Source IP for multihomed peer

Source IP for multihomed peer

[Svenne Krap]

Hi,

I have it a problem, that seems like the following is happening.


BoxA has multiple ip-addresses with different internet providers (i.e. 
multihomed)

BoxB is a normal single-homed dynamic peer (i.e. no fixed address), as 
is BoxC.

BoxB  and boxC both have hardcoded address1 ('boxA1')  as its peer


What seems to happen is:

1) BoxB writes sends to BoxA1  (address 1)

2) BoxA responds with BoxA2  (address 2)

3) BoxB disregards the traffic.


BoxC contacts boxA on BoxA1 and due to routing (due to BoxC's network) 
it gets replies with the right address ('boxA1'), and everything works 
as expected.



My question is twofold:

1) Does the above seem like a likely chain of events?

2) Is there any way to force the source ip of the connection from boxA 
to always use address boxA1 ?

 From the documentation Listenport only seems like the portnumber and 
there seems to be no way to set the source ip.


Regards


Svenne

Re: Source IP for multihomed peer

[Benda Xu]

Hi Svenne,

We have met exactly the same problem.

Svenne Krap <svenne@kracon.dk> writes:

> [...]
>
> My question is twofold:
>
> 1) Does the above seem like a likely chain of events?
>
> 2) Is there any way to force the source ip of the connection from boxA
> to always use address boxA1 ?
>
> From the documentation Listenport only seems like the portnumber and
> there seems to be no way to set the source ip.

It has been discussed on the list several times.  But Jason seems not
convinced of the necessity of address binding.

  https://lists.zx2c4.com/pipermail/wireguard/2017-May/001280.html
  https://lists.zx2c4.com/pipermail/wireguard/2019-March/003938.html
  https://lists.zx2c4.com/pipermail/wireguard/2018-June/003013.html
  https://lists.zx2c4.com/pipermail/wireguard/2017-November/002017.html

Rulin and I tried to implement an address binding feature at,

  https://github.com/FireflyTang/linux-wireguard-bind

It was verified to work with Linux-5.7.

Yours,
Benda

Re: Source IP for multihomed peer

[Chriztoffer Hansen]

On Fri, 15 Oct 2021 at 04:39, Benda Xu <heroxbd@gentoo.org> wrote:
> > From the documentation Listenport only seems like the portnumber and
> > there seems to be no way to set the source ip.
>
> It has been discussed on the list several times.  But Jason seems not
> convinced of the necessity of address binding.
>
>   https://lists.zx2c4.com/pipermail/wireguard/2017-May/001280.html
>   https://lists.zx2c4.com/pipermail/wireguard/2019-March/003938.html
>   https://lists.zx2c4.com/pipermail/wireguard/2018-June/003013.html
>   https://lists.zx2c4.com/pipermail/wireguard/2017-November/002017.html
>
> Rulin and I tried to implement an address binding feature at,
>
>   https://github.com/FireflyTang/linux-wireguard-bind
>
> It was verified to work with Linux-5.7.

In the prototyping patch you developed for WireGuard, did you consider
prototyping being able to bind to an interface, instead of explicitly
specifying an IP address? An example case for being able to bind to an
interface could be a multi-wan connected firewall/router with dynamic
public IP addresses offered by the upstream provider no at least one
connection. E.g. Primary fiber line, backup DSL line.

/Chriztoffer

Re: Source IP for multihomed peer

[Benda Xu]

Hi Chriztoffer,

Chriztoffer Hansen <ch@ntrv.dk> writes:

> In the prototyping patch you developed for WireGuard, did you consider
> prototyping being able to bind to an interface, instead of explicitly
> specifying an IP address? 

No we did not.  We wanted to keep the patch as small as possible.  

That said, we could manage it by an auxiliary script.

> An example case for being able to bind to an interface could be a
> multi-wan connected firewall/router with dynamic public IP addresses
> offered by the upstream provider no at least one
> connection. E.g. Primary fiber line, backup DSL line.

Yeah, that's a common use case.

Cheers,
Benda

Re: Source IP for multihomed peer

[Svenne Krap]

On 15.10.2021 04.39, Benda Xu wrote:
> We have met exactly the same problem.

Have you tried SNAT from iptables? Is that a viable work-around?


Svenne

Re: Source IP for multihomed peer

[Toke Høiland-Jørgensen]

> 2) Is there any way to force the source ip of the connection from boxA 
> to always use address boxA1 ?

In theory this should be possible to enforce via policy routing. Just
tried this on a simple veth setup:

# ip a add 10.11.1.1/24 dev veth0
# ip a add 10.11.2.1/24 dev veth0
# ping 10.11.1.2 -c 1
12:09:22.385888 IP 10.11.1.1 > 10.11.1.2: ICMP echo request, id 15, seq 1, length 64
12:09:22.385903 IP 10.11.1.2 > 10.11.1.1: ICMP echo reply, id 15, seq 1, length 64

# ip r add 10.11.1.2 src 10.11.2.1 dev veth0
# ping 10.11.1.2 -c 1
12:09:53.251386 IP 10.11.2.1 > 10.11.1.2: ICMP echo request, id 16, seq 1, length 64
12:09:53.251403 IP 10.11.1.2 > 10.11.2.1: ICMP echo reply, id 16, seq 1, length 64

I think this ought to work for wireguard's source selection as well. If
you don't have a particular destination, you should be able to do
something similar based on sports with ip-rule using the wireguard
source port:

# ip rule add sport 1234 lookup 100
# ip route add table 100 default via 1.2.3.4 src 3.4.5.6

That last bit I didn't test, though...

-Toke

Re: Source IP for multihomed peer

[Chriztoffer Hansen]

On Fri, 15 Oct 2021 at 12:14, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> > 2) Is there any way to force the source ip of the connection from boxA
> > to always use address boxA1 ?
>
> In theory this should be possible to enforce via policy routing. Just
> tried this on a simple veth setup:
>
> # ip a add 10.11.1.1/24 dev veth0
> # ip a add 10.11.2.1/24 dev veth0
> # ping 10.11.1.2 -c 1
> 12:09:22.385888 IP 10.11.1.1 > 10.11.1.2: ICMP echo request, id 15, seq 1, length 64
> 12:09:22.385903 IP 10.11.1.2 > 10.11.1.1: ICMP echo reply, id 15, seq 1, length 64
>
> # ip r add 10.11.1.2 src 10.11.2.1 dev veth0
> # ping 10.11.1.2 -c 1
> 12:09:53.251386 IP 10.11.2.1 > 10.11.1.2: ICMP echo request, id 16, seq 1, length 64
> 12:09:53.251403 IP 10.11.1.2 > 10.11.2.1: ICMP echo reply, id 16, seq 1, length 64
>
> I think this ought to work for wireguard's source selection as well. If
> you don't have a particular destination, you should be able to do
> something similar based on sports with ip-rule using the wireguard
> source port:
>
> # ip rule add sport 1234 lookup 100
> # ip route add table 100 default via 1.2.3.4 src 3.4.5.6
>
> That last bit I didn't test, though...

Will have to test this later.

If this works. This suggestion would be a great enhancement to wireguard-tools?