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;
> };
> };
> };
>
> }
>
>
