OSPF over openvpn; adjacency problems
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; }; }; }; }
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; }; }; };
}
On Tue, Oct 01, 2019 at 08:13:17PM +0200, 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":
Hi This seems like BIRD does not recognize src IP address as from immediate neighbor, so it ignores it. What is IP address reported by 'birdc show interfaces' or 'ip addr list' for that iface? BIRD expects only packets from 10.25.0.2 here. We examined OpenVPN issues in the past and IIRC OpenVPN does some very strange things with IP stack (like having 'virtual' router between VPN links and VPN server) that breaks things. Not sure if these issues are specific to tun mode or also appear in tap mode. If you need to use OpenVPN and OSPF, i would suggest to just create GRE tunnel inside it (between VPN server and client) and run OSPF through the GRE tunnel. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Kees and Ondrej, thanks a lot for your answers and your suggestions. I am rather new to the bird codebase and please forgive me if I make a blunder, but from my point of view openvpn should not be blamed here. I dug a bit into the code and ospf_rx_hook() got all needed packages. They were just silently filtered. I used the version in Debian Buster (1.6.6) and Unstable (1.6.8) and after adding the patch below, I got an adjacent neighbor over the openvpn link in state "Full/PtP" and in a different area one with "Full/BDR". Probably I broke something else ... Best regards Thorsten Index: bird-1.6.6/proto/ospf/packet.c =================================================================== --- bird-1.6.6.orig/proto/ospf/packet.c +++ bird-1.6.6/proto/ospf/packet.c @@ -230,10 +230,11 @@ ospf_rx_hook(sock *sk, uint len) if (ifa->state <= OSPF_IS_LOOP) return 1; - int src_local, dst_local, dst_mcast; + int src_local, dst_local, dst_mcast, link; src_local = ipa_in_net(sk->faddr, ifa->addr->prefix, ifa->addr->pxlen); dst_local = ipa_equal(sk->laddr, ifa->addr->ip); dst_mcast = ipa_equal(sk->laddr, ifa->all_routers) || ipa_equal(sk->laddr, ifa->des_routers); + link = (ifa->addr->pxlen == MAX_PREFIX_LENGTH); if (ospf_is_v2(p)) { @@ -243,7 +244,7 @@ ospf_rx_hook(sock *sk, uint len) * that (src_local || dst_local), therefore we are eliminating all * such cases. */ - if (dst_mcast && !src_local) + if (!dst_mcast && !src_local && !link) return 1; if (!dst_mcast && !dst_local) return 1; @@ -322,10 +322,6 @@ ospf_rx_hook(sock *sk, uint len) if (instance_id != ifa->instance_id) return 1; - /* It is real iface, source should be local (in OSPFv2) */ - if (ospf_is_v2(p) && !src_local) - DROP1("strange source address"); - goto found; } else if ((areaid == 0) && !dst_mcast)
participants (3)
-
Kees Meijs -
Ondrej Zajicek -
Thorsten Alteholz