Community discussions

 
cantanko
newbie
Topic Author
Posts: 28
Joined: Mon Apr 05, 2010 12:53 am

Black hole routes and IPSec VPN scopes

Fri Mar 22, 2019 9:03 pm

Hello,

Typically when setting up a router I add the standard bunch of non-internet-routable RFC1918 / documentation range / "reserved for future use" address ranges as blackhole, prohibited or unreachable routes so that packets can't escape in an uncontrolled manner. It also means (in the case of prohibited / unreachable routes) users are told which router can't deliver their packet rather than either silently dropping it or sending it out of a wider scope route, typically the default:
add distance=1 dst-address=0.0.0.0/8 type=unreachable
add distance=1 dst-address=10.0.0.0/8 type=unreachable
add distance=1 dst-address=100.64.0.0/10 type=unreachable
add distance=1 dst-address=169.254.0.0/16 type=unreachable
add distance=1 dst-address=172.16.0.0/12 type=unreachable
add distance=1 dst-address=192.0.0.0/24 type=unreachable
add distance=1 dst-address=192.0.2.0/24 type=unreachable
add distance=1 dst-address=192.168.0.0/16 type=unreachable
add distance=1 dst-address=198.18.0.0/15 type=unreachable
add distance=1 dst-address=198.51.100.0/24 type=unreachable
add distance=1 dst-address=203.0.113.0/24 type=unreachable
add distance=1 dst-address=240.0.0.0/4 type=unreachable
As such, if (for example) a PPP session comes up that has subnets of the above ranges used, these suddenly become routeable and everything is lovely. If the site isn't there, an error; if it is - transit. Great.

With IPSec, however, this appears not to be the case. If, for example, you have two sites - 10.1.2.0/24 and 10.3.4.0/24 with 10.1.2.0/24 directly attached to the router in question, even when the IPSec link is up, SAs are established and so on, the route is still classed as unreachable.

Before (I think) 6.44, I could add a static with the gateway set as the remote IPSec peer and, whilst this didn't show as active (the remote gateway is obviously not on a directly-connected network) it did work sufficiently to allow the more-specific route to be considered active by the routing table it would therefore allow the packet to be routed via IPSec.

Now it would appear this can not be done, and instead you have to notch out the (in my case often rather small and inconveniently placed) subnets with many, many mutually exclusive in-between "unreachable" routing table entries rather than just have, say 10.0.0.0/8 as unreachable and 10.3.4.0/24 added as a static (but inactive due to the non-local gateway) route.

Is there a more correct way of doing this, or am I now stuck in routing table purgatory whilst I write a few thousand filler rules between the subnets?

Cheers!

Who is online

Users browsing this forum: No registered users and 28 guests