Meraki IDS blocking offsite backups

[mattmbit]

Hello,

Figured I would try a forum post before submitting a ticket because I'm not sure who to send the ticket to (Veeam or Meraki in this case).

I've had issues with a couple clients now where their offsite backup chain gets corrupted and my incremental backups will be incomplete. This will happen randomly and usually always comes down to my Meraki's firewall IDS detecting the backup as some sort of threat and blocking it.

My setup for this specific client is My Veeam server is at the main site doing its normal backups and the offsite backup is a Synology NAS at another site connected via Meraki's mesh VPN.

The last time this happened I had to essentially kill the entire repository and reseed it and start again.

Just seeing if there is anyone here with the same setup. I'm very hesitant to just white list the connection for security reasons.

Thanks

[Mildur]

Sorry to hear about that.
I think, you have to follow this kb article and create exclusions for veeam on your ids system:
https://www.veeam.com/kb2140

[vky]

Although this thread is a bit old I ran into this issue as well and came across this the original post in a search. Seeing as there was no update with a resolution and the KB article linked is lacking specifics for this particular problem, I'm going to give some details of what I experienced and the steps that I went through to discover the issue and to mitigate it.


This was for an Windows Agent job so on the host being backed up I was looking at C:\ProgramData\Veeam\Endpoint\[JobName]\Agent.Source.[*].log (the most recent modified one) and seeing many entries like the ones below:

[02.09.2021 10:39:23] < 24260> cli| Trying to connect to the endpoint [192.168.1.10:2500]
[02.09.2021 10:39:23] < 24260> cli| Connection status: system:0 ( The operation completed successfully ).
[02.09.2021 10:39:23] < 24260> alg| After reconnect confirmation received: [2568].
[02.09.2021 10:39:23] < 24260> alg| Reconnectable channel was recovered.
[02.09.2021 10:39:23] < 24260> alg| Sender stage: running send cycle. Resend list: [2].
[02.09.2021 10:39:23] < 13876> alg| Receiver stage: running recv cycle.
[02.09.2021 10:39:23] < 24260> alg| ERR |write: An existing connection was forcibly closed by the remote host
[02.09.2021 10:39:23] < 24260> alg| >> |--tr:Cannot write data to the socket. Data size: [1048589].
[02.09.2021 10:39:23] < 24260> alg| >> |An exception was thrown from thread [24260].
[02.09.2021 10:39:23] < 13876> alg| ERR |read: An existing connection was forcibly closed by the remote host
[02.09.2021 10:39:23] < 13876> alg| >> |--tr:Cannot read data from the socket. Requested data size: [13].
[02.09.2021 10:39:23] < 13876> alg| >> |An exception was thrown from thread [13876].

(Note that Veeam proxy was running on the same host as was being backed up coincidentally so I'm not sure if the logs are from the proxy or the agent.)

On the Veeam server/proxy at HQ I ran Wireshark and noted many RSTs from the IP of the above host, but with a MAC address for the router local to HQ. I went to investigate the event logs but found that the Meraki dashboard was giving a message about too many events and them being dropped. I configured a syslog server to capture security events and investigated those(https://documentation.meraki.com/Genera ... 2C_and_API). I saw many entries like this:

1630595849.857375460 HQ_MX_250 security_event ids_alerted signature=14 priority=3 timestamp=1630595849.823847 dhost=AB:CD:EF:AB:CD:EF direction=ingress protocol=tcp/ip src=192.168.2.11:50711 dst=192.168.1.10:2500 decision=blocked message: POLICY-OTHER eicar test string download attempt

In this case it thought it was seeing an eicar test string oddly enough. Per Meraki documentation I was able to whitelist based on that signature (https://documentation.meraki.com/MX/Con ... Protection).

Whitelisting Signatures
You can whitelist specific SNORT® signatures by clicking Whitelist an IDS rule. Any signatures for which matching traffic has been seen by the appliance will appear in the Select an Option drop-down so you can select which signature(s) you wish to whitelist.

Obviously you wouldn't necessarily want to whitelist just anything, but in this case it seemed to be a false positive that it was detecting an eicar test string. Once that whitelist was in place the backup was able to finish successfully.

[Devan]

Hello, I'm not sure if you resolved your issue.

I had the same issue. This was caused by the Meraki blocking the Peer-to-peer connection.
To resolve the issue, you need to allow the "Encrypted P2P" setting under the Layer 7 rules. The rest of the P2P connections can be blocked, only "Encrypted P2P" needs to be allowed.

[jhemphill]

I don't see how to set a Layer 7 rule to Allow.
Any suggestions?

[jhemphill]

I was able to add a layer 3 rule to the Site to Site VPN firewall rules: listing my Source Veeam server, "Any" Source port, Destination IP, and Destination ports 2500-3300.
I believe this resolved the similar issues to this thread that I was having.