ASA 5545 Lists L2L IKE Peer Twice

[iglablues]

I have a site-to-site VPN set up between an ASA 5545 and a Meraki MX84. It has been a little unreliable to say the least. At any rate, today the tunnel went down and I tried resetting the peer connection from the ASA, something that has worked in the past. It did not work this time, and ultimately we had to reboot the Meraki to get the connection to re-establish. Afterwards I went through and did some basic things that I've seen suggested online such as disabling DPD on the ASA. I have not disable aggressive mode even though the documentation suggests it because a) our remote clients require it, and b) the setting in the crypto-map specifies main mode for phase 1 so I don't think aggressive mode is getting used anyway (could be wrong there). 

Anyway, when I run sh crypto isakmp sa detail I see 2 entries for the Meraki peer, both L2L, but one shows the ASA as the initiator and the other shows it as the responder: 

2 IKE Peer: x.x.x.x 
Type : L2L
Role : responder
Rekey : no
State : MM_ACTIVE
Encrypt : 3des
Hash : SHA
Auth : preshared
Lifetime: 86400
Lifetime Remaining: 64427

3 IKE Peer: x.x.x.x 
Type : L2L
Role : initiator
Rekey : no
State : MM_ACTIVE
Encrypt : 3des
Hash : SHA
Auth : preshared
Lifetime: 86400
Lifetime Remaining: 64433

I am confused as to how this even happened, and how I can fix it. It's not causing an issue right now as far as I can tell, but I worry that when the rekeying happens this will blow up. 

[Rahul Govindan]

This would have happened because both tried to initiate the tunnel at around the same time - this is evident in close lifetime remaining on both. This is really not an issue in most cases as during rekey, there is always a random jitter value added to the time to rekey. So the ASA and meraki should not initiate the rekey at the same time. This should result in only one rekey to be initiated and the other one to expire as the lifetime expires.

Also check how many Phase 2 SA's are created on the ASA. Even though there are 2 IKE SA's, there should be only one IPsec SA. Having more than one of those has a bigger impact than the IKE SA.

[iglablues]

Thank you for your response. I came in this morning and checked the status of the tunnel again (using the ASDM this time) and found some very confusing output. (Note: I was also just told that someone power cycled the Meraki again this morning because the tunnel was down again when they came in)

This is one of the two established tunnels. It's using IPSec for the Phase 2 tunnel. 

This is the second of the two established tunnels. It's using IPSecOverNatT (which is something I don't believe we ever explicitly set up)

There's one VPN tunnel config. Here are the details from the ASA:

show run crypto ikev1
crypto ikev1 enable outside
crypto ikev1 policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

show run all crypto map
crypto map outside_map 1 set pfs group2
crypto map outside_map 1 set connection-type bi-directional
crypto map outside_map 1 set ikev1 phase1-mode main
crypto map outside_map 1 set ikev1 transform-set first_transform ESP-AES-256-SHA
no crypto map outside_map 1 set tfc-packets
crypto map outside_map 2 match address outside_cryptomap
crypto map outside_map 2 set connection-type bi-directional
crypto map outside_map 2 set peer x.x.x.x
crypto map outside_map 2 set ikev1 phase1-mode main
crypto map outside_map 2 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 2 set security-association lifetime seconds 79200
crypto map outside_map 2 set security-association lifetime kilobytes unlimited
no crypto map outside_map 2 set tfc-packets
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside

sh run all tunnel-group x.x.x.x
tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x general-attributes
no accounting-server-group
default-group-policy GroupPolicy_x.x.x.x
tunnel-group x.x.x.x ipsec-attributes
ikev1 pre-shared-key *****
peer-id-validate req
no chain
no ikev1 trust-point
isakmp keepalive disable
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

I can understand what you've said above about the establishing of two tunnels when one of the ends gets restarted, but can you help me understand how one set of traffic is being sent over one of the tunnels and another set of traffic is being sent over another? If I kill one of the tunnels from the ASA, will the other traffic move over to the remaining tunnel? 

[iglablues]

I think I've gotten a better handle on this. I see that NAT-T is enabled on the ASA, and I believe on the Meraki as well. If I understand how this works, the devices figure out for themselves if the other end of their traffic is behind a NAT device and uses NAT-T or plain IPSec with ESP automatically. That doesn't explain, to me at least, why there was different Phase 2 settings for the two tunnels despite all of the traffic being between the same two devices, but as of now the tunnel running native IPSec/ESP is gone and I am now left with one tunnel again. 

I still wonder, if two tunnels show up again as the result of someone power cycling the Meraki, what would happen if I killed one of the two tunnels? Would all traffic then move to the remaining tunnel? 

[Rahul Govindan]

One possibility is that one of your phase 2 tunnels is matching the crypto static map while the other is matching the dynamic map.  Can you paste the "show crypto ipsec sa" output from the ASA Cli when both tunnels are up?

[#6]

Did you ever figure out a solution to this? I'm currently experiencing same issue with a Meraki Z1 and ASA 5510. The second tunnel shows up every time lifetime expires. Traffic becomes one-way and I have to kill the original tunnel. Then the second tunnel comes up as IPSecOverNatT and two way traffic resumes.