All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan Labáth" <labawi-wg@matrix-dream.net>
To: Samuel Holland <samuel@sholland.org>
Cc: wireguard@lists.zx2c4.com
Subject: Re: WireGuard roaming behind a load balancer
Date: Thu, 17 Jan 2019 11:54:33 +0000	[thread overview]
Message-ID: <20190117115433.GA31370@matrix-dream.net> (raw)
In-Reply-To: <d66b2b95-ee36-ed16-b8fa-94edfe092478@sholland.org>

On Wed, Jan 16, 2019 at 06:40:05PM -0600, Samuel Holland wrote:
> H can immediately send handshakes to all peers when it is brought up (and will
> do so today if they have persistent keepalives set). But you need more than HA
> being able to initiate traffic to B. B could have roamed to a new IP while it
> was communicating with A. Then A would know about the new IP (because it
> received an authenticated packet from there), but H would not.
> 
If B can roam like that, I wouldn't really say HA can initiate traffic.
I was thinking more of big site to smaller site high availability VPNs
with static IPs and one side seamless failover capability. Not the usual
case, just if you rally wanted to.

Yes, you should probabaly use multiple peers/tunnels and/or different
failover protocols if you can't take the 2min downtime.

Maybe it would be useful, if wireguard could reinitiate a handshake
if it hasn't received packets in a configurable amount of time?
Currently it can only be set to periodically send packets, which doesn't
help if only one side can initate and the other loses state, so it will
wait till the generic timeout.

> Sharing ephemeral keys would avoid the need for a new handshake at failover, but
> that is very little benefit, since handshakes happen every couple of minutes
> anyway. More importantly, sharing keys comes with the security risk of sending
> your most sensitive data over the network. Anyone with those keys can decrypt
> VPN traffic in real time.

If the hosts are trusted to decrypt the traffic anyway, it shouldn't
be that big a deal, if done right. But yes, beware, it can can create
serious security issues.

Ivan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      reply	other threads:[~2019-01-17 11:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 16:45 WireGuard roaming behind a load balancer pdub
2019-01-16 18:44 ` John Huttley
2019-01-17  0:21 ` Ivan Labáth
2019-01-17  0:40   ` Samuel Holland
2019-01-17 11:54     ` Ivan Labáth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190117115433.GA31370@matrix-dream.net \
    --to=labawi-wg@matrix-dream.net \
    --cc=samuel@sholland.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.