Hi Thorsten, I'm not very into BIRD code or OSPF as a protocol but I do know a thing or two about OpenVPN and general networking. According to your sample, it seems BIRD uses the IANA assigned multicast addresses to communicate and (try to) form an OSPF adjacency. Per default, OpenVPN uses the regular addresses specified and multicasting doesn't work. Either BIRD should not use the multicast addresses in this case and "fall back" to unicast ór you should configure OpenVPN with TAP instead of TUN with just some /30 network on top. In this case multicasting would very likelely to work on the L2 segment (TAP is L2, TUN is L3). In my opinion unicasting is more elegant but I'm not sure if OSPF (or BIRD) supports this and how one should configure that. If you're going for L2: be very aware of MTU c.q. MSS issues. I hope this helps. Cheers, Kees On 01-10-2019 20:13, Thorsten Alteholz wrote:
Hi,
I am trying to use OSPF over an openvpn link. tcpdump tells me that both ends send their HELLO packet but bird does not want to recognize them.
When looking at ospf_rc_hook() in proto/ospf/packet.c the HELLO packet arrives in bird, but is discarded because of "strange address combinations":
src_local is 0: sk->faddr = 10.25.0.26 ifa->addr->prefix = 10.25.0.2 ifa->addr->pxlen = 32
dst_mcast is 1: sk->laddr = 224.0.0.5 ifa->all_routers = 224.0.0.5 ifa->des_routers = 224.0.0.6
dst_mcast = 1 || 0
From my point of view these values do not look that bad (the tun interface on this server has an address of 10.25.0.1 and on the client it is 10.25.0.26). But of course (dst_mcast && !src_local) is 1 and the HELLO packet is ignored.
Does anybody have any idea what went wrong here?
Best regards Thorsten
The OSPF configuration on the server:
protocol ospf { debug all; import all; export none;
area 10.10.10.0 { interface "tun1" { type ptp; cost 2000; neighbors { 10.25.0.1; }; }; };
}