OSPF not advertising tun IPs with OpenVPN

[Ondrej Zajicek]

On Sat, Oct 05, 2013 at 01:05:11PM -0500, Thomas Johnson wrote:
> I am having some difficulty getting my OSPF configuration to play nicely
> with OpenVPN tunnels on FreeBSD. I have a number of point-to-point tunnels
> between sites, with a BIRD instance running on each tunnel endpoint.
> Endpoint addresses for a tunnel use a logical /31. Initially, the BIRD
> instances would talk to each other, but the endpoint addresses were not
> advertised by OSPF, making them unreachable.

Yes, for several reasons, ptp addresses of non-stub ifaces are not
advertised by OSPF and have to be explicitly configured by stubnet
option.

> I remedied this by adding stubnet declarations (/32) for each of the tunnel
> endpoints.

You added as stubnet local /32, remote /32 or both?

Personally, i would add just local /32.

> This has the effect of making all of my endpoint addresses
> reachable, but causes another issue. In this configuration, if I restart
> one of my OpenVPN tunnels, it fails to set addressing on the tunnel,
> because the host route already exists in the routing table (due to the
> stubnet).

Because OSPF does not generate routes for local networks (including local
stubnets), i guess that the problem was caused by /32 stubnets propagated
through OSPF, which would generate some indirect /32 route that is exported
to kernel and would collide with the direct route.

This problem is not really specific to stubnet option, it could
happen even if these addresses would be advertised automatically,
but it would be a race condition between OSPF convergence and
OpenVPN reestablishment. It is a general problem of collisions
between kernel device routes and BIRD routes.

On Linux, using separate kernel table (or perhaps a different
krt_metric) for BIRD routes should ultimately help. I am not sure if
there is such simple way to avoid it on BSD.

Perhaps the problem could be avoided if you configure both local and remote
/32s as stubnets. In that case local stubnets always win, so no indirect
route is found. Or setup a stubnet for whole /31.

Another solution would be to have an import filter which explicitly rejects
any /32 route that should be directly reachable by OpenVPN:

filter ospf_in
{
 if net ~ [ 1.2.3.4/31+, 1.2.3.10/31+ ]
 then reject;
 else accept;
}

protocol ospf
{
  import filter ospf_in;
  ...
}


But both suggestions are not optimal and have some problem.


I would have another suggestion - do not propagate these as independent /32s.
Either consider them as a kind of 'link-local' IP, or use IPs for them from
some wider pool (either some local ethernet stub network or some designated
pool of ptp endpoint IPs for given router), which is propagated as a whole.


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20131005/20ee84c4/attachment-0001.asc>