Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Pix 2 pix vpn: multiple peers in 1 crypto-map sequence...

Dear all,

I'm gooing NUTS! Let me elaborate on why:

We have 3 head-offices call them A, B and C. These are linked to each other via High BW leased lines. The smaller remote sites are connected to the main sites via internet-vpn. Now the problem is that we have crypto maps set-up like this:

crypto ipsec transform-set EXAMPLEset esp-des esp-sha-hmac

crypto map EXAMPLEmap 10 ipsec-isakmp

crypto map EXAMPLEmap 10 match address HQACL

crypto map EXAMPLEmap 10 set peer ADRESS.OF.HQ.A

crypto map EXAMPLEmap 10 set peer ADRESS.OF.HQ.B

crypto map EXAMPLEmap 10 set peer ADRESS.OF.HQ.C

crypto map EXAMPLEmap 10 set transform-set EXAMPLEset

crypto map EXAMPLEmap 10 set security-association lifetime seconds 3600 kilobytes 4608000

And the peer that get's the tunnel is not allways the one I'd expect; nl the first in row. The tunnel also swaps peer at intermittant intervals. which cause havoc on the HQ-nework. Any sugestions are welcome...



Re: Pix 2 pix vpn: multiple peers in 1 crypto-map sequence...

Are the source and destination IPs same for all the HQ connections ??? I could see a single HQACL being applied for all the three connections.... In these cases, the peer given first (HQ A) will have the site to site tunnel created, when an interesting packet is triggered from the HQACL.... when this isnt reachable, it creates a tunnel on the second peer HQ B.... This is the way it should happen...

Let us know your IP addressing schemes ..


New Member

Re: Pix 2 pix vpn: multiple peers in 1 crypto-map sequence...

Since you said, all three HQ sites are connected using high bandwidth lines, I assumed the acl has the IPs of all three sites in it as destinations.... As of the peers, its goes in order of config....It goes to the next one if the previous peer is not reachable at the time of negotiation. So, when an SA is about to expire and triggers a renegotiation, I guess the Primary peer is momentarily not available which prompts the use of second peer and so on. That's the only logincal explanation for what you are seeing.

CreatePlease login to create content