FRR OSPF distribute route for OpenVPN Interface
itsdave last edited by
i have several pfsense running with configured FRR OSPF (just one area) with a dozen of routes being distributed just fine.
In addition I would like to distribute the route to an OpenVPN server Roadwarrior network. I think I should be able to do this by adding this interface as a OSPF interface and setting it to passive.
This even changes the ospfd.conf an adds a network:
passive-interface ovpns8 network 10.25.58.0/24 area 0.0.0.0
But this is still not distributed.
It does also not appear on Status-->OSPF Database
But i can see it in the Zebra Routes, even if i delete this Interface in the OSPF interfaces:
K * 10.25.58.0/24 [0/0] via 10.25.58.2 inactive, 00:08:30 C>* 10.25.58.0/24 is directly connected, ovpns8, 00:08:30
The only way i could make it work is to check "Redistribute connected networks" in the OSPF settings, but this brings up all connected networks - with a lot of stuff i don`t want to be distributed.
I even tried to set it up as an Zebra static route an use "Redistribute FRR static routes" but this did not work also.
Is there a clean way to distribute this particular OpenVPN Network?
srain last edited by
I have this exact issue. I needed to introduce 198.18.5.0/24 for my OpenVPN remote-access users, and nothing I tried worked for this network. I was eventually able hackishly get it working by adding a larger supernet, of which this network was a part of.
I added 198.18.4.0/23 to the Global configuration, which OSPF then picked up and redistributed:
It's now showing up as an E2 route though:
It works, but is by no means ideal. I thought of creating an access list or route map like you suggested, but that would also not be ideal. Any idea why it doesn't work the way it should?
If you find a better solution please let me know :)
nzkiwi68 last edited by
2.4.4-p3 with FRR 0.5.2
I had exactly the same issue. I tried very hard to get OSPF to distribute the local OpenVPN subnet (10.9.9.0/24) to the remote pfsense/OSPF end and couldn't get any of the following to work;
1. I tried adding the OpenVPN interface as an interface Services > FRR > OSPF > OSPF Interfaces and setting that interface as "Interface is Passive"
2. Next I added the network 10.9.9.0/24 to Services > FRR > Global Settings and tried setting the "Static Route Target" as the actual local OpenVPN Interface (didn't work) and then as "localhost" (also didn't work)
The only way I could actually get the OpenVPN subnet to be seen by OSPF was to add a supernet of 10.9.8.0/23 to Services > FRR > Global Settings with
subnet: 10.9.8.0/23 Route: Localhost
(And of course in all cases under Services > FRR > OSPF > OSPF Settings select "Redistribute FRR static routes"
Thank goodness for your post with the idea of the supernet!
I know this is odd but it's just how FRR behaves these days. Quagga didn't do this, but Quagga had other behaviors with these links that were not desirable, too.
It is the culmination of a few fun quirks:
- FRR treats OpenVPN interfaces as point-to-point interfaces, so it doesn't latch onto the whole subnet of the interface in the way you expect.
networkstatements in the OSPF config do not tell OSPF which specific networks to redistribute, they only define the networks in which interfaces exist that FRR should use. This is an older confusing syntax we should probably deprecate in the package, for just this reason.
- FreeBSD only supports one route per matching network so your FRR static route wouldn't stick because FreeBSD already has a route in its kernel routing table for the same network. Using a supernet works because that route doesn't already exist in your routing table.
- It should work with redistribute connected or redistribute kernel, but that may do too much. The GUI should probably let you pick a route-map to filter this which would get closer to what you want to see.
So there isn't a bug here, just confusing behavior on behalf of FRR. The GUI could be improved but it would take some design work and big changes to do it right. It'll happen eventually, though. We've been working a lot on OSPF for TNSR so a lot of this is fresh in my mind, so it might be sooner rather than later, but that depends on available time.
nzkiwi68 last edited by
@jimp Thanks very much for the reply. I now understand what's going on.
I think the route-map filter will be the ultimate way forward, but, at least until then a supernet works.
Thanks again for the informative note.
FRR 0.6 should allow working around this in several ways. See https://forum.netgate.com/topic/144572/frr-0-6-coming-big-changes-to-ospf