Export strongSwan generated routes as plain stub network routes via OSPF
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). Is there anything I can do to export the networks that the VPN concentrator connects as stub networks, even though they aren't connected through an interface, but just as entries in a routing table (some are RTD_DEVICE, others RTD_ROUTER)? As a twist: I cannot export bigger networks as static stub nets to the corresponding VPN concentrator and then have some policy there which catches currently unroutable networks, as there are multiple (load-balanced) VPN concentrators in the backbone area, and I don't know in advance which networks are connected to which VPN concentrator - that's why I wanted to use OSPF to propagate the actual connections from the strongSwan generated routing table(s). Thanks for any hints on how I might get this to work! Heiko.
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@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."
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@crfreenet.org> Gesendet: Mittwoch, 9. Dezember 2020 21:44 An: Gehrkens.IT GmbH | Heiko Wundram <heiko.wundram@gehrkens.it> Cc: bird-users@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@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."
participants (2)
-
Gehrkens.IT GmbH | Heiko Wundram -
Ondrej Zajicek