This post is really for information purposes only as I have fixed the issue with the below solution.
I've recently had an issue setting up a L2L VPN for a client between a Cisco SOHO router using a dynamic external IP running IOS 12.4 and a Cisco ASA5510 running ASA 7.2 and am writing this post as I was unable to find an exact replica of the issue I was having.
The tunnel was forming and there was data passing across the device however when the home worker tried using their VoIP phone, it would cut off and tear down the tunnel. The ASA had replaced a previous device that did not have any issues therefore it seemed the that error was with the ASA.
Running debug on the router returned the following output:
IPSEC(key_engine): request timer fired: count = 1,
(identity) local= 92.156.2.118, remote= 80.194.196.226,
local_proxy= 0.0.0.0/0.0.0.0/1/0 (type=4),
remote_proxy= 0.0.0.0/0.0.0.0/1/0 (type=4)
IPSEC(sa_request): ,
(key eng. msg.) OUTBOUND local= 92.156.2.118, remote= 80.194.196.226,
local_proxy= 0.0.0.0/0.0.0.0/1/0 (type=4),
remote_proxy= 0.0.0.0/0.0.0.0/1/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac (Tunnel),
lifedur= 3600s and 4608000kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
and from the ASA:
[IKEv1]: Group = DefaultL2LGroup, IP = 83.71.191.89, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/1/0 local proxy 0.0.0.0/0.0.0.0/1/0 on interface outside
The cause of the problem turned out to be related to the homeworker router configuration.
Within the VPN encryption domain configuration was the statement:
access-list 100 permit icmp any any
ANY = 0.0.0.0/0 when it comes to encryption domains within the context of a VPN tunnel configuration.
As the home worker VPN configuration uses a dynamic_crypto_map on the ASA (due to the home worker having a dynamic external IP assigned by the ISP) there is no matching policy for 0.0.0.0/0 causing the ASA to delete the tunnel and remove the peer from it's ISAKMP SA table (were as the previous device simply ignored it and left the ISAKMP / IPSEC SA up for the other tunnels to the same peer)
The remedy in my case was to simply define the ICMP traffic more tightly, therefore negating the any (0.0.0.0/0) domain being used
access-list 100 permit icmp 10.1.1.0 0.0.0.15 10.0.0.0 0.255.255.255
I hope this can help anyone getting the above error.
