Test Connections to Agent button in SureSync 8 fails with a failed to connect error

Steps to take when encountering an error testing connections to a Communications Agent

When attempting to connect to a Communications Agent service with the ’Test Connections to Agent’ button on the General tab of the Computer, the test fails with the following error:
"Failed to connect from [machine1] to the Status Service on [machine2] via TCP Port 9032, Basic256. The Communications Service may not be running, communications may be blocked, or you may have specified the DNS name or IP address incorrectly."

and

"Failed to connect from [machine1] to the Status Service on [machine2] via TCP Port 9032, TLS with Certificate. The Communications Service may not be running, communications may be blocked, or you may have specified the DNS name or IP address incorrectly."

This message can be caused by a number of configuration issues. Possible causes are:

  1. Make sure the Communications Agent service is started on the remote machine you’re attempting to connect to.
  2. Expand the Computers node of the SureSync Desktop and click on the Computer in question. This will be under Servers or Workstations depending on operating system type. The name in the list must be the NetBIOS name of the machine. If you used a name other than the NetBIOS name of the machine, delete the entry and add the machine again using the correct name.
  3. Check the connection details under Listen Configurations for the computer in question. The defaults are a TCP, Port=9032, TLS with Certificate connection used for data transfer and a (Config) TCP, Port=9032 connection used for Agent configuration data exchange. On the Options tab of each connection is the Default Access Name used to access the machine. This can be a NetBIOS name, IPv4, IPv6 or fully qualified domain name (FQDN). The same Default Access Name should be defined for both connections.
  4. You could also be missing the advanced user right "log on as a batch job" on the Communications Agent machine. Verify that this right is assigned to the account you have listed under "Login Name" for the machine you’re trying to test to. This is assigned in Local Security Policy under Administrative Tools. Under Local Policies | User Rights Assignments is the "Log on as batch job" right.
  5. Ensure that the clocks on the computers in question are accurate. .NET cryptography will reject requests when the clocks are greater than 5 minutes apart. An error from .NET should be logged in the Application Event Viewer indicating that problem.
  6. The final possibility is that there is a router or firewall somewhere between the main SureSync installation and the Communications Agent, which is blocking traffic on SureSync’s port. The default port is TCP 9032. Please make sure the port is open on any hardware firewalls/routers between the machines that might be blocking our traffic.

The Windows Firewall has become a very common cause of this error message. By default, the SureSync installer will attempt to configure an exception to allow the Communications Agent traffic through. However, you should verify this is setup correctly and add a rule if needed. It is often helpful to turn the Windows Firewall off as a test. If the connection is then successful you know the issue is with the Windows Firewall.

Another potential issue relates to NAT forwarding in firewalls. Assume you have SureSync installed on ServerA in OfficeA. OfficeA is located in San Francisco and is connected to OfficeB in New York. The New York office has a firewall. In OfficeB are ServerB and ServerC which you want to synchronize with ServerA using the Communications Agent. This two destinations can be a problem if you don’t have multiple public IP addresses because firewalls can only forward traffic from one IP address/Port to one internal destination. In this case, you need separate public IP addresses for each of the machines. The other option is to install SureSync in New York. This allows you to access the one machine in San Francisco via a public IP that is properly forwarded to ServerA by the firewall in OfficeA. The other New York machine can be accessed via a local IP address or DNS name which gets around the NAT firewall issue.

Open Port Checker Tools

A number of different web sites can be used to test if a port is open. You can visit one or more of these sites, enter the IP address being used to reach the Communications Agent and port 9031 to test and see if the port is really open. If this test fails, the port is not open and is still being blocked by a firewall or security device of some type.