Will make this short and simple. We have an old VPN 3000 that we are replacing with ASA 5515X. We use EIGRP on our internal network. For VPN lan-to-lan traffic we force it out to the VPN 3000 using static routes. The Nexus 7k and VPN3000 have a locally connected network/router-interface/instance.
With new ASA 5515x we enabled EIGRP. The ASA 5515x and Nexus also are directly connected via another local/connected router interface/instance.
I want to be able to "float" tunnels over at the clients discretion to the new ASA5515. My plan to do this is to leverage weighted static route on the Nexus that points to the old VPN concentrator, and have the ASA use reverse-route-injection and redistribute static with EIGRP. The idea is the weighted static will be active, and when the client changes with VPN device to the new ASA, and the tunnel comes up, the ASA will create the static and it will redistribute and the Nexus will see it as a better weighted route and the new EIGRP route via the ASA will superseed the weighted static, and traffic will now flow over the new replacement ASA 5515x.
The problem is as soon as I create a LAN to LAN configuration on the ASA5515x (v8.6) with reverse-route-injection, the ASA creates the static route and it gets redistributed into EIGRP, killing the weighted static. If it does what it's supposed to do, the route for the LAN-to-LAN remote-network should NOT be created on the ASA until the tunnel actually comes up, but this is not what is happening. It is immediately creating a static. I've created just a dummy VPN config with a peer of 22.214.171.124 and remote-network of 126.96.36.199 with reverse-route injection, and as soon as I apply, a static gets created on the ASA and then redistributed to the Nexus 7k.
This has to be a bug right? We had 2900's that had the same problem using reverse route injection, but it was the routes not clearing after the tunnel dropped (the 2900 was terminating IPSEC tunnels for all clients on the local network), and I beleive it was resolved ( I wasn't directly involved in the case).
Regardless, what is happening is the static route is being created on the ASA unconditonally as soon as a VPN peer configuration is commited that uses reverse-route-injection. It should only be creating this static when the tunnel comes up, and it should remove the static when the tunnel drops.
Can someone at cisco confirm that this is a known issue on the ASA 5515X. I am going to put in a TAC case, but always like to get a discussion going with official feedback in forums as I myself use the forums as a resource to confirm behaviour I see before entering a TAC, and to validate behaviour based on other peoples real world issues.
Entered and TAC and pleasantly got a quick response. Of the two options setting a tunnel to answer only is the cleaner and simpler option. I tested and it does only inject the route when the tunnel comes up. While this will work when clients/vendors intiate to access resources on your network (for us luckily this is ~75% of our tunnels), it doesn't address the issue when we are the ones intitiating the traffic to access a clients remote resources.
Hopefully the RFE makes it into a OS release soon, as it it is definately is something I can use now and in the future.
è How to remove the RRI static routes when the VPN tunnel is not up
è By default the RRI static routes are installed irrespective of the status of the VPN. There is an enhancement request raised so as to install the RRI static routes only when the tunnel is up.
è While the work on this is going on, following are the two workarounds that can be implemented to achieve this:
1) Make the local ASA connection type as ‘answer-only’ & remote side must initiate the tunnel always. Following is the link to enable this.
2) The other option is to use the Dynamic crypto maps instead of static crypto maps.
I'm going to try this at the weekend with v9.x code and I would also be interested to know what the progress on the RFE was. I found some documentation about an enhancement being made to the RRI syntax on IOS routers (within the crypto-map), but not the ASA.
Some other bugs/feature enhancements which seem relevant are:
At least in the 9.x version I tested, there was no sign of the Feature Request being implemented - static routes appeared immediately for static crypto maps, regardless of the ikev1 status.
Coupled with the lack of vti support, it's difficult to see these boxes in my environment going forward.
Looks like 9.7 made some improvements on RRI and introduced VTI.