non-meraki vpn - constant renegotiation

[ZDonaldson]

I am working on a non-meraki tunnel to a Fortigate firewall.

It was solid until today when we added a bunch of additional networks to the tunnel config.  nothing was changed in the IPSEC configuration, although we verified once again that the configs match exactly.

We are seeing on the fortigate that there is an issue with the Phase 2, specifically with a non-match SPI.  I will admit i don't know what an SPI is, but its causing issues.

The Meraki logs, as is typical, are showing even less information.  they are only showing constant phase 2 negotiation with no indication as to why.

anyone have any sort of insight into this sort of issue?

[PhilipDAth]

An SPI basically denotes which IPSec connection it is (more important when the device has lots of them).  It is like an index into a table.

I would try giving both devices a power cycle if you can.  One of them might be hanging onto the old state.

Otherwise try removing the extra networks and get it working again, and then start adding the extra networks in a couple at a time.  Then you should get to a point where you know which change is breaking it.

[ZDonaldson]

fortigate support was able to confirm that the meraki is the culprit in initiating the phase 2 renegotiations.

I have restarted the MX unit with no success, still constant renegotiating.

[PhilipDAth]

It will re-negotiate if it fails to negotiate compatible parameters.

[Ramtech]

Do you have 2 x WAN Connections in the MX with load balancing disabled (fail-over mode)?  

If so do you have the Fortinet setup to have a tunnel to both (for redundancy and fail-over)?

If so this is your issue.  The Primary will be up and happy, the fail-over will keep failing until such a time as it fails over to the second WAN.  We have the same issue and it is very ugly unfortunately, but I can't find a work around.  Everything works fine, but the logs fill up with negotiation failures as it can't have 2 SPIs with the same routes on them (for obvious reasons).

Let me know if this helps and is your issue.  TAC could help you here also.

[Adam]

Make sure all the IPSEC configs and timers (lifetime) match for both side configs.  Also verify the subnets included in the tunnel.  I battled with this when trying to do a Non Meraki VPN tunnel to a Checkpoint FW as well. 

[ZDonaldson]

so, we are only using 1 internet connection.

I added the subnets to the tunnel one at a time.

We are now seeing that it has stopped renegotiating constantly and the mismatched SPI errors have gone away.

When we run pings between my site and one other site, no errors.

if we add traffic to a 3rd site at the same time, we see some packet loss

When a 4th site is added, its nearly 100% packet loss.

Its looking to me like the MX100 just doesn't have enough resources to handle processing this many routes across a tunnel.  very disappointing.

This would be only 1 of many ways in which the Meraki MX has proven to not be ready for primetime in anything more than the smallest of environments.