Intrusion Detection and Prevention breaks Hyper-V Replication

[MMoss]

I have an issue where ID&P breaks out Hyper-V replication. If it's in detection it works fine, but flip it to prevention and it dies. It's been very hit and miss in the past so we've switched to detection, but the last month or so it's run well on prevention. It's set for security, but even set to balanced it still randomly happens. I'll watch it replicate fine and then fail out of nowhere. We are replicating between a MX67C and MX100 Firmware 17.10.2, but both were upgraded at least a week prior to it starting up again.

Right now we replicate over port 80 and support has us moving it to port 443 thinking the encryption of traffic might keep it from being flagged. The Security Center logs also don't show the reason for the replication being blocked. I had 3 hits yesterday and the day before and whitelisted those. It's still failing with no new flagged events in the logs.

Has anyone else seen this?

[PhilipDAth]

This is going to be very firmware dependent.  Version 17.x firmware has moved to the brand new snort V3 engine for IPS.  I think if I was you, I would move to that firmware version, and concentrate on getting that going (since all new versions of the firmware will be based on snort V3).

[MMoss]

I'm running V17.10.1, but they are asking me this. They are thinking if we use port 443 it might correct the issue because the traffic is encrypted, but I'm not sure on that one. I have my Sys admin looking into getting new certs on the servers today. Read Only Friday last week and all. Looks like I'll need to see it fail in order to get some pcap's again. Their response below.

The worst part is there is no security center logs to help troubleshoot. If it is a SNORT rule then it's simply unacceptable that it's not being logged.

"Can you take a LAN interface on the MX to see if the MX is sending TCP packets with RST packets to interrupt the replication? "

[JosephJVV]

I have the exact same issue with 2 of my Customers who replicated their Hyper-V VMs back to our office over a VPN.

Meraki Technical support has said it is an isolated case and here we are having the same issue.

It is difficult to do support over the phone as it sometimes works and then the server suddenly goes to "critical" and by that time Meraki support have said to monitor the issue

[PhilipDAth]

Does it happen with the 17.x firmware?

[JosephJVV]

Yip only with the new Firmware MX 17.10.2. 

[CptnCrnch]

Your best option (sorry to say that) is opening a case with Meraki.

[MMoss]

Same here, this is their response to my ticket. I'll be trying this shortly. "Can you take a LAN interface on the MX to see if the MX is sending TCP packets with RST packets to interrupt the replication? " During the call the also asked if I'd try moving backups to port 443 which my Sys Admin is looking into. If it works I'll let you know. Right now no matter what security lever I set it at it causes the replication to crap out.