WG load balancing?

WG load balancing?

[Matthias Urlichs]

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

Hello list,

Assume a branch office with two uplinks to the Internet that wants to
use WG to talk to the main office, using both of these uplinks in
parallel (assuming they're both up) for better uplink speed (and for
redundancy if they aren't). Now the obvious idea is to create two WG
interfaces on each side, and add a couple of firewall rules to make sure
that packets fwmarked 1 go out on the first uplink, and so on.

That's the easy part. The hard part is how to teach the kernel to load
balance its default route between the WG interfaces. I tried to use a
libteam or bonding interface to tie them together, but apparently WG
isn't Ethernet, so that doesn't work.

I thought about using a GRE tunnel, but tunnels have fixed endpoint
addresses – somehow I don't think it'd be a good idea to create two
wireguard interfaces with the same IP address … and I don't really want
to do heavy-handed address mangling on every packet. Losing all
connectivity whenever I happen to flush my firewall tables doesn't
appeal to me.

Ideally I would like the kernel's wireguard interfaces to be compatible
with teaming … any takers?

-- 
-- Matthias Urlichs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: WG load balancing?

[Tim Weippert]

Hi Matthias, 


On Thu, May 10, 2018 at 11:21:44AM +0200, Matthias Urlichs wrote:
> Hello list,
> 
> Assume a branch office with two uplinks to the Internet that wants to
> use WG to talk to the main office, using both of these uplinks in
> parallel (assuming they're both up) for better uplink speed (and for
> redundancy if they aren't). Now the obvious idea is to create two WG
> interfaces on each side, and add a couple of firewall rules to make sure
> that packets fwmarked 1 go out on the first uplink, and so on.
> 
> That's the easy part. The hard part is how to teach the kernel to load
> balance its default route between the WG interfaces. I tried to use a
> libteam or bonding interface to tie them together, but apparently WG
> isn't Ethernet, so that doesn't work.
> 
> I thought about using a GRE tunnel, but tunnels have fixed endpoint
> addresses – somehow I don't think it'd be a good idea to create two
> wireguard interfaces with the same IP address … and I don't really want
> to do heavy-handed address mangling on every packet. Losing all
> connectivity whenever I happen to flush my firewall tables doesn't
> appeal to me.

Maybe you can use some kind of dynamic routing approach here. Use FRR,
Quagga or Bird with e.g. OSPF and ECMP ( Equal Cost Multipath) to utilize
both links. (practically you can also have two default routes with the
same metric and this should do a round robin fashioned loadbalancing)

Additional you get a failover functionality with the dynamic routing, as
one path is lost, it moves to the other one. And you don't need to mark
packets on the firewall level.

> Ideally I would like the kernel's wireguard interfaces to be compatible
> with teaming … any takers?

Can't help with teaming here.

HTH, 
tim

-- 
Tim Weippert
http://weiti.org - weiti@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

Re: WG load balancing?

[Toke Høiland-Jørgensen]

Tim Weippert <weiti@weiti.org> writes:

> Hi Matthias,=20
>
>
> On Thu, May 10, 2018 at 11:21:44AM +0200, Matthias Urlichs wrote:
>> Hello list,
>>=20
>> Assume a branch office with two uplinks to the Internet that wants to
>> use WG to talk to the main office, using both of these uplinks in
>> parallel (assuming they're both up) for better uplink speed (and for
>> redundancy if they aren't). Now the obvious idea is to create two WG
>> interfaces on each side, and add a couple of firewall rules to make sure
>> that packets fwmarked 1 go out on the first uplink, and so on.
>>=20
>> That's the easy part. The hard part is how to teach the kernel to load
>> balance its default route between the WG interfaces. I tried to use a
>> libteam or bonding interface to tie them together, but apparently WG
>> isn't Ethernet, so that doesn't work.
>>=20
>> I thought about using a GRE tunnel, but tunnels have fixed endpoint
>> addresses =E2=80=93 somehow I don't think it'd be a good idea to create =
two
>> wireguard interfaces with the same IP address =E2=80=A6 and I don't real=
ly want
>> to do heavy-handed address mangling on every packet. Losing all
>> connectivity whenever I happen to flush my firewall tables doesn't
>> appeal to me.
>
> Maybe you can use some kind of dynamic routing approach here. Use FRR,
> Quagga or Bird with e.g. OSPF and ECMP ( Equal Cost Multipath) to utilize
> both links. (practically you can also have two default routes with the
> same metric and this should do a round robin fashioned loadbalancing)

You can add ECMP routes with 'ip route' via the 'nexthop' parameter. See
'man ip-route'.

-Toke

Re: WG load balancing?

[Toke Høiland-Jørgensen]

Matthias Urlichs <matthias@urlichs.de> writes:

> Hello list,
>
> Assume a branch office with two uplinks to the Internet that wants to
> use WG to talk to the main office, using both of these uplinks in
> parallel (assuming they're both up) for better uplink speed (and for
> redundancy if they aren't). Now the obvious idea is to create two WG
> interfaces on each side, and add a couple of firewall rules to make sure
> that packets fwmarked 1 go out on the first uplink, and so on.
>
> That's the easy part. The hard part is how to teach the kernel to load
> balance its default route between the WG interfaces. I tried to use a
> libteam or bonding interface to tie them together, but apparently WG
> isn't Ethernet, so that doesn't work.
>
> I thought about using a GRE tunnel, but tunnels have fixed endpoint
> addresses =E2=80=93 somehow I don't think it'd be a good idea to create t=
wo
> wireguard interfaces with the same IP address =E2=80=A6 and I don't reall=
y want
> to do heavy-handed address mangling on every packet. Losing all
> connectivity whenever I happen to flush my firewall tables doesn't
> appeal to me.

You could create GRE tunnels on the internal IP addresses of the
wireguard interface? Or use the kernel's ECMP routing as suggested by
Tim :)

-Toke

Re: WG load balancing?

[Tim Sedlmeyer]

On Thu, May 10, 2018 at 5:22 AM Matthias Urlichs <matthias@urlichs.de>
wrote:

> Hello list,

> Assume a branch office with two uplinks to the Internet that wants to
> use WG to talk to the main office, using both of these uplinks in
> parallel (assuming they're both up) for better uplink speed (and for
> redundancy if they aren't). Now the obvious idea is to create two WG
> interfaces on each side, and add a couple of firewall rules to make sure
> that packets fwmarked 1 go out on the first uplink, and so on.

> That's the easy part. The hard part is how to teach the kernel to load
> balance its default route between the WG interfaces. I tried to use a
> libteam or bonding interface to tie them together, but apparently WG
> isn't Ethernet, so that doesn't work.

> I thought about using a GRE tunnel, but tunnels have fixed endpoint
> addresses =E2=80=93 somehow I don't think it'd be a good idea to create t=
wo
> wireguard interfaces with the same IP address =E2=80=A6 and I don't reall=
y want
> to do heavy-handed address mangling on every packet. Losing all
> connectivity whenever I happen to flush my firewall tables doesn't
> appeal to me.

> Ideally I would like the kernel's wireguard interfaces to be compatible
> with teaming =E2=80=A6 any takers?

> --
> -- Matthias Urlichs


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

If you are in kernel >=3D4.4 you can use hash-based multipath routing. A ha=
sh
by default based upon source and destination address will be calculated and
flows matching the hash will be assigned to a particular path. If need to
better balance traffic you can configure the kernel to use source and
destination ports as part of the hash also. The kernel will assign hashes
to the links in a manner that balances the traffic across them. You can
also assign weights to each path and the kernel will assign traffic
according to the ratio of the weights.

For example to equally balance the traffic between 2 wireguard interfaces
the command would be:

ip route add default nexthop dev wg0 weight 1 nexthop dev wg1 weight 1

If you wanted to send 5 times as much traffic over the 2nd link:

ip route add default nexthop dev wg0 weight 1 nexthop dev wg1 weight 5