ASA 5510 - L2L VPN reverse-route admin distance

[Jasonch518_2]

Hello,

Is there any way to change the administrative distance on the reverse-route feature of VPN tunnels? When using reverse-route it installs it as static, which gives it an admin distance of 1 it seems, so makes it very hard to use that as a backup route, when I have a static route pointing to a connected interface on the ASA, which I would like to be primary.

If you do not use reverse route, would a static route take preference?

I guess I would need to use some type of tracking so that if the interface that the static route was pointing to was unavailable, it would pull it out, and than the vpn tunnel would be used.

The connected interface on the ASA goes to a Ethernet leased lined service. I thought of moving the VPN tunnel off of the ASA, and onto some other device, and then I could just have 2 static routes on the ASA, with different admin distances, but was hoping there was a better way.

Thanks for any advice.

[Collin Clark]

You can use a route map, match on the remote network(s), and set the metric.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00809d07de.shtml

Hope that helps.

[Jasonch518_2]

Collin,

Thanks for the link, but I am not running any routing protocols currently, because there is no need, so I do not think that this will help.

The routing protocol would work, if the VPN and the leased line were terminating on different devices, but they both terminate on the firewall.

[Collin Clark]

Why use RRI then? Why not add a static route in the hub site and increase the AD?

[Jasonch518_2]

The remote site has a dedicated link back to the hub site, as well as a backup internet connection out there, for the vpn tunnel back to the hub site, and I need the dedicated link to be preferred. Maybe I am not understanding what you mean, but if I was to add a static route pointing to the remote subnet, and the next hop is a connected interface, and also turn up the VPN tunnel, what stops the traffic from going over the VPN tunnel, would it always prefer to use the static route?

If that is the case, then it should not be an issue, and I would just need to implement tracking on that static route, to remove it if the next hop was unavailable.

I was unaware if it worked that way. If that is the case, I should be fine.

[Collin Clark]

Maybe you could put a quick diagram together? Also check this link and see if this would work for you. Granted this is for a backup internet connection, but it could also be set for a specific route.

https://packetpros.com/cisco_kb/IP_SLA.html

[Jasonch518_2]

Collin,

Sorry for the delay getting back to you.

I have attached a quick diagram.

Currently the VPN tunnel in the diagram is the only connection between the 10.10.30.0/24 network and the 172.16.10.0/24 network. We are adding the Ethernet WAN connection, and want that to be primary, but in the event of that going down, we have the Internet access line at the remote site, and would like that VPN tunnel to kick in as a backup.

I am not sure of how the ASA treats a static route (pointing to the Ethernet WAN connection) vs the crypto map ACL's, when RRI is not used, which is fine to turn off, if that would make the static route higher priority. At that point, I could use the IP SLA functionality that you linked to remove the static route, if that link were to be down.

Thanks for the help.

[Collin Clark]

Thanks for the diagram, it really helps. Your best option is to use backup interface. Here's a link on it. Check it out and let me know if it's feasible or not.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806e880b.shtml

BTW: The routes injected via RRI are set to admin distance of 1. You could change them with a route map, but that would not help in the dynamic fail over.

[Jasonch518_2]

Collin,

Got everything working, by turning off RRI, so that the static is primary, and used the SLA monitor to remove the static if the WAN link is down.

Failover works well, thanks for the help.

[Collin Clark]

Cool, good to hear.