Quick fix here for an operational task error I encountered in Veeam FastSCP 3.0.3. I was trying to copy a file from the VMware vMA 4.1 appliance to a Windows folder using Veeam FastSCP 3.0.3. In Veeam, the vMA appliance is registered as a Linux server & is recognized in the interface as the server object with the penguin. In this example, I’m trying to copy /etc/motd to my local C: drive on Windows 7 Ultimate 64 bit:
After a delay of several seconds, the error message is displayed:
Agents failed to start, server “vma41.boche.mcse”, client “localhost” Cannot connect to server [x.x.x.x:2500].
The problem is an iptables daemon which is responsible for blocking communication on port 2500. The workaround I used is to temporarily disable the iptables daemon as follows:
[vi-admin@vma41 etc]$ sudo service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter [ OK ]
Unloading iptables modules: [ OK ]
Immediately after the iptables daemon is stopped, I’m able to copy the file:
Now that my file is copied, I’ll undo the workaround, ensuring the vMA appliance is left in the state I had found it with its firewall rules applied:
[vi-admin@vma41 etc]$ sudo service iptables start
Applying iptables firewall rules: [ OK ]
Loading additional iptables modules: ip_conntrack_netbios_n[ OK ]
Left alone, the workaround would persist until the next reboot. Other workarounds to deal with this issue in a more permanent fashion would be to open port 2500 or use chkconfig to permanently disable the iptables daemon as follows:
sudo chkconfig iptables off
sudo service iptables save
sudo service iptables stop
I’m not sure I would consider turning off the firewall so I could access a single port a “solution”. In my eyes opening that single port on the firewall is the solution, anything else is a massive reduction in security and I’m surprised it was suggested
I’m not too concerned about attacks on an internal vMA appliance which is not running VMs and has no sensitive data other than a list of host names and corresponding SSL thumbprints if connections were established. The workaround was in place only for a few minutes.
I’ll also call to attention the end of the post where I said:
“Other workarounds to deal with this issue in a more permanent fashion would be to open port 2500”