-
Hi,
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.0But 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:30The 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?
-
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 :)
-
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.
- The
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.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@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
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@nzkiwi68 I was having the same issue, and couldn't figure out why FRR 0.6.3_1 on 2.2.4-p3 was refusing to advertise route to openVPN tunnel, and then I came across your suggestion. Works great!
@jimp I still need to use a supernet to get FRR OSPF to advertise the subnet correctly despite it being on the latest version, so I think this ultimately an OS / OpenVPN issue as you described.
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.
Oddly enough it works as expected with IPv6, just not IPv4, but the behavior at the OS level is slightly different:
OpenVPN IPv4 subnet: 10.125.255.0 (was using /24 but wouldn't route, so used /26) on the OpenVPN interface instead.
OpenVPN IPv6 subnet: xxxx:yyyy:1100:a001::/64 you can see it shows up differently in the routing table and is properly advertised by OSPF6In both cases OpenVPN's actual interface shows up as a loopback interface, but additionally in IPv4 it it puts in a /32 which is what initially shows up via OSPF.
10.125.255.0/26 10.125.255.2 UGS 0 1500 ovpns1 10.125.255.1 link#8 UHS 0 16384 lo0 10.125.255.1/32 ovpns1 U1 0 1500 ovpns1 10.125.255.2 link#8 UH 0 1500 ovpns1xxxx:yyyy:1100:a001::/64 link#8 U 0 1500 ovpns1 xxxx:yyyy:1100:a001::1 link#8 UHS 0 16384 lo0 -
@itsdave @srain @nzkiwi68 @awebster
I managed to redistribute exact openvpn networks without usage of supernets in other way:
interfaces > assignments > and assigned openvpn interfaces and enabled them in interfaces menu:
and added "static route targets" pointing to those previously created (and enabled) openvpn interfaces: services > FRR global/zebra > global settings > route handling
hope this will help someone and sorry for reviving a quite old post:)
