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 at 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 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 at 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 at 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
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>