* Source IP for multihomed peer
@ 2021-10-14 8:30 Svenne Krap
2021-10-15 2:39 ` Benda Xu
2021-10-15 10:14 ` Toke Høiland-Jørgensen
0 siblings, 2 replies; 7+ messages in thread
From: Svenne Krap @ 2021-10-14 8:30 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-14 8:30 Source IP for multihomed peer Svenne Krap
@ 2021-10-15 2:39 ` Benda Xu
2021-10-15 7:57 ` Chriztoffer Hansen
2021-10-15 8:54 ` Svenne Krap
2021-10-15 10:14 ` Toke Høiland-Jørgensen
1 sibling, 2 replies; 7+ messages in thread
From: Benda Xu @ 2021-10-15 2:39 UTC (permalink / raw)
To: Svenne Krap; +Cc: wireguard
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-15 2:39 ` Benda Xu
@ 2021-10-15 7:57 ` Chriztoffer Hansen
2021-10-15 8:25 ` Benda Xu
2021-10-15 8:54 ` Svenne Krap
1 sibling, 1 reply; 7+ messages in thread
From: Chriztoffer Hansen @ 2021-10-15 7:57 UTC (permalink / raw)
To: Benda Xu; +Cc: Svenne Krap, WireGuard List (wireguard@lists.zx2c4.com)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-15 7:57 ` Chriztoffer Hansen
@ 2021-10-15 8:25 ` Benda Xu
0 siblings, 0 replies; 7+ messages in thread
From: Benda Xu @ 2021-10-15 8:25 UTC (permalink / raw)
To: Chriztoffer Hansen; +Cc: wireguard
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-15 2:39 ` Benda Xu
2021-10-15 7:57 ` Chriztoffer Hansen
@ 2021-10-15 8:54 ` Svenne Krap
1 sibling, 0 replies; 7+ messages in thread
From: Svenne Krap @ 2021-10-15 8:54 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-14 8:30 Source IP for multihomed peer Svenne Krap
2021-10-15 2:39 ` Benda Xu
@ 2021-10-15 10:14 ` Toke Høiland-Jørgensen
2021-10-15 11:14 ` Chriztoffer Hansen
1 sibling, 1 reply; 7+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-10-15 10:14 UTC (permalink / raw)
To: Svenne Krap, wireguard
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Source IP for multihomed peer
2021-10-15 10:14 ` Toke Høiland-Jørgensen
@ 2021-10-15 11:14 ` Chriztoffer Hansen
0 siblings, 0 replies; 7+ messages in thread
From: Chriztoffer Hansen @ 2021-10-15 11:14 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Svenne Krap, WireGuard List (wireguard@lists.zx2c4.com)
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-10-15 11:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-14 8:30 Source IP for multihomed peer Svenne Krap
2021-10-15 2:39 ` Benda Xu
2021-10-15 7:57 ` Chriztoffer Hansen
2021-10-15 8:25 ` Benda Xu
2021-10-15 8:54 ` Svenne Krap
2021-10-15 10:14 ` Toke Høiland-Jørgensen
2021-10-15 11:14 ` Chriztoffer Hansen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).