Overview

This article provides information on the LanGuard Agent communications with the LanGuard server and diagnostic guidelines. 

Introduction

The following flowchart illustrates the entire communication between Agent and Server during the Agents lifetime:

Description

Communications

The LanGuard Agent and LanGuard Server communicate with each other in various ways and because of different reasons.

Scanning

LanGuard uses such a DCOM engine called LNSSCommunicator to communicate with remote (or the local) machines during a scan process and enumerate the required information, yet some interactions are using other channels.

1. Whenever a refresh information scan is to be performed by the Agent, a change is made to the agent’s configuration or a scanning profile is altered, the LanGuard Server Attendant Service connects to the Agent’s data folder via SMB (port 445) and pushes the required files to the %AgentDataFolder%\Servers\{SERVER UID} folder. 

   For example, when a scan profile is changed, Server notifies the Agent of the change by writing a profilesupdateorder.txt file to the agent’s %AgentDataFolder%\Servers\{SERVER UID} folder. This causes the agent to download the new operationsprofiles.7z before the next scan.

   Note:

   • The SMB connection requires access to admin shares (C$).
   • The Attendant Service account needs write permission on this folder if no alternative credentials have been specified in this machine’s properties on the LanGuard Server.
   • The change may take time when the Agent Manager process is doing some other actions. An Agent scan can be initiated to force the change. The Agent Manager will send the new configuration files and scan order to the agent immediately.

2. During a scan, the Agent sends regular status updates back to Server, such as ‘Scan started’, ‘Scan in progress’, ‘Error encountered’, etc. For this (and ONLY for this) the agent will always talk to the Server port 1072 (by default), even when configured to use a Relay.

3. Once a scan is complete the Agent exports the scan result from its own scanresults.mdb as a new XML file to its %AgentDataFolder%\Servers\{SERVER UID} folder and sends the ‘Scan complete’ status message.

   The Server subsequently connects again via SMB to the Agent, collects the XML scan result, and imports it into the main database in the same way manual XML scan result import is handled.

4. At regular intervals the main application’s agent manager will connect to each agent, verify it is installed, check for scan results that were not previously imported, any agent messages posted, and update the timestamp.

For more information regarding communications during the Scanning, refer to LanGuard Scanning Process Workflow 

Updating

Agents request updates from the GFI LanGuard Server if no Relay Agent is assigned. They check for program updates using update.exe at the following times:

1. Once between the hours configured in the Agents Management settings.

   

   This is done to ensure the agents are updated regularly while allowing configuring downloads off working hours. The time is constant for a given agent and is initialized when the agent is installed. This time is kept in toolcfg_updates.xml on each agent in the field Recurrence/Time.

   Each agent is given a different time to do their update so as to not overwhelm the network with requests all at the same time.

2. Just prior to the beginning of any scan to make sure they have the latest patch and vulnerability
   definitions.

Agent Diagnostic

To help users to find out what agents are not being updated or having other issues the diagnostic information is displayed in Dashboard > Overview > Agent Status.

The Agent Diagnostic feature enables automatic troubleshooting of agents. It launches a new GUI which displays the progress and results of an agent diagnostic operation. The operation verifies connectivity to/from the agent, provides helpful error messages when needed, and also displays a summary at the end containing relevant state information about the agent.

Note: All this information can be found on the main server and is stored in lanss_vxxx_attendantservice.csv and lanss_vxxx_securityscanner.csv

If all of the checks pass Agent Diagnostic collects troubleshooting data and imports it to %DataFolder%\Servers\{SERVER UID} on the Server. If there are communication errors between Server and Agent, the troubleshooter archive is created on the Agent %AgentDataFolder%\Servers\{SERVER UID} folder.

Note: if the remote registry check fails all the next steps fail and the troubleshooter archive is not generated.

Relay Agent Related Heath Errors

The Agent Heath pane displays any error encountered by Agents and Relay Agents.

The messages (errors or warnings) are retrieved from the file %AgentDataFolder%\Servers\{SERVER UID}\toolcfg_agentmessages.xml and the Agent creates, modifies and deletes this file, while LanGuard server reads and removes this file when present.

The attributes are:

• ID - message type UID
• Component - which component generated the message
• Priority - (0 is the lowest)
• Type - "0" means Error (default value), "1" means Warning

Whenever an agent component responsible for reporting messages executes, it will follow this flow:

The following types of errors can be encountered:

The Agent cannot connect to Server via Relay

These errors occur when an Agent cannot connect to a Relay.

Possible reasons:

• The Relay is offline
• A firewall on the Relay or on the route is blocking the Agent access
• The Agent is in another subnet

Modules involved:

• Update.exe - if any of the update downloads fail, an error is reported
  
• PatchAgent.exe - when running on a machine with an agent installed with relay settings, if any downloads through relay fail an error is reported
  
• AgentManager.dll on the Server is responsible for checking/clearing toolcfg_agentmessages.xml 

Relay is offline

These errors occur when LanGuard Server is unable to contact a Relay. 

Possible reasons:

• The Relay is offline
• ICMP Echo is disabled on the relay
• A firewall on the relay, or somewhere in between, is blocking the access

Modules involved:

• AgentManager.dll Attendant Service plugin performs a PING on each Relay on a 20 minutes loop. If any Relay Agent fails to respond to the PING request, a "Relay agent is offline" error will be created in the database.

Relay functionality errors

These errors occur when a relay agent cannot function according to its specifications and settings.

Possible reasons:

• Invalid cache folder
• Not enough disk space for caching
• A firewall blocking Apache
• Other Apache errors

Modules involved:

• HttpServerAttPlugin.dll - performs, on a 10-minute loop, the free space check (free space on the cache folder disk drive is at least 2GB). If the check fails a warning message is reported:
  

  Also on a 10-minute loop, it checks the validity and existence of the cache folder, and reports an error if the specified folder doesn't exist:
  

  Possible Apache errors will have:
  

• HttpServerOp.dll - when configuring the cache folder for the Apache server it checks the specified cache folder existence and tries to create it if needed. If the path is still invalid\non-existent, it will instead tell Apache to use a predefined fallback folder for caching: %DataFolder%\Cache\Http.
• AgentManager.dll on the Server is responsible for checking/clearing toolcfg_agentmessages.xml