The official "Used Ports"
page is... daunting. There are a LOT of edge cases requiring a LOT of holes poked through firewalls. Some of that surely makes sense - weird storage arrays etc. But to highlight where I believe most of the problem is, look at the sections labeled "Backup Server -> Linux Server" and compare that to "Backup Server -> Windows Server."
Put differently, when Veeam wants to control a Linux box it logs in via SSH and gets work done. When Veeam wants to control a Windows box it lazily expects a kazillion various NetBIOS and RPC ports to be open and ready to roll, and from what I've been experiencing, Veeam fails miserably when one of those ports isn't in the right state. When you're a sysadmin working with a networking team and constantly have to go hat in hand to beg for yet another large number of firewall rules to be poked, this is a huge time sink and a major drag.
What I propose is that Veeam develop some sort of runtime middleware that spawns on the Windows box (using the same install method as the Transport service perhaps) that only requires one control port open to the management server, guest interaction proxy, etc.
Note: I'm not complaining about the port range for Data Mover. That is at least consistent across platforms. I am complaining about needing to poke TCP 111, 135, 137-139, 445, 1058+ 2049+, 6060-6162, 49152-65535 and UDP 111, 135, 137-139, 445, 1058+, 2049+ for each and every Windows box out there versus TCP 22 for each Linux box.
Really, control data should be limited to SOAP over 443, SSH on 22, and some single Windows port. Please Veeam, you gotta do something about all this sprawl.