Hi, first of all thanks for your reply. It became clear that there were some misunderstandings on my side. On Mon, Apr 19, 2021 at 09:41:33PM +0200, Ondrej Zajicek wrote:
On Sun, Apr 18, 2021 at 08:55:12PM +0200, Stefan Haller wrote:
In a recent change in the FreeBSD Wireguard kernel module the POINTTOPOINT interface flag is dropped for wg interfaces[1]. This behaviour will probably not change, because Wireguard is not peer-to-peer or a broadcast domain, but peer-to-multipoint. Hence my previous configuration of setting peer addresses on the interface is not working anymore:
ifconfig wg0 inet 192.168.0.10/32 192.168.0.4
Hi
Just to be sure, Wireguard is really PtMP (some peers on the iface may not be able to communicate between themselves directly) and not NBMA? In that case this network setup makes sense.
That is true, yes. For example, one could build something like this here: A ----- B | / | | / | | / | C ----- D A and D can not communicate directly. This happens in my case, for example, because A and D sit at different dormitory home connections and can not talk to each other directly (easily).
Note that this actually models the real world better, because Wireguard is not point-to-point but point-to-multipoint. So multiple peers can be done in the following way:
ifconfig wg0 192.168.0.10/32 route add 192.168.0.4 -iface wg0 route add 192.168.0.8 -iface wg0
However, this does not work with bird 2.0.8: bird will not recognize the p2p peer addresses as gateways and it will log on kernel table rescan:
Yes, the main issue is that (sans onlink flag) BIRD validates next-hops against interface ranges and not against direct (non-gateway) routes. In most cases it does not matter but with PtMP it would require manually configuring multiple PtP address pairs for an iface.
I see. I think I cleared up my confusion. So on Linux, if I have wg0 with 192.168.0.10/32 configured and I issue: ip route add 192.168.0.4 dev wg0 The equivalent of calling `neigh_find(..., "192.168.0.4", "wg0", ...)` will _not_ find the neighbor. I misread the netlink code and thought the goal of it was to enable this neighbor to be found. Thanks for your explanation. That's why I wanted to replicate it on BSD.
[...]
The proper solution (on Linux) is that the second route (for 192.168.42.0/24) also has onlink flag, so it does not depend on existence of route for 192.168.0.4/32. Babel in BIRD generates routes with onlink flag.
This configuration is working now with Babel + BIRD 2.0.8 on Linux (I was still on 2.0.7 when testing it on Linux previously). Looks like that it would not work with e.g. OSPF. What I still don't get exactly is the following mismatch: (i) If the route is read from the kernel, BIRD checks if the next-hop is reachable by any interface network (= stricter check than kernel). (ii) However, if BIRD sends the route to the kernel it will not check if the gateway is reachable. If BIRD thinks the gateway is unreachable and the route still gets installed (because it in fact is), BIRD will never be able to correctly read the route back in. Shouldn't there be a check in (ii) too?
[...]
I see the problem as BIRD internally support onlink flag, but BSD kernel does not support that flag, so onlink routes exported to BSD kernel are not read back properly. Seems to me that there is a simple woraround:
When i read a route (from kernel on BSD) that has gateway on iface, which has only /32 or /128 IP address(es), so no proper iface range, then i would assume onlink flag for the route (its nexthops).
I will continue working in this direction. Kind regards, Stefan