Why is my L2L tunnel using RA tunnel settings?

[professorguy]

I am trying to add another L2L tunnel to the many we already have working correctly. The settings for this tunnel are identical to the settings for all our other L2L tunnels, but I get this from a 'show isakmp sa detail' during an attempted telnet:

...
6 IKE Peer: 208.x.y.33
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : 3des Hash : MD5
Auth : preshared Lifetime : 86400
7 IKE Peer: 208.w.z.227
Type : user Role : initiator
Rekey : no State : MM_WAIT_MSG2
Encrypt : aes-256 Hash : SHA
Auth : preshared Lifetime : 0
...

The first one works, the second one with the wrong type and weird encryption/hash settings doesn't. However, looking at the running configuration, THERE ARE NO SETTING DIFFERENCES BETWEEN THESE TWO TUNNELS! Here's some highlights:

-----------
crypto map vpn_map 50 match address vpnVRC
crypto map vpn_map 50 set peer 208.x.y.33
crypto map vpn_map 50 set transform-set ESP-3DES-MD5
...
crypto map vpn_map 90 match address vpnMedHost
crypto map vpn_map 90 set peer 208.w.z.227
crypto map vpn_map 90 set transform-set ESP-3DES-MD5
-----------
access-list vpnVRC extended permit ip object-group PACS-Local object-group VRC-Remote
...
access-list vpnMedHost extended permit ip object-group MedHost-Local object-group MedHost-Remote
-----------
tunnel-group 208.x.y.33 type ipsec-l2l
tunnel-group 208.x.y.33 ipsec-attributes
pre-shared-key *
...
tunnel-group 208.w.z.227 type ipsec-l2l
tunnel-group 208.w.z.227 ipsec-attributes
pre-shared-key *
-----------
access-list acl_nonat extended permit ip object-group PACS-Local object-group VRC-Remote
...
access-list acl_nonat extended permit ip object-group MedHost-Local object-group MedHost-Remote
-----------

Anyone have any ideas as to why it is trying (and failing) to establish a USER tunnel instead of an L2L tunnel? It says type ipsec-l2l right in the tunnel-group! And why is it using the aes-256/sha settings when the crypto map specifies a transform set using 3des/md5?

Thanks in advance for any insight.

 

[brianinms]

What is the end device trying to initiate the L2L?

 

[professorguy]

The tunnel is being established between our Cisco ASA 5520 and their Cisco PIX 525. In the case above it is our ASA which is trying to establish the tunnel (notice the 'initiator' in the isakmp output). It tries (and fails) to come up when I try to hit their hosts from the servers here.

 

[brianinms]

Make sure they have it configured for no-xauth



isakmp key ******** address 0.0.0.0 netmask 0.0.0.0 no-xauth

 

[professorguy]

Here's what the cisco site says:

"If a LAN-to-LAN tunnel and a Remote Access VPN tunnel are configured on the same crypto map, the LAN-to-LAN peer is prompted for XAUTH information, and the LAN-to-LAN tunnel fails.

"Note: This issue only applies to Cisco IOS and PIX 6.x. Because it uses tunnel-groups, PIX/ASA 7.x is not affected by this issue."

Obviously I'm using tunnel-groups here (see the excerpts above) so this doesn't seem it could be the problem.

 

[brianinms]

Their pix 525 is running 7.0 code as well?

 

[professorguy]

I just assumed because they have successful L2L tunnels to many, many client sites they have a configuration that works correctly. If they are prompting for xauth, I can't see how any L2L tunnel will work for them. If it's my side incorrectly prompting, then I need to cut that out.

 

[brianinms]

You are correct, I didn't realize both the Pix and ASA are running 7.0 code so that xuath isnt an issue. Are you sure the access-lists for the crypto map are identical on both sides? I assume you have also tried changing the key.

 

[NetworkGhost]

Are there any other crypto map entries besides
crypto map vpn_map 50 and 90?

Free Firewall/Network/Systems Support-

http://firewalls.ath.cx

 

[professorguy]

Yes, there are. They all use the same transform-set (ESP-3DES-MD5) and each have their own ACL for match addresses. Some of these are simple (one host to one host) while some are quite complicated (many hosts to many hosts in various combinations). And the peers are specific to those tunnels.

Also, the other tunnels work fine. I'm now certain this is a configuration problem on the vendor's side. I base that on the fact that the VPN Engineer I started setting this up with is now gone from the vendor's employ. So he may have been a chimp.