Non-Meraki VPN - IKEv2 issues (?)

RaphaelL
Kind of a big deal
Kind of a big deal

Non-Meraki VPN - IKEv2 issues (?)

Hi ,

 

I would like to start off by stating that I'm a complete noob when it comes to VPN , IPSEC , SA , IKEv2 and all that stuff.

 

 

We have a simple setup. One MX peering to a Palo Alto. 

 

RaphaelL_0-1724254869318.png

 

Phase 1 works fine and Phase 2 works fine.... most of the time. 

 

As you can see ( even if it's blured ) there are like 10 subnets configured. 

 

When we establish the tunnel , ALL 10 subnets are working fine. After couple hours ( something like 6-24 hours ). Some of the subnets stop working. 

 

I can see the log on the MX that : msg: <remote-peer-2|13> closing CHILD_SA net-2{42} with SPIs cccdb01e(inbound) (54640 bytes) 9812d7e5(outbound) (144750 bytes) and TS XXXXXXXX/28 === XX.XX.15.0/24

 

However when ever I try to bring the SA up by sending traffic to .15.0/24 it doesn't. Either I have to bring to whole tunnel down and up OR I can bring it up by sending traffic from the Palo-Alto side. 

 

I have confirmed that the timers of Phase 1 and 2 are matching on both sides ( 28800s and 3600s )

 

I'm running MX18.211.3 and I have a case open.

 

I have read the multiple posts here and many of the documentation pages but I couldn't find anything except : https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#NOTE_For_IKEv2

 

 

Any troubleshooting ideas ?

 


Cheers , 

9 Replies 9
KarstenI
Kind of a big deal
Kind of a big deal

The Link you posted and here with some more details:

https://documentation.meraki.com/MX/Site-to-site_VPN/IKEv1_and_IKEv2_for_non-Meraki_VPN_Peers_Compar...

 

The IKEv2 implementation of the MX is different to approx. 90% of commercial firewalls out there.  It's a shame that the MX team doesn't care. Or they care in a way that they hope customers move the peer to AutoVPN. Sadly, for me, some customers moved entirely away from the Meraki Fullstack because of MX limitations.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
RaphaelL
Kind of a big deal
Kind of a big deal

That's sad. I just hope that Support is going to tell me right away that this is not working instead of me wasting hours trying to tshoot that. 

 

I didn't design that. Our Extranet is built with Palo Alto and I can't easily put a MX HUB. That would solve all my issues in an instant , but not possible atm.

AgungTP
Here to help

hmm, I'm having the same issue here.. I need to reset the tunnel from the other side (the initiator) to make it works, re-enable the VPN tunnel or restart MX didn't help at all

CJHarms
Here to help

We seem to have exactly the same Problem. I also have a Case open (12167713) but no Fix/Workaround so far.

 

We remove and re-add the Network Tag on the affected Site-to-Site VPN Peer to get it going again for 24-48hrs.

AgungTP
Here to help

well, I have decided to use IKEv1 instead of IKEv2, I have no choice currently, its running stable so far (at least for the last 2 weeks)

CJHarms
Here to help

We might also need to go back to IKEv1. In the new MX19.x Firmware i can see a lot of Bugfixes regarding Third Party VPNs - I hope the Fixes get backported to the MX18.x Firmware so I can try if a new 18.x Firmware fixes the IKEv2 Problems.

wes808
New here

What utter garbage.  Years and Meraki still can't get this right.  And we don't even have an actual non-meraki peer on the other end of our tunnels anymore - it's all meraki!  Simply merakis from different orgs.  And still their ikev2 implementation is trash that dies constantly.  Pretty pathetic.

rsage_voda
Getting noticed

I have a number of sites with Meraki MX creating a IPSEC tunnel to an Azure Gateway. For most sites this seems stable but I have one site an MX250 HA Pair (18.211.2) which seems to be having issues. The Meraki send the IKE_SA_Init to which the Azure Gateway responds. There is then a 9 second gap before the Azure Gateway sends out an INFORMATIONAL which contains a Notify Private Errors (12345) repeats and then the Meraki sends the IKE_SA_INIT again and it repeats. 

Then for no discernable reason that I haven't been able to capture the VPN springs into life. Only to go down again at some sporadic point in time for the issue above to repeat. TAC states its config but we are not making changes between incidents and the VPN does come up.

From the earlier contributions can I surmise the Meraki MX doesn't implement IKE V2 particularly well?

Justin-
Comes here often

We have used the ikev2 to our azure palo running panos 11.1, with minimal issues from several mx68w and one site with mx105.  But one site has mx250 and it constantly had problems. On the Palo side we have it configured in tunnel mode, and using a full tunnel(0.0.0.0/0), on the meraki side we broke up the 0.0.0.0/0 to omit the 10/8, 192.168/16 and 172.16/12  ranges to remove the overlap warnings. But with all that said,  I've had never had a issue with meraki mx in ikev1 mode, but this is policy mode on the meraki.  So you do not want any overlap with it, and the tunnels phase 2's have to match on both sides, which is laborious with this many ranges on the palo side. We also stay on meraki mx stable firmware train.  Been running this way for almost a year.  But it does seem to matter what mx device you have.

 

0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4

Get notified when there are additional replies to this discussion.