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 , 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.
You do not have the required permissions to view the files attached to this post.