WireGuard roaming behind a load balancer

Ivan Labáth labawi-wg at matrix-dream.net
Thu Jan 17 12:54:33 CET 2019

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.


More information about the WireGuard mailing list