juanmachado wrote: ↑Feb 26, 2025 6:30 pm
Giving network access to our Veeam agents to talk directly to our Inmutable Hard Repositories is a no-no. It breaks all the best practices promoted by Veeam regarding their Hard Repositories.
I'm curious where you saw us promoting the idea that Veeam Agents should never have direct access to a hardened repository for transferring backup data. Can you maybe share a link?
Our "promoted best practice" for hardened repositories advise closing all remote management ports, such as remote hardware management and SSH. If an attacker gains root access to the machine through such ports, they could potentially delete the entire disk partition containing the backups. That's why it's essential to block remote management protocols and ports from external access.
However, it’s important that the Agents and Backup Proxy Server for VM and file backup jobs can communicate with the Data Mover Service on the hardened repository for transferring backup data and restoring data.
+1 for proxy, in particular to use the backup server.
The repo is the biggest target for attack, and we need to have it accessible to all the agents, on ports 2500-3300? We use stateless ACLs on a system that does not allow port ranges to be specified, so we would need an ACL entry for each port, each way, for each of the 5 agents we're backing up. Thousands of ACLs. Madness.
Why can't we proxy it through the backup server, so only it needs to talk to the repo? Is there a technical reason this is difficult, or is it seen as not needed?
At the very least, allow us to specify the range of ports needed, which would let me create a job for each agent and specify the port for that job. Two ACL entries for each agent beats 1600.
Please note that normally only a few first ports from that range are used, and their total number depends on concurrency. For example, if your repository is set to accept a maximum of 10 concurrent tasks, then only ports 2500 to 2509 will be ever used no matter how many workloads are you protecting.
That's not what it's doing in my case. I have max concurrency set to 4, but the recent failures tried to use ports 2500-2512 (except 2504) for my 4 agents.
The first try was on port 2508, and port usage was more or less random, sometimes with it retrying an agent on the same port and sometimes switching.
I disabled the job at retry 25.
This is unexpected so have our support engineer take a look. Devs tell me agent debug log will explicitly list all ports that have been tried. From code perspective, the port selection is definitely not "random", rather first available port in the above mentioned range should be used.