11-04-2013 05:19 AM
Hello,
I am pretty much wondering under what circumstances an ASA installs static routes due to the "set reverse-route" command in a static crypto map.
We have several tunnels where the route is not installed, whereas others appear. It seems that the route only appears if the local side of the tunnel
is directly connected.
So my questions are:
a) does the local side need to be directly connected
b) is it sufficient to habe the local side in the local routing table
c) does the local side not matter at all
Thanks for your help!
Cheers,
Heri
Solved! Go to Solution.
11-04-2013 10:02 AM
Seems that this was a bug in the ASA OS - filed under bug id
CSCui48221 (see https://tools.cisco.com/bugsearch/bug/CSCui48221)
11-04-2013 10:07 AM
Hi,
Thank you for the update.
I tried to look for any situation where the behaviour you see could happen normally but couldnt find one (or think of one even).
- Jouni
11-04-2013 05:24 AM
Hi,
I am not sure if the RRI / Reverse Route Injection has anything to do with the local/source network of the VPN connection.
The times I have used it I have had no problem having the ASA add the route for the remote network to the routing table. To my understanding this Static Route should be added even if the L2L VPN in question is not up.
In the case of VPN Client connection I think the ASA automatically adds a Static Route for the VPN Client IP address to the local routing table BUT it will need RRI / Reverse Route Injection enabled for the ASA to pass that route to some dynamic routing protocol.
Last time I tested this on my test ASA for someone here in CSC the route was installed just fine and my source network was not directly connected. To my understanding it should not have any effect on whether the route is installed or not.
Naturally you could share some configurations and "show route" outputs of the connection where you have the problem and some outputs where its working.
I think most of the time I have not had any need for RRI / Reverse Route Injection as we rarely run any Dynamic Routing Protocol on our ASAs and the default route already present on the ASA usually handles forwarding traffic to the remote VPN networks just fine.
- Jouni
11-04-2013 08:11 AM
Jouni,
thanks for your reply. Running 9.0(2), it seems that the static route is only set while the tunnel is up and running and removed if the tunnel goes down. At least this is the behaviour I expected.
For the configuration, there is absolutely no difference between the two crypto map entries that work and that dont. Both tunnels are up and running but just one remote proxy is installed into the routing table - for whatever reason!
Btw: there are no static routes installed on this ASA.
This is the entry of a working tunnel:
crypto map CMAP_EXTERNAL 30 match address CMAP_HERI_MATCH
crypto map CMAP_EXTERNAL 30 set pfs
crypto map CMAP_EXTERNAL 30 set connection-type answer-only
crypto map CMAP_EXTERNAL 30 set peer VPN_PEER_HERI
crypto map CMAP_EXTERNAL 30 set ikev1 transform-set ESP-AES256-SHA
crypto map CMAP_EXTERNAL 30 set security-association lifetime seconds 3600
crypto map CMAP_EXTERNAL 30 set reverse-route
access-list CMAP_HERI_MATCH line 1 extended permit ip host 192.168.36.203 host 192.168.107.9
The routing table shows the following:
asa1# sh route | include ^S
S 192.168.107.9 255.255.255.255 [1/0] via A.B.C.D, external
asa1#
This is a tunnel entry that does not place any static routes into the routing table:
crypto map CMAP_EXTERNAL 45 match address CMAP_AXX_MATCH
crypto map CMAP_EXTERNAL 45 set pfs group5
crypto map CMAP_EXTERNAL 45 set peer VPN_AXX_INFORENT
crypto map CMAP_EXTERNAL 45 set ikev1 transform-set ESP-AES256-SHA
crypto map CMAP_EXTERNAL 45 set security-association lifetime seconds 28800
crypto map CMAP_EXTERNAL 45 set security-association lifetime kilobytes 4608000
crypto map CMAP_EXTERNAL 45 set reverse-route
access-list CMAP_AXX_MATCH line 1 extended permit ip 192.168.36.0 255.255.255.128 192.168.204.16 255.255.255.240
As you can see in aboves output, only the host 192.168.107.9 was installed - for whatever reason. Both tunnels were up and running at this time.
11-04-2013 10:02 AM
Seems that this was a bug in the ASA OS - filed under bug id
CSCui48221 (see https://tools.cisco.com/bugsearch/bug/CSCui48221)
11-04-2013 10:07 AM
Hi,
Thank you for the update.
I tried to look for any situation where the behaviour you see could happen normally but couldnt find one (or think of one even).
- Jouni
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide