WireGuard roaming behind a load balancer

WireGuard roaming behind a load balancer

[pdub]

[-- Attachment #1.1: Type: text/plain, Size: 888 bytes --]

Greetings,

WireGuard is a really cool project! Thanks!

With WireGuard's native roaming support, I have a question about just how
stateful/stateless the roaming is. Here's a hypothetical situation:

Let's say WireGuard is being used to tunnel into a location and is served
behind a load balancer for high availability. If both nodes have identical
WireGuard config files at the start of WireGuard (and, for simplicity,
let's assume the configurations don't change). If one node dies, the load
balancer will automatically start sending packets to the standby node
running WireGuard (perhaps existing on the same subnet as the other node,
but with a different IP).

In a sense, the server-side "peer" has just roamed from machine to another,
but the public/Internet IP address didn't change (because that is assigned
to the load balancer itself). Will this work with WireGuard today?

TIA

[-- Attachment #1.2: Type: text/html, Size: 1079 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

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

Re: WireGuard roaming behind a load balancer

[John Huttley]

If you are using an F5 LTM load balancer,

Set a keepalive timeout  on  wireguard.
Assign a UDP profile with a timeout greater than the wireguard keepalive
Assign the Profile to the UDP VIP
--John



On 16/01/2019 4:45 AM, pdub wrote:
> Greetings,
> 
> WireGuard is a really cool project! Thanks!
> 
> With WireGuard's native roaming support, I have a question about just
> how stateful/stateless the roaming is. Here's a hypothetical situation:
> 
> Let's say WireGuard is being used to tunnel into a location and is
> served behind a load balancer for high availability. If both nodes have
> identical WireGuard config files at the start of WireGuard (and, for
> simplicity, let's assume the configurations don't change). If one node
> dies, the load balancer will automatically start sending packets to the
> standby node running WireGuard (perhaps existing on the same subnet as
> the other node, but with a different IP).
> 
> In a sense, the server-side "peer" has just roamed from machine to
> another, but the public/Internet IP address didn't change (because that
> is assigned to the load balancer itself). Will this work with WireGuard
> today?
> 
> TIA
> 
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
> 

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

Re: WireGuard roaming behind a load balancer

[Ivan Labáth]

Hi,

Wireguard isn't completely stateless. It has connections and state,
even though it is comparably small and transient.

Wireguard roaming supports changing IPs. An authenticated
packet updates the ip and all works well. Changing hosts requires
a rekey (to re-establish transient keys), and that won't be
automatically triggered by unauthenticated gibberish, so plain
switching won't work immediately.

If you don't mind a relatively short outage when switching,
it should work fine.


In your setup, where H,A,B are wg nodes, and
  (H)A - B
is switched to
  (A)H - B

B->HA traffic will be lost (considered junk) until either

 - B's timer expires and a B->H rekey is issued (maybe 10s of seconds?)
 - H->B traffic and/or timer initiates a H->B rekey

If HA can initate traffic to B, you may be able to rig a rekey soon,
with a <1s outage, or even lossless in some circumstances, but you are
going against the design of a host-to-host "stateless" vpn.

Real hot-standby HA VPNs with transparent lossless switching
on the HA side usually share their ephemeral keys.

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

Re: WireGuard roaming behind a load balancer

[Samuel Holland]

On 01/16/19 18:21, Ivan Labáth wrote:
> In your setup, where H,A,B are wg nodes, and
>   (H)A - B
> is switched to
>   (A)H - B

I assume here A and H are the active/hot-spare pair, and B is the remote node.

> B->HA traffic will be lost (considered junk) until either
> 
>  - B's timer expires and a B->H rekey is issued (maybe 10s of seconds?)

To be precise, this timer is 120 seconds from the last successful handshake.

>  - H->B traffic and/or timer initiates a H->B rekey
> 
> If HA can initate traffic to B, you may be able to rig a rekey soon,
> with a <1s outage, or even lossless in some circumstances, but you are
> going against the design of a host-to-host "stateless" vpn.

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.

So you need some way to stream endpoint updates between A and H. I'm not sure if
WireGuard's netlink has a way to push endpoint changes (that would be nice), but
you could at least poll netlink on the active host, and push netlink on the standby.

You could also extend the netlink interface with a way for userspace to request
a handshake on all peers. Then you could leave the interface up, and wouldn't
need any persistent keepalives.

> Real hot-standby HA VPNs with transparent lossless switching
> on the HA side usually share their ephemeral keys.

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.

Plus you *still* need the updated endpoint information to send packets from H to
B before B sends anything to AH, even if the session key is still valid. So I
highly recommend against attempting to extract the ephemeral keys from the kernel.

> Regards,
> Ivan

Cheers,
Samuel
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WireGuard roaming behind a load balancer

[Ivan Labáth]

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