* Multihoming?
@ 2020-03-31 7:22 Alex Besogonov
2020-04-05 0:47 ` Multihoming? Justin Kilpatrick
2020-04-05 7:38 ` Multihoming? Jason A. Donenfeld
0 siblings, 2 replies; 3+ messages in thread
From: Alex Besogonov @ 2020-03-31 7:22 UTC (permalink / raw)
To: wireguard
Hi, list!
I’ve read the source code Wireguard implementations and it appears that true multihoming seems to be impossible with the current protocol. By true multihoming I mean possibility of using multiple connections at the same time, preferably with configurable rates for them on both sides.
A typical use-case would be a small office using two independent ISPs to connect to a Wireguard server, so that failure of one of them would not cause service interruption. Or a mobile user with an LTE and WiFi connections used simultaneously.
Any ideas on how this could be implemented?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Multihoming?
2020-03-31 7:22 Multihoming? Alex Besogonov
@ 2020-04-05 0:47 ` Justin Kilpatrick
2020-04-05 7:38 ` Multihoming? Jason A. Donenfeld
1 sibling, 0 replies; 3+ messages in thread
From: Justin Kilpatrick @ 2020-04-05 0:47 UTC (permalink / raw)
To: wireguard
Using multiple connections at once is fraught with problems in the first place (see the complexities of teaming and bonding nics) but you can do a simple failover system using Babeld + Wireguard
Althea uses this for failover. In earlier versions of Wireguard it was quite bad (60 second switch times) but more recently handshake re-negotiation is triggered on the fly.
The whole process for Babel to detect the failure, reroute to some other Babeld node advertising the same IP and then for that Wireguard server and the client to renegotiate and get traffic flowing takes only a few seconds (about 5 in my experience).
--
Justin Kilpatrick
justin@althea.net
On Tue, Mar 31, 2020, at 3:22 AM, Alex Besogonov wrote:
> Hi, list!
>
> I’ve read the source code Wireguard implementations and it appears that
> true multihoming seems to be impossible with the current protocol. By
> true multihoming I mean possibility of using multiple connections at
> the same time, preferably with configurable rates for them on both
> sides.
>
> A typical use-case would be a small office using two independent ISPs
> to connect to a Wireguard server, so that failure of one of them would
> not cause service interruption. Or a mobile user with an LTE and WiFi
> connections used simultaneously.
>
> Any ideas on how this could be implemented?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Multihoming?
2020-03-31 7:22 Multihoming? Alex Besogonov
2020-04-05 0:47 ` Multihoming? Justin Kilpatrick
@ 2020-04-05 7:38 ` Jason A. Donenfeld
1 sibling, 0 replies; 3+ messages in thread
From: Jason A. Donenfeld @ 2020-04-05 7:38 UTC (permalink / raw)
To: Alex Besogonov; +Cc: WireGuard mailing list
On Sat, Apr 4, 2020 at 4:45 PM Alex Besogonov <alex.besogonov@gmail.com> wrote:
> By true multihoming I mean possibility of using multiple connections at the same time, preferably with configurable rates for them on both sides.
Both connections at the same time, configurable rates... seems a bit
out of scope for an encrypted tunnel, doesn't it?
Rather, set up two tunnels, and then bond them or run some other
aggregation protocol over it. Several years ago I was aggregating
several different internet connections using MPTCP over various pipes.
Things worked extraordinarily well.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-04-05 7:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-31 7:22 Multihoming? Alex Besogonov
2020-04-05 0:47 ` Multihoming? Justin Kilpatrick
2020-04-05 7:38 ` Multihoming? Jason A. Donenfeld
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).