Unable to build 2 different VPN tunnels terminated on same Remote Peer

[cannan.ilangovan]

Hi Experts,

I have a peculiar problem. the scenario is this. I am building two different VPN tunnels from two different Accenture Locations to my client's network. Both the VPN Tunnels are terminated in the same ASA 5520 at the Client end. The source and destination are the same via both the tunnels.

below is the example schematic...note the IP addresses are cooked up here...for valid reasons...!!! :-)

Tunnel 1

My peer IP: 192.168.1.100

Remote Peer: 172.16.10.1

Local Network: 10.1.1.0/24

Remote Network: 172.16.100.2/32

Tunnel 2

My Peer IP: 172.18.19.1

Remote Peer IP: 172.16.10.1

Local Network: 10.1.1.0/24

Remote Network: 172.16.100.2/32

I know that we cannot achieve this...i mean have both the tunnels active at the same time since the Remote End will have trouble sending back the traffic eventually breaking either one of the tunnel, most likely the second tunnel that comes up...

what I am looking to understand is that, if i clear the crypto sessions of the tunnel that is active and try to bring up the other tunnel, it never comes up. although the IKE sessions come up fine, the IPSec sessions reports errors and eventually breaks the IKE sessions too...interestingly at the Far end, there we no IKE/IPSec sessions that were active when the first tunnel came up...so theoretically this should bring up the second tunnel...but it is not happening...any help/explanation as to why this is not happening will be really appreciated...

thanks in advance for your time.

[#2]

If the IPsec VPN tunnnel has failed within the IKE negotiation, the failure can be due to either the PIX or the inability of its peer to recognize the identity of its peer.When two peers use IKE to establish IPsec security associations, each peer sends its ISAKMP identity to the remote peer. It sends either its IP address or host name dependent upon how each has its ISAKMP identity set. By default, the ISAKMP identity of the PIX Firewall unit is set to the IP address. As a general rule, set the security appliance and the identities of its peers in the same way to avoid an IKE negotiation failure.

In order to set the Phase 2 ID to be sent to the peer, use the isakmp identity command in global configuration mode

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml#idenity