This document describes issues with RRI and recursive routelookups in certain IOS codes
In normal site-to-site VPN deployments, we usually create a static/default route to define the exit path for traffic which is part of the encryption domain. This forces the interesting traffic to exit from the interface on which the crypto map is defined thus either initiating the IKE exchange or causing the the packet to get encrypted using an existing Security Association(SA). In some scenarios however, like when one(or both) side of a VPN tunnel is doing HSRP or using other such HA protocols, sometimes static routes cannot be used to define exit paths for the remote network. Instead in these cases we need to rely on a mechanism called Reverse Route Injection to inject routes into our routing table for the remote networks However, since IOS v15.0(1)M, there is a change in behavior in RRI when "reverse-route" is configured and when the crypto map is applied to a multi-access interface (eg., ethernet). For this configuration to work, the router will try to arp for the crypto peer address to populate the CEF adjacency for the remote protected network. As a result, if the upstream router does not have proxy arp enabled (very common in provider environment), then arp will fail and the egress traffic toward the peer will be dropped due to incomplete CEF adjacency.
The symptoms can be observed with debug arp and show adj output:
*Apr 23 15:46:11.627: IP ARP: creating incomplete entry for IP address: 126.96.36.199 interface Ethernet0/0
*Apr 23 15:46:11.627: IP ARP: sent req src 10.1.1.1 aabb.cc01.1800,dst 188.8.131.52 0000.0000.0000 Ethernet0/0
*Apr 23 15:46:13.471: IP ARP: creating incomplete entry for IP address: 184.108.40.206 interface Ethernet1/0
Protocol Interface Address
IP Ethernet0/0 10.1.1.2(11)
IP Ethernet0/0 220.127.116.11(5) (incomplete)
IP Ethernet1/0 18.104.22.168(7)
In order to fix this issue, one can use the gateway option while enabling reverse-route injection. This can be done using the optional remote-peer keyword. When this keyword is used, it indicates two routes: one for the tunnel endpoint, with the next hop being the interface to which the crypto map is bound. If it is used with the optional ip-address argument, then the next hop is determined by the user-added value for the ip-address argument.
The static keyword at the end can be used to make the routes persistent. In some cases, e.g. cases where there is no default gateway defined or the default gateway uses an interface which does not have the correct crypto-map enabled , using this keyword is necessary so that even when the tunnel is not up, the router is aware of how to reach the remote protected network. Otherwise, the router will never be able to initiate the tunnel, even though once the tunnel is up the router will be capable of routing traffic.
Hardware: ASA 5510Version: 9.1(7)25AnyConnect File: anyconnect-win-4.7.01076-webdeploy-k9.pkg I've read many posts and watched multiple videos but for some reason I cannot get the web deploy page to show up that allows a user to authenticate and then...
Hi guys, I need up-to-date info about ASAs.I am seriously considering replacing a physical Fortinet firewall that is using multiple VDOMs.I have used 55xx ASAsa few years ago, and I remember using contexts which from memory were the equivalent to VDO...
Currently we have a web portal called BASE-Q , Which is hosted on AWS and out public ip is whitelisted on AWS so anyone can access it from their browser. As of now the users that require BASE-Q from home are remoting on to a RDS server so they ...
We recently started moving our devices back to TACACS authentication from RADIUS. We had this on ACS, but when we migrated to ISE it only supported RADIUS at the time. Now that we can do authorization sets again, I am curious as to what command sets you c...