cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3502
Views
0
Helpful
2
Replies

Reverse route injection on ASA5510 site-site VPN's

rscho
Level 1
Level 1

Hi forum,

We have two ASA5510's connected to two different ISP's and both able to initiate a site-site IPsec connection to a remote site. Depending on the state of the ISP's either ASA may initiate this VPN.

We use Reverse Route Injection into OSPF for VPN clients and it works fine with the route being distributed when a client connects and disappearing when there are no clients.

So we thought we'd try it for our site-site VPN's. Unfortunately when we enable Reverse Route Injection the routes are distributed regardless of whether the VPN is up or not, so if one ASA has initiated a VPN it's reverse route is distributed (which is what we want) but the other ASA also distributes a route for it's non-existent VPN. The result is that our gateway routers see two OSPF routes and can't ascertain which route is actually up.

Is there any way to distribute the route using Reverse Route Injection (or any other method) only when a site-site VPN is actually up? For various reasons we can't use BGP or other gateway routing protocols.

Our ASA5510 are currently running IOS 8.2(1)

We'd be grateful for any tips anyone may have.

2 Replies 2

Roland Duhme
Level 1
Level 1

Hi Rudi,

We got this working but only that way that we did'nt configure the Tunnel-Groups for the specific peers and Used instead the Default-L2L-Group. But this means that our L2L-VPN Acts like a dial-in VPN. For us that was ok.

Hope that helps.

Regards Roland.

jonrojas
Level 1
Level 1

Hi Rudi,

I can´t assure this 100% if this is your case because I don´t have the information available since I´m not at the office, though there is a documented bug for the reverse routes getting stucked even where there is no vpn tunnel up, right now I don´t remember the exact version of the problem and if there have been any fix for this but I will try to get you the information on Monday if nobody has been able to give you any response by then.

There are many workarounds I can think of in case there is not a fix yet, though it will be a better idea to check that information first, and in case it is necessary, upgrade the code on the devices, this way you won´t have to change much your current implementation.

I will follow up here on Monday with the information just in case nobody has posted a better answer.

Regards.

Jonnathan Rojas