vpn tunnel establishing

[Benjamin Saito]

I have a strange issue. Customer had 2 peer IP's configured in a tunnel:

crypto map outside_map 1 set peer 1.1.1.1 2.2.2.2

The tunnel would establish fine to 1.1.1.1 but then it would eventually get torn down for this reason:

"Peer Address Changed"

Then 2.2.2.2 would come up as the active peer. I couldn't figure out why this was happening so I just removed 2.2.2.2 from the crypto map and the tunnel was working fine after that. But I kept logs running on the syslog server and saw that the tunnel to 2.2.2.2 was establishing still even though it was completely removed from the crypto map. "Show crypto ipsec sa peer 2.2.2.2"shows it is actually establishing an SA. I even reset that tunnel via ASDM and it just keeps coming back up. Anyone know what the cause of this could be? This is a 5510 on code version 8.0(5).

[Octavian Szolga]

Hi Benjamin,

The point of having 2 IPs in the same statement is for redundancy. Basically, your tunnel endpoint has 2 WAN/Internet interfaces that you can use to establish your IPsec. If the first one becomes unavailable, the second one will be used.

Regarding the peer removal that you did, have you also deleted the tunnel-group section for the 2nd IP?
Also, just to make sure that your change is correctly applied, just remove the crypto map from the interface and add it again (warning: your sessions will be torn down..)

Thanks,

Octavian

[Benjamin Saito]

Hi Octavian,

Thanks for the reply!  I didn't remove the tunnel-group because if there are ever issues with the current peer IP then we will manually need to add in the secondary peer IP. But having the tunnel-group configured still shouldn't allow the tunnel to establish without the "2.2.2.2" being configured on the crypto map, correct? We have several tunnels set up like this on many ASA's and this is the only time I have ever seen both peer's become active on an ASA. When you configure a crypto map with 2 different peers only 1 should be active at a time. Not both.

[Florin Barhala]

I agree with your logic here! What I would do is add IP SLA for the 1st IP and review the results.
Also you could log any IP SLA flap and add back 2.2.2.2. Then you could compare logs and see if any related flap from 1.1.1.1 actually triggers a VPN failover to 2.2.2.2