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 192.169.23.5
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 192.168.254.0/24
!
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
router-id 10.200.21.254
network 10.200.21.0 255.255.255.0 area 0
log-adj-changes
redistribute static subnets tag 700 route-map myvpn_learned_routes #---our-route-map
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 192.168.254.0/24 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
^ ^
=( * * )=
o
/ \
Hey Ken,
ReplyDeleteI 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
Hi Ed,
DeleteAgreed 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.
Hi Ed
ReplyDeleteLong 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
;)