IPsec VPN re-keying sometimes fails between ASA5525 and Meraki MX68

[Tats0611]

Hello,

I am having this issue that Ipsec VPN re-keying between ASA5525 and MX68 sometimes fails.

This issue happens about once a week.

workaround for the issue is clearing ikev1 sa and ipsec sa but I would like to know the root cause of this issue.

I read this somewhere that lifetime of ike tunnel should always be greater than lifetime of ipsec tunnel (although I could not find the reason of this practice.)

My current config is not following this practice. means phase 1 and phase 2 have the same lifetime at this moment.

Could this config cause this re-key issue?

I see these logs on ASA side:

Removing peer from correlator table failed, no match!

All IPSec SA proposals found unacceptable!

I see these logs on Meraki:

Jun 5 12:48:21 Non-Meraki / Client VPN negotiation msg: no proposal chosen.
Jun 5 12:48:21 Non-Meraki / Client VPN negotiation msg: no suitable policy found.
Jun 5 12:48:21 Non-Meraki / Client VPN negotiation msg: not matched
Jun 5 12:48:21 Non-Meraki / Client VPN negotiation msg: encmode mismatched: my:Tunnel peer:UDP-Tunnel
Jun 5 12:48:20 Non-Meraki / Client VPN negotiation msg: notification NO-PROPOSAL-CHOSEN received in informational exchange.
Jun 5 12:48:20 Non-Meraki / Client VPN negotiation msg: initiate new phase 2 negotiation:xxx
Jun 5 12:48:20 Non-Meraki / Client VPN negotiation msg: purged IPsec-SA proto_id=ESP spi=2758757436.
Jun 5 12:48:20 Non-Meraki / Client VPN negotiation msg: IPsec-SA expired: ESP/Tunnel xxx
Jun 5 12:48:18 Non-Meraki / Client VPN negotiation msg: notification NO-PROPOSAL-CHOSEN received in informational exchange.
Jun 5 12:48:18 Non-Meraki / Client VPN negotiation msg: initiate new phase 2 negotiation: 61.xxx
Jun 5 12:48:16 xxx 802.11 disassociation unknown reason
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: failed to pre-process ph2 packet (side: 1, status: 1).
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: no proposal chosen.
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: no suitable policy found.
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: not matched

[Mano11]

Hi Tats, 

i'm currently facing the same issues as well. I went through a forum and noticed that disabling the NAT-T on the back-end of the Meraki should resolved this issue. 

https://community.meraki.com/t5/Security-SD-WAN/Third-party-site-to-site-vpn-failing-recovering-at-random/td-p/42292

I'm gonna try and will let you know the outcome. Did you managed to get this resolved. 

[Mohammad Alhyari]

Dears,

first for the message you are getting;

Jun 5 12:48:18 Non-Meraki / Client VPN negotiation msg: notification NO-PROPOSAL-CHOSEN received in informational exchange.
Jun 5 12:48:18 Non-Meraki / Client VPN negotiation msg: initiate new phase 2 negotiation: 61.xxx
Jun 5 12:48:16 xxx 802.11 disassociation unknown reason
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: failed to pre-process ph2 packet (side: 1, status: 1).
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: no proposal chosen.
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: no suitable policy found.
Jun 5 12:48:16 Non-Meraki / Client VPN negotiation msg: not matched

it means phase 2 failed on the remote peer and they sent the notification message no proposal chosen. these settings are related to phase 2 and are :

transform set including encryption and hash 

the proxies used for encryption which is the acl 

the mode of the encapsulation [tunnel/transport/udp/nat-t]

What happens when you rekey is that the it can be initiated from any of the two sides. which is why it works sometimes and not the other time. look for the settings closely on both sides and the debugs on the Juniper side see why they are rejecting phase 2 proposals from Meraki.

for your concern about the lifetime. phase 1 is like a protection suite for phase 2. it makes sense keep the lifetime for that tunnel longer than the data tunnel. so under the same phase security association you can rekey multiple phase 2 associations. 

[JoseRolandoTorresBello1522]

I had the same problem I fixed change the CIDR.

Verify the Mask.