Veeam FastSCP “Agents failed to start” During Copy

February 8th, 2011 by jason Leave a reply »

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:

SnagIt Capture

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].

SnagIt Capture

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 ]

SnagIt Capture

Immediately after the iptables daemon is stopped, I’m able to copy the file:

SnagIt Capture

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 ]

SnagIt Capture

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


No comments

  1. Dave says:

    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

  2. jason says:

    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”

Leave a Reply