AW: Export strongSwan generated routes as plain stub network routes via OSPF
Gehrkens.IT GmbH | Heiko Wundram
heiko.wundram at gehrkens.it
Thu Dec 10 08:13:29 CET 2020
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 <santiago at crfreenet.org>
Gesendet: Mittwoch, 9. Dezember 2020 21:44
An: Gehrkens.IT GmbH | Heiko Wundram <heiko.wundram at gehrkens.it>
Cc: bird-users at network.cz
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: 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."
More information about the Bird-users
mailing list