wg addconf :: AllowedIPs gets deleted with the additions of peers

[Toke Høiland-Jørgensen]

Adrian Sevcenco <adrian.sev at gmail.com> writes:

> On 06/25/2018 11:37 PM, Toke Høiland-Jørgensen wrote:
>> Adrian Sevcenco <adrian.sev at gmail.com> writes:
>> 
>>> On 06/25/2018 10:55 PM, Toke Høiland-Jørgensen wrote:
>>>> Adrian Sevcenco <adrian.sev at gmail.com> writes:
>>>>
>>>>> Hi! It seems that AllowedIPs declaration gets erased when peers are
>>>>> added with addconf
>>>>
>>>> You can't have the same AllowedIPs for two different peers... :)
>>>
>>> Err... so, it's a bug or a feature?
>> 
>> A feature. The AllowedIPs controls which IP addresses will be routed to
>> that peer. They refer to addresses inside the tunnel. So depending on
>> your setup you'd specify the single IP you assign each peer, or possibly
>> any subnets behind that peer you want routed through the tunnel.
> Then, how can i set a default allow everything for each peer? Should i 
> make a different tunnel for each peer?

Yes, if you want point-to-point links where all traffic is sent to a
single other peer, you'll need separate interfaces.

If you want a road warrior type setup, where client devices connect to a
server and use that as a default gateway, you'd assign each client a
single IP (inside the tunnel) and put that in each peer config's
allowedips. The clients can then all have 0.0.0.0/0 as allowedip of the
server.

> But given your explanation i still feel that it is a bug that when an 
> AllowIPs is declared with the addition of a second peer the declaration 
> from the first peer gets erased ...

Well, the UI can be surprising, sure, but the alternative would be to
report an error if you try to set the same allowedIP on different peers,
which is not necessarily better. And it's not a bug in that it is
intentional behaviour ;)

> It should be either a global setting per tunnel OR an individual setting 
> per peer (in which case it should stay set)

I think the point of confusion is that it is called 'allowedips', but it
really means 'ips that are allowed from this peer *and* routed to this
peer'. I.e., it is also a routing table. See
https://www.wireguard.com/#cryptokey-routing


-Toke