MikroTik

Should hopefully be a simple answer...

I have a particular environment I'm working with that has a IPSec tunnel from a main router to a 3rd party operated network (tunnel is working fine), and I also have 5 other OSPF connected routers that also connect to that same main router. All connectivity is working except the route propagation for the IPSec network.

I'm stuck on how do I distribute the route to the remote IPSec network via OSPF. I can add a static route on the remote routers (to the main router via their existing connections) and all connections work correctly, I just can't seem to figure out how to distribute the IPSec connected route to the remote routers via OSPF.

bump, any ideas on this? still stuck...

I have the same issue.
Is there a way to distribute it over OSPF ?

Have you tried network-type NBMA, static OSPF neighbors and static routes for the neighbors? Anything with broadcast hellos in either direction won’t work because of the tunnels and the intermediate routed hops. As long as both sides of the IPsec region have enough to figure out how to unicast to their static OSPF neighbor, it shouldn’t matter what’s in the middle. (So long as the third party tunnel router isn’t filtering IP protocol 89…)

Frankly I haven’t tested this and when I get near a lab I’ll give it a shot. There might be a limitation I’m forgetting about.

Rereading the question I'm not sure I even understood the topology correctly. See below.

IPsec typically is policy-based so anything matching policies is intercepted for processing, see the IPsec policies in https://help.mikrotik.com/docs/display/ ... Interfaces, not route-based hence no routes to redistribute.

Some vendors have virtual interfaces, e.g. Cisco VTI. With Mikrotik you can use GRE or IPIP tunnels with IPsec to provide similar functionality.

Looking at this again I think I misunderstood the scenario as you having two routers you control on opposite ends of a L3 provider in the middle. I attached a messy mspaint sketch of my second reading to see if that's correct before I open my mouth more. Is this x.x.x.x/x prefix on the far side of the IPsec link that you're trying to get into OSPF? Also some clarification about whether it's raw IPsec w/ manual policy or whether you've got something else like L2TP/GRE/IPIP happening over it would be helpful.

From I know but not test in RouterOS, the Cisco world will use rule like on "main router"
/ip route add dst-address=x.x.x.x/x gateway=(eth2 or IP@eth2)

This is always a problem with RouterOS. For now we can try use some workaround
*) SNAT&DNAT to pass traffic between one IPSec to other IPSec/Router - not your case
*) add a layer with e.g. GRE on IPSec and use route at GRE as interface. This can be distribure.
*) add next SPOF litle router who do IPSec and be between, thanks that your "Main router" do normal route and can distribure it.

The way I've done this before is to add a loopback (bridge) interface, add static routes for the remote network, then redistribute the static routes with OSPF. IPsec will intercept the traffic when there's an active policy. If the IPsec tunnel is down, the route will still be distributed - if that's a problem for you, there might be a way to script it (enable/disable the static route based on a ping to the other end of the tunnel).

cpbruton write:

The way I've done this before is to add a loopback (bridge) interface, add static routes for the remote network, then redistribute the static routes with OSPF.

You can give more detail ?

Example:
Local src.address in local enc.domain is 192.168.10.0/24
Remote dst.address in remote enc.domain is 192.168.20.0/24
Target remote subnet who not exist as enc.domain of any of site's: 192.168.21.0/24

bridge-lo with what IP ?
Route to 192.168.21.0/24 via what ?

Suppose:
R1 = OSPF connected router (1 of 5) - connected network 192.168.10.0/24
R2 = main router
R3 = 3rd party router - connected network 192.168.30.0/24

There is a pure IPsec tunnel between R2 and R3. The goal is to have a route to 192.168.30.0/24 distributed to R1 using OSPF. But we cannot run any routing protocols between R2 and R3.
So R2 must be running IPsec in tunnel mode (not transport mode), and has a policy to encrypt traffic with src-address 192.168.10.0/24 and dst-address 192.168.30.0/24. Assume that R3 has the correct reverse policy in place.

Since we can't receive an OSPF route from R3, we instead have to generate it on R2. So first we create a loopback interface bridge-lo. From here there are two options.

Option 1: Add a static route to 192.168.30.0/24 via the bridge-lo interface and configure OSPF to redistribute static as type 1. We don't need to give bridge-lo an IP address at all in this case. On ROSv6:

Option 2: Give the bridge-lo interface any IP address in 192.168.30.0/24, and add it as a passive interface to OSPF. On ROSv6:

Basically we are tricking R2 into thinking it has a way to get to 192.168.30.0/24 via an interface - either with a static route or as a directly connected network. But that traffic will never actually hit the loopback interface - instead, it will be picked up by the IPsec policy and forwarded to R3 over the tunnel.

Basically we are tricking R2 into thinking it has a way to get to 192.168.30.0/24 via an interface - either with a static route or as a directly connected network. But that traffic will never actually hit the loopback interface - instead, it will be picked up by the IPsec policy and forwarded to R3 over the tunnel.

I would have bet this wouldn't work but it absolutely does. According to the published packet walk diagrams [1], a packet that needs to cross the tunnel should encounter a routing decision (2.) before it ever hits an IPsec policy decision (5.). It never really occurred to me that this routing decision is really fully irrelevant as long as there is any valid route for the packet. Policy-matching packets are always recirculated through a second routing decision (7.) so the first one really is a formality.

Nonetheless, a third alternative to the two @cpbruton presented is to have a static route for the target network with the next-hop of the IP of the IPsec peer. This static route is then redistributed into OSPF. This is equally as bogus from an actual routing perspective, but it does avoid having a loopback (you probably have one anyway) and it has the added benefit of automatically being marked invalid if the recursive next-hop resolution fails (e.g. all paths for the tunneled traffic are dead). Once invalid, it will also be purged from the OSPF database. Obviously this is only a little bit better because there a ton of circumstances where the tunnel is broken even though the IPsec peer is reachable, but it's a start.

Here's what this looks like:


Not being able to leave well-enough alone, I also tested a fourth and more cursed alternative that handles failures even more completely. To do this, install 1) a static route of the far side router's address (10.3.0.1/32) with the next-hop of the IPsec peer address and 2) a static route of the target network (10.3.0.0/24) with the next-hop of 10.3.0.1 and check-gateway=ping. You do have to mess with the target-scope of #2 because otherwise it will never go active (it relies on #1 which has a scope of 30 by default). By doing this, if 10.3.0.1 becomes ICMP unreachable (the best indicator of the tunnel failing) then 10.3.0.0/24 becomes invalid.

The only remaining problem at that point is that if you are still just blindly doing redistribute-static=as-type-1 you will also get 10.3.0.1/32 in your OSPF database when you might not actually want or need it. In my case, I simply upped the 10.3.0.1/32 scope to something higher than all else (say, 40) and then indicated that the 10.30.0.0/24 route should recurse to a target-scope of 40. Then I added a routing filter for chain=ospf-out that filters all routes with a scope of 40 and permits everything else. There are a bunch of ways that could be done but that seemed like the least likely to have other side effects.

This does seem to work despite the extensive delay for check-gateway=ping to discover the failure and for the resulting recursive route invalidations and OSPF changes to trickle down to R1. The moral of the story is really to run OSPF-over-GRE-over-IPsec-transport-mode when at all possible so you can avoid this garbage. But if you can't, maybe this garbage will work for you A combined configuration is also attached.

[1] https://wiki.mikrotik.com/wiki/File:IpsecFlow.png