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

[bart.mollemans]

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...

Thanx

[sachinraja]

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 ..

Raj

[suman.daniel]

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.