Overlapping AllowedIPs Configuration

[Vincent Wiemann]

> we have the same problem here, although our allowed IP ranges should be
> 0.0.0.0/0 for all peers.
> We have OSPF traffic on the wireguard links so it should be task of the
> Kernel's routing table to decide where to send what.

This is not possible with a layer 3 tunnel as the kernel routing table only
knows which route goes to which interface.
I'm working on a layer 2 WireGuard version, but due to lack of funding and free-time
it is not in a state in which I'd like to release it.

As already stated there is still the possibility to use a separate
WireGuard interface per peer or let OSPF set WireGuard's peer's routes which
requires a modification of the OSPF daemon.

On 07.06.19 12:07, Matthias Urlichs wrote:> On 07.06.19 10:05, Ivan Labáth wrote:
>> As per the original question, I do find it strange, that a transient
>> modification of a peer can remove routes from another peer. Also
>> discarding routes in general, even more so when done silently.
>
> It might be helpful to have an option that disallows (silently)
> replacing another peer's route.

As far as I understand, this should not happen at all as overlapping peers
should not be allowed as this breaks cryptokey-routing.

Regards,

Vincent Wiemann