MX Appliance and Cisco Anti-Replay Detection

KeithBucknall
Here to help

MX Appliance and Cisco Anti-Replay Detection

Hi,

 

We are currently having a lot of issues with our newly deployed (and to be deployed) MX's over a site-to-site VPN with a Juniper firewall.  The MX's replaced some ageing Cisco ASA's that also had an issue which Cisco identified as the Anti-Replay protection and the MX's are showing the same symptoms.

 

Having worked with the Meraki support team they have hit a block as the product team have not confirmed if Anti-Replay is in the MX code or not and if so how to disable it - I am posting this hoping someone will know or answer.

 

Thanks

 

Keith

13 Replies 13
PhilipDAth
Kind of a big deal
Kind of a big deal

Anti-replay protection is part of IPSec.  It is not a Cisco/Meraki/Juniper feature per-see.

 

Sometimes there can be multiple paths between a source and destination.  This can cause the IPSec packets to arrive out of order.  IPSec can only decrypt the packets if they arrive in order.

 

So when packets arrive out of order (or a packet goes missing) the device is allowed to buffer packets up to the "replay window size" and put them back into order.  If the missing packets have not turned up in that time it has no choice but to throw them away.  At this point you effectively have to rebuild the VPN.

 

On Cisco ASA's and Cisco routers you can configure the replay window size.  You can't do this on Cisco Meraki.  I have no idea about Juniper.

On the whole, it is not a setting that has to be adjusted very often.  When you need to adjust it you normally only make it larger.

 

If you are experiencing replay window issues and the Juniper can not have its window expanded then you should probably look at the root of the issue - why are you getting packets lost or transmitted out of order so often.

PhilipDAth
Kind of a big deal
Kind of a big deal

You can read more about it on Wikipedia.

https://en.wikipedia.org/wiki/Anti-replay

KeithBucknall
Here to help

Thanks for the reply, is the window sized configured within ike phase 2 proposal as this is what Meraki support advised us to remove from the Juniper configuration and since then it has been ok.  But we do see a lot of re-negotiations on the MX side but now on the Juniper side.

PhilipDAth
Kind of a big deal
Kind of a big deal

To the best of my knowledge, the replay window size is not a negotiated parameter.  On Cisco Enterprise kit you can configure it globally or per VPN.

KeithBucknall
Here to help

Hi,

 

Just to update you on this we are having more and more issues with different MX's and we think the issue is either the ESP window size or the fact that the Meraki's have anti-replay enabled.

 

I am about to rip these out for Fortinet which is a shame.

KeithBucknall
Here to help

Hi,

 

We have had two sites go down today one with an MX-64 and the other with MX-100 both terminating on a 3rd Party ISG, the issue was slightly different to the loss of packets yesterday within the active tunnel.  This was the tunnel going down.

 

I am starting to think this is a Meraki bug issue but support cant find the issue

KeithBucknall
Here to help

We had another outage and the only advise I get now is try and get upstream packet captures which ~I cannot do for this remote site.  5 times now Meraki refuse to disable Anti Replay Protection and I cannot understand why the product team will not disable this.  Every "enterprise" firewall has the ability to do this apart from Meraki.

 

It is so frustrating that the only option I have is to get a refund for all my MX firewalls and move to an "enterprise" class device, so disappointing.

PhilipDAth
Kind of a big deal
Kind of a big deal

I think you have a fundamental mis-understanding of anti-replay detection.

 

This is a "per-device" setting.  It is not a negotiated setting.

 

And you absolutely do not want it disabled.  VPNs would fall over constantly without it.  Anti-replay detection allows packets to be re-ordered (inside of the window) that are received out of order - rather than tearing the entire VPN down.

PhilipDAth
Kind of a big deal
Kind of a big deal

Maybe it might be better to buy an extra MX and put it at this third party, so you can use AutoVPN to the VPNs automatically.  It would save all the grief you are having.

KeithBucknall
Here to help

@PhilipDAth I would love to do that but the 3rd party refuses it!

KeithBucknall
Here to help

Hi all,

 

Just to update you on this, it turns out that we cannot work out what is happening and the only function we cannot disable and test is Anti-Replay Protection which Meraki cannot do.  Therefore I am now having to replace all my firewalls with another vendor that supports this which is extremely disappointing.  Meraki advised us to move to Cisco ASA but I do not have the skills in-house which is why I wanted Meraki in the first place.

 

Shame.!

OHTorx
Here to help

We have the same issues and have had a case opened opened for months. We finally had a break through. With firmware 15.7 Meraki changed the anti replay value from 4 to 32. Juniper has a default value of 64. We have requested that this be a configurable value either to the end user or the Support staff. After applying the beta code all has been smooth. We are still working out a few Dead Peer detection issues, on lesser used subnets.
ITofTN
Here to help

From another thread

 

https://community.meraki.com/t5/Security-SD-WAN/VPN-stops-passing-traffic-between-Meraki-Security-Ap...

 

Advised me to look into the anti-replay window between the meraki and the watchguard firewall.

 

Having issue of phase2 just hanging they turned off nat-T but another user referenced anti-replay.

 

 

 

Get notified when there are additional replies to this discussion.