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