Hello Ondrej, tip number 1 is perfect, thanks for the hint! I knew that this was possible (i.e. changing the route type to RTD_PROHIBIT in my case, which is also semantically correct in the other routing tables that the IPsec routes are supposed to be propagated to), but I didn't think to do it earlier in the route import (i.e. directly in the kernel protocol) so that the RTD_PROHIBIT route would then be spread everywhere else and also cause OSPF to present a stub route. I'm doing just this for another routing table, but in that case, keepalived inserts the prohibit routes...
Anyway, a big thanks, that tip helped a lot to get my thoughts straight. 😊 Heiko. -----Ursprüngliche Nachricht----- Von: Ondrej Zajicek <[email protected]> Gesendet: Mittwoch, 9. Dezember 2020 21:44 An: Gehrkens.IT GmbH | Heiko Wundram <[email protected]> Cc: [email protected] Betreff: Re: Export strongSwan generated routes as plain stub network routes via OSPF On Wed, Dec 09, 2020 at 05:22:14PM +0000, Gehrkens.IT GmbH | Heiko Wundram wrote: > Hello all, > > I'm currently trying to get strongSwan generated IPsec rules to play nice > with the OSPF implementation of bird. The problem I'm facing is that > currently, the strongSwan generated routes are added properly to the > corresponding IPsec routing table (for all those that have an IPsec tunnel up > with the VPN concentrator), but most of the routes contain a gateway (set up > from the default route on the VPN concentrator, pointing to its default > gateway, for the VPN network). These gateways are useless with respect to the > actual IPsec transport (because the XFRM policy overrides the nexthop target > anyway), but are used in source address selection for local outgoing > connections from the gateway (that's why strongSwan inserts the routes this > way). > > Now, I'd like to export the routes that are up on the VPN concentrator to the > OSPF neighbors of it (all OSPF peers are in the backbone area of this > network), which of course means that bird doesn't export a route pointing to > the VPN concentrator for the networks that are up (i.e., a stub network), but > rather exports the corresponding gateway route. This means that all other > hosts try to route packets to the IPsec tunnel via the default gateway that > the VPN concentrator has set up, and not via the VPN concentrator itself, > which breaks the IPsec routing. > > I've tried overriding the route type (i.e., to RTD_DEVICE) on import > into the OSPF instance, and also clearing out/resetting the gateway, > but the former is forbidden, and the latter doesn't do what I expect > it to do (I tried setting up the IP address of the VPN concentrator in > the corresponding imported route in the OSPF instance as the gateway, > but that doesn't seem to properly be propagated). Hello If i understand it correctly, you have routes with a next hop and want export it to OSPF as a route without nexthop, so it is routed by others to the originating router? There are 3 ways to do that (in BIRD 2.0.7): 1) change route type to a different type than RTD_UNICAST, e.g. RTD_UNREACHABLE: dest = RTD_UNREACHABLE. 2) change route to a direct (device) route (both direct and indirect routes in BIRD 2.0 are RTD_UNICAST): ifname = "eth0"; 3) change nexthop to an IP address from a prefix of an iface that is not handled by the OSPF protocol. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
