[WireGuard] wg set - unexpected change of routes

[WireGuard] wg set - unexpected change of routes

[Ivan Labáth]

Hello,

I have noticed that adding a route (allowedips) to a peer
automatically removes any such route from other peers,
as has been explained in some email.

It seems to me as unexpected behaviour, as I wouldn't expect
the configuration of a peer to be (silently) affected when
changing the configuration of another peer.

I think repeating subnets in different peers is most probably
an error and in such circumstances the most useful action would
be to fail and report it as such.


Result of an attempt at something similar:

linux ~ # ip route add 172.16.0.0/12 via 127.0.0.1
linux ~ # ip route add 172.16.0.0/12 via 127.0.0.2
RTNETLINK answers: File exists

Regards,
Ivan Labáth

Re: [WireGuard] wg set - unexpected change of routes

[Bruno Wolff III]

On Tue, Aug 30, 2016 at 07:44:54 +0100,
  Ivan Labáth <labawi-wg@matrix-dream.net> wrote:
>
>I think repeating subnets in different peers is most probably
>an error and in such circumstances the most useful action would
>be to fail and report it as such.

Except in some cases it is convenient to use a large network for one peer 
and carve out a small subnet in another. Having to list a big subnet with 
a carve out as the sum of smaller networks can be a big pain.

Re: [WireGuard] wg set - unexpected change of routes

[Ivan Labáth]

On Tue, Aug 30, 2016 at 10:44:39AM -0500, Bruno Wolff III wrote:
> On Tue, Aug 30, 2016 at 07:44:54 +0100,
>   Ivan Labáth <labawi-wg@matrix-dream.net> wrote:
> >
> >I think repeating subnets in different peers is most probably
> >an error and in such circumstances the most useful action would
> >be to fail and report it as such.
> 
> Except in some cases it is convenient to use a large network for one peer 
> and carve out a small subnet in another. Having to list a big subnet with 
> a carve out as the sum of smaller networks can be a big pain.

By repeating subnets, I meant repeating ip/mask tuples.
It is something that wireguard already enforces, but it
does so by silently dropping all but the last occurence
of the ip+mask.


Currently it will even happily load the following configuration,
dropping the first occurence of the 10/24 subnet:

[Interface]
PrivateKey = mP3lDaGe7Ge/fo1k+TNnBlRVXiZKJSiWfwFrCdcaDGM=

[Peer]
PublicKey = iiLB93qP+YnDqxN4UixSpEWhvqWdZYmcs0fjKRShNmA=
AllowedIPs = 10.0.0.0/16

[Peer]
PublicKey = qAoLCCM/K3JWqaaSdOy2SmuzMTRwTaxyRR3g36tdzgY=
AllowedIPs = 10.0.0.0/16



The following is valid, correctly loaded, as should remain so
(I don't know whether it routes among peers)

[Interface]
PrivateKey = mP3lDaGe7Ge/fo1k+TNnBlRVXiZKJSiWfwFrCdcaDGM=

[Peer]
PublicKey = iiLB93qP+YnDqxN4UixSpEWhvqWdZYmcs0fjKRShNmA=
AllowedIPs = 10.0.0.0/16

[Peer]
PublicKey = qAoLCCM/K3JWqaaSdOy2SmuzMTRwTaxyRR3g36tdzgY=
AllowedIPs = 10.0.0.0/24


I am concerned about situations where one would issue commands
that reuse a route and would not know that a route was removed
from a peer. For example, with the last configuration:

wg set wg0 peer qAoLCCM/K3JWqaaSdOy2SmuzMTRwTaxyRR3g36tdzgY= allowed-ips 10.0.0.0/16
wg set wg0 peer qAoLCCM/K3JWqaaSdOy2SmuzMTRwTaxyRR3g36tdzgY= allowed-ips 10.0.0.0/24

One might think he restored the configuration, but the /16 route was
removed from the first peer.

Re: [WireGuard] wg set - unexpected change of routes

[Dave Taht]

I've only been using wireguard for 24 hours, and I like it a lot.

In my world, what I'd want is the ability to leverage source specific
routing, and to be able
to have nailed up dozens of routes to the same dozens of locations,
having a routing protocol layered on top to pick the best one (or, in
a tor-like way, pick a set of confusing ones), to ensure being able to
route around an outage somewhere.