Monday, May 26, 2014

Reverse Route Injection via a Cisco ASA vpn and OSPF

In this post, we will look at  route-injection for ipsec-vpn and the cisco ASA.

The cisco ASA has the means  for route installation upon establishments of a active vpn-tunnel. This is accomplished via the set reverse-route command within our crypto map. This is similar to the cisco legacy vpn concentrator and the Reverse Route Injector.

1st let's look at our topology and the route table & then we will look at  the configurations and controls for route-injecting.

The Topology

ASA crypto map

crypto map EXTERNAL02_map0 10 match address VPN2FGTHQ
crypto map EXTERNAL02_map0 10 set peer
crypto map EXTERNAL02_map0 10 set ikev1 transform-set ESP-AES-128-SHA
crypto map EXTERNAL02_map0 10 set reverse-route   
#<-we add the route injection-command
crypto map EXTERNAL02_map0 interface EXTERNAL02

note: The  command set reverse-route will install the vpn remote-destination into the local route-table

Now in order to push this route into our DYNAMIC routing protocol  ( OSPF ), we will perform some redistribution and controls for this process.

1st  let's build a prefix-list matching only our remote vpn prefixes;

prefix-list myvpnroutes description USE THIS RT-map for controlling insertion of our vpn routes
prefix-list myvpnroutes seq 5 permit

Next, we will build a route-map that calls up our prefix-list. This route-map will be used  in our ospf process and for controlling routes that we populate into ospf.

route-map myvpn_learned_routes permit 10
 match ip address prefix-list myvpnroutes
 set metric 12000
 set metric-type type-1
route-map myvpn_learned_routes deny 100

and within our  ospf process;

router ospf 1
 network area 0
 redistribute static subnets tag 700 route-map myvpn_learned_routes 
  default-information originate metric 1000 metric-type 1

Now within our routing domain, we will have the vpn injected route, we will check on our core-L3 switch;

The prefix is now installed into  OSPF via the redistribution process on our  cisco ASA.

We can also check our ospf-database for confirmation;

 Ken Felix
 Freelance Network & Security Engineer
 kfelix -a--t- socpuppets ---d--o--t--- com

   ^      ^
=( *   * )=
      /  \


  1. Hey Ken,

    I was training a colleague of mine on this, and ran in to your post here. Thought I might just suggest putting in the tunnel as connection type "answer-only" so that the route appears only when the tunnel is up. Without that the route will remain in the routing table regardless of tunnel status.

    Thanks...hope you are doing well.

    Ed Vazquez

    1. Hi Ed,
      Agreed that the answer-only is necessary, at least with static crypto maps, if a dynamic RRI is what you want.

      And if you want your RRI dynamic, you probably need to get DPD keepalives working on both peers so that they actually know when the tunnel is down in a prompt fashion.

      I've just got this running between ASA and Fortigate and I must admit I am surprised by how smoothly it works.

  2. Hi Ed

    Long time, it really depends on what you want and if you want the firewall to be a responder or bidirectional ike negotiations. So you can use the set connection type of answer-only but having the route in the route-table will ensure no traffic for that destination is not leaked out of a "default-route".

    Also with the null routing capabilities of the ASA it's a good practice to install null-route for all VPN ipsec destinations for the same reason.

    ( e.g VPN destination )

    route null0 x.x.x.x x.x.x.x