Development discussion of WireGuard
 help / color / mirror / Atom feed
* 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).