vpn tunnel not working from one end

[Benjamin Saito]

Hello,

I have an ASA 5510 and I am building a site-to-site vpn tunnel, peer on the other end is a sonicwall. I can initiate the tunnel from my end, but when he tries from his end it fails on phase 2 with this error in the logs:

"Rejecting IPSec tunnel: no matching crypto map entry for remote proxy"

Obviously our crypto map's don't match, i have it restricted to specific ports on my end and he had it wide open on his end, but said he is not sure how to restrict it down to specific ports. My question is why would I be able to bring the tunnel up on my end if the crypto map's don't match and he can't bring it up?

Thanks!

[Jouni Forss]

Hi,

I very rarely run into such a problem.

On the ASA Firewalls there is possibility to configure the L2L VPN connection to be initiator or responder only. (Typically it works both ways) I wonder if something similiar has been configured on the remote device? I dont know what kind of error message that situation produces.

Could we see your current ASA configurations?

- Jouni

[Aref Alsouqi]

Is it possible that SonicWall has more than one crypto map, so when he recieves tunnel negotiations he uses one, and when he initiates tunnel use another?

Sent from Cisco Technical Support iPhone App

[Benjamin Saito]

I can't get my hands on the sonicwall so this is making it difficult to troubleshoot, but he says he does not know of any setting that would only allow him to be the intiator or the responder. I have it set up to NAT exempt the internal IP's on my end, I am having him check to see if he has any other tunnels that uses the same internal ip address range that we use. Here's the config I have on my end:

access-list outside_cryptomap_1 extended permit tcp object-group Samaritan_local_hosts object-group Samaritan_remote_hosts range 12000 12005

crypto map outside_map 7 match address outside_cryptomap_1

crypto map outside_map 7 set peer x.x.x.x

crypto map outside_map 7 set ikev1 transform-set ESP-3DES-SHA

crypto map outside_map 7 set nat-t-disable

nat (inside,outside) source static Samaritan_local_hosts Samaritan_local_hosts destination static Samaritan_remote_hosts Samaritan_remote_hosts no-proxy-arp route-lookup

tunnel-group x.x.x.x type ipsec-l2l

tunnel-group x.x.x.x general-attributes

default-group-policy GroupPolicy_x.x.x.x

tunnel-group x.x.x.x ipsec-attributes

ikev1 pre-shared-key *********

I forgot to mention that when I open the tunnel up for full ip access, either one of us can bring up the tunnel, the problem is when i restric the traffic in the tunnel.

Thanks for your replies!

[Jouni Forss · Accepted solution]

Hi,

I would suggest if the ACL with the TCP and ports is causing problems that you stick to "permit ip" statements and configure a VPN Filter ACl on this L2L VPN connection to get around the problem.

In this case I think the main problem is that the remote end is unable to configure the mirrored rules using specific TCP ports. I personally consider using TCP/UDP ports in the cryptomap ACL something that I rather not do. If you want to control traffic its good to use interface ACL or VPN Filter ACL (The interface ACL use requires you to change a global setting which is a rather problematic situation if you have several existing VPN connections, both Client and L2L VPN on the device)

- Jouni

[Benjamin Saito]

Thanks for the responses. I haven't been able to figure this one out, it's difficult when I can't get access to the sonicwall on the other end. But I am going to go ahead and disable the global setting and filter via acl instead of the crypto map, as jouni recommended. Thanks for the help.