Overview

The GFI LanGuard console displays Unable to contact server in the Agent Status pane of the Overview tab.

Solution

There are several possible root causes for the Unable to contact server error messages, all of which revolve around communications and Program Update failures.

• Each day once between the hours of 10 AM and 5 PM (can be changed) it requests program updates - new patch and vulnerability definitions and other program components.
• When it begins a scan it does a check of program updates.
• During a scan (after attempting a program updates session) it sends a Scan Notification 'Post' message directly to the LanGuard server.
• When it finishes its scan it sends a Scan Notification 'Post' message directly to the LanGuard server.

When using Relay Agents, all agent requests for Program Updates go to the Relay Agent communication port (1072 by default). However, all Scan Notification Messages go directly to the LanGuard server's communication port (1072 by default). You can find the traces in the LanGuard server or Relay Agent Debuglogs\HTTPD\Access.log.xxxxx files.

When these communications fail the agent will put a corresponding error message in its Servers\<GUID> directory that the LanGuard server will pick up and display.

There are two different resolutions depending on whether the agent is configured to connect via the Relay Agent or directly to the server. See the appropriate section below based on your setup.

You may have to install the telnet client from Programs and Features or Add Remove Programs.

Ensuring communications when the agent IS NOT using a relay:

1. Ensure the communication server port is open on the GFI LanGuard server. This setting is specified under Agents Settings > General tab (port 1072 by default):
   
   
   • This can be tested by running the following command from the command line:

Netstat -ano | find ":<port>" (ex. netstat -ano | find ":1072")

1. • Check that there are two httpd.exe processes listed in Task Manager and that the Command-Line entry references the C:\Program Files (x86)\GFI directory.
     
     
2. Ensure that the GFI LanGuard server's local firewall has an exclusion for the port.
3. Ensure the agent can access the GFI LanGuard server's communication server port:
   
   • This can be tested from any agent machine by connecting to http://<LanguardServerIP>:port/files/update/index.txt (e.g. http://192.168.1.200:1072/files/update/index.txt). This should return a page with a single number.
   • Alternately you can test by using the telnet command from the agent command prompt:

telnet <LanGuard_IP> <port>
ex. telnet 192.168.1.200 1072

Ensuring communications when the agent IS using a Relay:

1. Make sure the port used by the Relay Agent is open (by default 1072). This setting is specified in the console under <Relay Computer> Properties > Relays tab > Advanced Settings link.
   
   
   • This can be tested by running the following command from the command line:

netstat -ano | find ":<port>"
ex. netstat -ano | find ":1072"

2. Check that there are two httpd.exe processes listed in Relay Agent Task Manager and that the Command-Line entry references the C:\Program Files (x86)\GFI directory.
3. Make sure that the Relay Agent's firewall (Windows firewall) has an exclusion for the port.
4. Make sure the agent can access the relay agent's communication port:
   
   
   • This can be tested from any agent machine by connecting to http://<LanguardServerIP>:port/files/update/index.txt (e.g. http://192.168.1.200:1072/files/update/index.txt). This should return a page with a single number.
   • Alternately you can test by using the telnet command from the agent command prompt:

telnet <LanGuard_IP> <port>
ex. telnet 192.168.1.200 1072

Testing

Once communications are established go to the LanGuard console Dashboard tab, locate the agent machine in the Computer Tree, right-click on it and choose Scan > Refresh information now.

If the error persists after the scan is completed, it might be that the agent fails to download program update files via the LanGuard Server or Relay Agent - continue with the Manually Testing if an Agent Can Download Patches or Updates.

In rare cases, the root cause is that the agent fails to put the patch/vulnerability definitions into the patch/vulnerability databases - this will usually resolve itself during later updates.