Development discussion of WireGuard
 help / color / mirror / Atom feed
* best way for redundancy?
@ 2021-02-25 21:17 Joachim Lindenberg
  2021-03-02 17:10 ` Nicolai
  0 siblings, 1 reply; 3+ messages in thread
From: Joachim Lindenberg @ 2021-02-25 21:17 UTC (permalink / raw)
  To: 'WireGuard mailing list'

Hello
I do have a wireguard VPN that connects multiple sites. Unfortunately some routers are not available all the time, causing network disruption. I´d like to improve connectivity via redundancy, i.e. add multiple routers that connect the networks.
What are the options to do that using wireguard? Can I have multiple peers with different keys and endpoint but same Allowed IPs? Will wireguard select the one available?
Any suggestions?
Thanks, Joachim



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: best way for redundancy?
  2021-02-25 21:17 best way for redundancy? Joachim Lindenberg
@ 2021-03-02 17:10 ` Nicolai
  2021-03-04  8:58   ` AW: " Joachim Lindenberg
  0 siblings, 1 reply; 3+ messages in thread
From: Nicolai @ 2021-03-02 17:10 UTC (permalink / raw)
  To: wireguard

On Thu, Feb 25, 2021 at 10:17:06PM +0100, Joachim Lindenberg wrote:

> I do have a wireguard VPN that connects multiple sites. Unfortunately
> some routers are not available all the time, causing network disruption.
> I'd like to improve connectivity via redundancy, i.e. add multiple
> routers that connect the networks.

> What are the options to do that using wireguard? Can I have multiple
> peers with different keys and endpoint but same Allowed IPs? Will
> wireguard select the one available?

In the future I want a similar setup: multiple routers for each network
each seamlessly handling WireGuard when necessary.  I haven't put any
effort into this yet, but my general plan is to use CARP on OpenBSD,
with WireGuard sharing keys.  (I know you want distinct keys, so I
waited to respond until others had a chance.)  Anyway the routers in
City1 would share City1Keys, routers in City2 would share City2Keys,
etc.  When City1Router1 is unavailable, City1Router2 would grab the IP
address and be able to immediately speak WireGuard to the other
locations without anyone noticing.

https://www.openbsd.org/faq/pf/carp.html

Nicolai

^ permalink raw reply	[flat|nested] 3+ messages in thread

* AW: best way for redundancy?
  2021-03-02 17:10 ` Nicolai
@ 2021-03-04  8:58   ` Joachim Lindenberg
  0 siblings, 0 replies; 3+ messages in thread
From: Joachim Lindenberg @ 2021-03-04  8:58 UTC (permalink / raw)
  To: wireguard

I probably should share some more details about my use case and also why I am hesitating to use OpenBSD/OpnSense etc.
All my VPN-routers are actually virtual machines. One is a virtual private server from a hoster that provides an external static IPv4 address, the others are Ubuntu VMs running on Hyper-V 2019. When I check support of OpenBSD/OpnSense on Hyper-V it looks like this is not really granted, basically works, but... and CARP apparently requires special configuration and cooperation of network drivers. And then I haven´t found good documentation on how to configure CARP with wireguard. 

Thus I tried something else... Until this week, the router of one network was on a mobile machine, which occasionally was really on the road - and the connectivity was of course broken then. There is another host available in the same network that can host a VM, but that host is not running 7*24 for power and noise reasons. That actually suggested a fail over scenario to me. What I configured right now is the following: I "partitioned" that network logically into two groups of VPN-clients. One group is the host and all VMs on the power-saving-host, the other group is the rest. Via DHCP or static routes, each group now uses different routers (part of the respective group) for their respective wireguard tunnel to the other networks. On the other side of the tunnel, network ranges in AllowedIPs are used to address the respective peer (I didn´t dare to have these overlap so far).

That is not really a general high-availability scenario, as essentially I optimized for the expected outages. I am still wondering whether wireguard can support a more general approach without the complexity introduced by CARP. My gut feeling is that the roaming capabilities of wireguard should actually support that very well.

Thanks, Joachim



-----Ursprüngliche Nachricht-----
Von: WireGuard <wireguard-bounces@lists.zx2c4.com> Im Auftrag von Nicolai
Gesendet: Tuesday, 2 March 2021 18:10
An: wireguard@lists.zx2c4.com
Betreff: Re: best way for redundancy?

On Thu, Feb 25, 2021 at 10:17:06PM +0100, Joachim Lindenberg wrote:

> I do have a wireguard VPN that connects multiple sites. Unfortunately 
> some routers are not available all the time, causing network disruption.
> I'd like to improve connectivity via redundancy, i.e. add multiple 
> routers that connect the networks.

> What are the options to do that using wireguard? Can I have multiple 
> peers with different keys and endpoint but same Allowed IPs? Will 
> wireguard select the one available?

In the future I want a similar setup: multiple routers for each network each seamlessly handling WireGuard when necessary.  I haven't put any effort into this yet, but my general plan is to use CARP on OpenBSD, with WireGuard sharing keys.  (I know you want distinct keys, so I waited to respond until others had a chance.)  Anyway the routers in
City1 would share City1Keys, routers in City2 would share City2Keys, etc.  When City1Router1 is unavailable, City1Router2 would grab the IP address and be able to immediately speak WireGuard to the other locations without anyone noticing.

https://www.openbsd.org/faq/pf/carp.html

Nicolai


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-03-04  8:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-25 21:17 best way for redundancy? Joachim Lindenberg
2021-03-02 17:10 ` Nicolai
2021-03-04  8:58   ` AW: " Joachim Lindenberg

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).