Allowed IPs Toggling

Allowed IPs Toggling

[Gianluca Gabrielli]

Hi folks,

I was setting two peers on the server, but every time I re-add one of these=
 two the other one is shown with (none) on "allowed ips" field. Of course t=
hat blocks communications with that peer.
If I try to re-add it, then the other peer loses its configuration, same pr=
oblem.=20

I also uploaded a screenshot to show what happen: http://b1.ge.tt/thumbnail=
/9mHe41p2/0/user-FmSzCRxxFYeJWFrs22ANXjgqdUW3IX7GvUIDb-/0x675.png

I'm pretty sure that is not a bug, but my fault about some misconfiguration=
.... anyone knows what I'm doing wrong??

Cheers,
Gianluca

Re: Allowed IPs Toggling

[Samuel Holland]

Hello,

On 03/15/18 10:31, Gianluca Gabrielli wrote:
> I was setting two peers on the server, but every time I re-add one of these 
> two the other one is shown with (none) on "allowed ips" field. Of course that
> blocks communications with that peer. If I try to re-add it, then the other
> peer loses its configuration, same problem.

Allowed IPs is like a routing table; you can't have two routes for the same set
of IPs, or WireGuard doesn't know which peer to send the traffic to. You want to
have non-overlapping Allowed IP ranges. This usually means that the range of
Allowed IPs is smaller than the host's subnet. For example:

Host A:
IP configuration for WireGuard interface: 192.168.123.1/24
Allowed IPs for Host B: 192.168.123.2/32

Host B:
IP configuration for WireGuard interface: 192.168.123.2/24
Allowed IPs for Host A: 192.168.123.1/32

The IP configuration tells the kernel which IP ranges are accessible via the
WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of those IPs
is associated with each peer.

> Cheers,
> Gianluca

Cheers,
Samuel

Re: Allowed IPs Toggling

[Steve Gilberd]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

> Allowed IPs is like a routing table; you can't have two routes for the
same set of IPs

If this is the case, then wireguard does not have proper routing support.

Normally, routing tables allow both multiple and overlapping routes
present. When making routing decisions, the most-specific route is chosen
(e.g. a /29 is higher priority than a /24 which overlaps with it). If there
are two identical routes of the same size, then the one with the lowest
routing metric is used.

I can understand not allowing identical routes of the same size, as
wireguard doesn't really have a concept of metric (although it could be
useful for backup links). However, it really should allow overlapping
routes of different sizes. There's no ambiguity with routing decisions, and
it's a standard feature that I would normally expect any IP routing stack
to have.

Cheers,
Steve

On Fri, 16 Mar 2018, 04:57 Samuel Holland, <samuel@sholland.org> wrote:

> Hello,
>
> On 03/15/18 10:31, Gianluca Gabrielli wrote:
> > I was setting two peers on the server, but every time I re-add one of
> these
> > two the other one is shown with (none) on "allowed ips" field. Of course
> that
> > blocks communications with that peer. If I try to re-add it, then the
> other
> > peer loses its configuration, same problem.
>
> Allowed IPs is like a routing table; you can't have two routes for the
> same set
> of IPs, or WireGuard doesn't know which peer to send the traffic to. You
> want to
> have non-overlapping Allowed IP ranges. This usually means that the range
> of
> Allowed IPs is smaller than the host's subnet. For example:
>
> Host A:
> IP configuration for WireGuard interface: 192.168.123.1/24
> Allowed IPs for Host B: 192.168.123.2/32
>
> Host B:
> IP configuration for WireGuard interface: 192.168.123.2/24
> Allowed IPs for Host A: 192.168.123.1/32
>
> The IP configuration tells the kernel which IP ranges are accessible via
> the
> WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of
> those IPs
> is associated with each peer.
>
> > Cheers,
> > Gianluca
>
> Cheers,
> Samuel
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019 The Terrace, Wellington 6143, NZ*

[-- Attachment #2: Type: text/html, Size: 3722 bytes --]

Re: Allowed IPs Toggling

[Samuel Holland]

Hello,

On 03/15/18 13:39, Steve Gilberd wrote:
>> Allowed IPs is like a routing table; you can't have two routes for the same
> set of IPs
> 
> If this is the case, then wireguard does not have proper routing support.
> 
> Normally, routing tables allow both multiple and overlapping routes present.
> When making routing decisions, the most-specific route is chosen (e.g. a /29 is
> higher priority than a /24 which overlaps with it). If there are two identical
> routes of the same size, then the one with the lowest routing metric is used.
> 
> I can understand not allowing identical routes of the same size, as wireguard
> doesn't really have a concept of metric (although it could be useful for backup
> links). However, it really should allow overlapping routes of different sizes.
> There's no ambiguity with routing decisions, and it's a standard feature that I
> would normally expect any IP routing stack to have.

WireGuard *does* support overlapping ranges of AllowedIPs on different peers. It
doesn't support having *identical* ranges of AllowedIPs on different peers,
which was the situation here. (You're correct, there's no concept of a metric.)

> Cheers,
> Steve

Cheers,
Samuel

Re: Allowed IPs Toggling

[Steve Gilberd]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

 > WireGuard *does* support overlapping ranges of AllowedIPs on different
peers. It
> doesn't support having *identical* ranges of AllowedIPs on different
peers,
> which was the situation here. (You're correct, there's no concept of a
metric.)

Oh good - looks like I just misunderstood your ordinal email then; I
thought you were saying that any situation with multiple routes to a single
IP was unsupported. Thanks for clarifying :-).

Cheers,
Steve

On Fri, 16 Mar 2018, 07:51 Samuel Holland, <samuel@sholland.org> wrote:

> Hello,
>
> On 03/15/18 13:39, Steve Gilberd wrote:
> >> Allowed IPs is like a routing table; you can't have two routes for the
> same
> > set of IPs
> >
> > If this is the case, then wireguard does not have proper routing support.
> >
> > Normally, routing tables allow both multiple and overlapping routes
> present.
> > When making routing decisions, the most-specific route is chosen (e.g. a
> /29 is
> > higher priority than a /24 which overlaps with it). If there are two
> identical
> > routes of the same size, then the one with the lowest routing metric is
> used.
> >
> > I can understand not allowing identical routes of the same size, as
> wireguard
> > doesn't really have a concept of metric (although it could be useful for
> backup
> > links). However, it really should allow overlapping routes of different
> sizes.
> > There's no ambiguity with routing decisions, and it's a standard feature
> that I
> > would normally expect any IP routing stack to have.
>
> WireGuard *does* support overlapping ranges of AllowedIPs on different
> peers. It
> doesn't support having *identical* ranges of AllowedIPs on different peers,
> which was the situation here. (You're correct, there's no concept of a
> metric.)
>
> > Cheers,
> > Steve
>
> Cheers,
> Samuel
>
-- 

Cheers,

*Steve Gilberd*
Erayd LTD *·* Consultant
*Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237*
*PO Box 10019 The Terrace, Wellington 6143, NZ*

[-- Attachment #2: Type: text/html, Size: 2815 bytes --]

Re: Allowed IPs Toggling

[Tim Sedlmeyer]

Allowed-ips plays a variety of roles which at different times can be
mapped to several traditional network roles but one it doesn't really
play the role of routing table. Instead they act as a forwarding
information base for the wireguard interface matching ip addresses to
peers. Wireguard then makes forwarding not routing decisions based
upon this "FIB". Since it is acting as a FIB at any given time it can
contain only a single destination for any given entry.

If you want support for things like equal cost multipath (something
that will never be possible over peers on the same interface), route
failover and metric weighted routing than a routing process must get
involved to make the routing decisions, populate the routing table and
then manage entries in the "FIB" based upon the routing table. As it
stands today there are not, at least not readily publicly available,
any routing processes which can interact with WireGuard to do so. This
is why today to do any sort of dynamic routing with wireguard the
peers involved need to be assigned to different interfaces and
allowed-ips on them set to 0.0.0.0/0 or the total subset of ip
addresses which might ever traverse a peer under any routing
situation. Existing routing processes can then just treat them as
traditional interfaces and not worry about updating the "FIB".

On Thu, Mar 15, 2018 at 2:39 PM, Steve Gilberd <steve@erayd.net> wrote:
>> Allowed IPs is like a routing table; you can't have two routes for the
>> same set of IPs
>
> If this is the case, then wireguard does not have proper routing support.
>
> Normally, routing tables allow both multiple and overlapping routes prese=
nt.
> When making routing decisions, the most-specific route is chosen (e.g. a =
/29
> is higher priority than a /24 which overlaps with it). If there are two
> identical routes of the same size, then the one with the lowest routing
> metric is used.
>
> I can understand not allowing identical routes of the same size, as
> wireguard doesn't really have a concept of metric (although it could be
> useful for backup links). However, it really should allow overlapping rou=
tes
> of different sizes. There's no ambiguity with routing decisions, and it's=
 a
> standard feature that I would normally expect any IP routing stack to hav=
e.
>
> Cheers,
> Steve
>
>
> On Fri, 16 Mar 2018, 04:57 Samuel Holland, <samuel@sholland.org> wrote:
>>
>> Hello,
>>
>> On 03/15/18 10:31, Gianluca Gabrielli wrote:
>> > I was setting two peers on the server, but every time I re-add one of
>> > these
>> > two the other one is shown with (none) on "allowed ips" field. Of cour=
se
>> > that
>> > blocks communications with that peer. If I try to re-add it, then the
>> > other
>> > peer loses its configuration, same problem.
>>
>> Allowed IPs is like a routing table; you can't have two routes for the
>> same set
>> of IPs, or WireGuard doesn't know which peer to send the traffic to. You
>> want to
>> have non-overlapping Allowed IP ranges. This usually means that the rang=
e
>> of
>> Allowed IPs is smaller than the host's subnet. For example:
>>
>> Host A:
>> IP configuration for WireGuard interface: 192.168.123.1/24
>> Allowed IPs for Host B: 192.168.123.2/32
>>
>> Host B:
>> IP configuration for WireGuard interface: 192.168.123.2/24
>> Allowed IPs for Host A: 192.168.123.1/32
>>
>> The IP configuration tells the kernel which IP ranges are accessible via
>> the
>> WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of
>> those IPs
>> is associated with each peer.
>>
>> > Cheers,
>> > Gianluca
>>
>> Cheers,
>> Samuel
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
> --
>
> Cheers,
>
> Steve Gilberd
> Erayd LTD =C2=B7 Consultant
> Phone: +64 4 974-4229 =C2=B7 Mob: +64 27 565-3237
> PO Box 10019 The Terrace, Wellington 6143, NZ
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

Re: Allowed IPs Toggling

[Gianluca Gabrielli]

Thanks very much to everybody, like always professional and straight to the=
 point!
One of the best ml ever :)

Cheers,
Gianluca