Overview

Prior to the Device42 18.06.00 release, message communications between the Main appliance, Remote Collectors and Windows Discovery Service servers was done via long-term, bi-directional WebSocket connections.

Starting in version 18.06.00, the default messaging communications mechanism has been changed to use a periodic polling model referred to as “Long Polling”. Long polling is a variation of a traditional polling model that is less chatty and more responsive.

While the default messaging communications model is now Long polling, it should be noted that Websocket communications are still supported if network infrastructure or other considerations require it.

Key Benefits of Long Polling

There are several benefits in transitioning the message communication model from WebSockets to Long Polling. Key benefits are listed below.

• Security: Long polling eliminates long lasting, stateful connections between servers. With Long polling, reauthorization is required on each poll request and mitigates a tempting security attack vector.
• Stability: Long lasting network connections have an increased vulnerability to network instability events.
• Scalability: Long polling can be more scalable than websockets for large-scale applications, as it can be implemented using load-balancers and distributed systems more easily.
• Simplicity: Long polling is simpler to implement than websockets, and requires less complex server-side code.
• Lower server load: Long polling can be less demanding on server resources than websockets by making short lived requests rather than maintaining a constant connection.
• Cloud Friendliness: As more and more computing moves to the Cloud, it is important to utilize communications techniques that are easily supported by Cloud infrastructure. Websockets are often not supported, discouraged, and can be difficult to configure and maintain in the Cloud.
• Future direction: The elimination of WebSocket communication is critical to the future direction of Device42 Discovery Collectors which is a strategy that envisions Collectors as simple, lightweight, stateless, Discovery engines that can be more easily deployed, organized into work groups, load balanced and more resource efficient.

Expected Issues and Work-Arounds

If you have established firewall rules between RC and MA and/or WDS and RC you might experience issues using Long polling, as different endpoints are used for Long polling requests.

The firewall must allow HTTPS (443) communication between the servers. Additionally if your firewall has specific URL rules in place for communication between these servers additional changes will be required. These are outlined below.

Note that WebSocket communication is still supported in order to mitigate issues with existing Firewall constraints. Both the Remote Collector and WDS can be configured to use WebSockets while waiting for Firewall constraints to be reconfigured if necessary.

Remote Collectors

As stated above, Remote Collectors can communicate with the Main appliance using either Long polling or Websockets, with Long polling as the default on upgrade or installation.

The following describes the process necessary to configure Long polling for a Remote Collector.

1. Log into the Remote Collector VM Console and choose: (f) Set Connection Configuration from the Device42 Appliance Management menu.
2. When the Set RC Connection Type page opens, select connection type: Websockets and press Save.

The Remote Collector will now use Websockets as the message communications mechanism.

To configure the Remote Collector to use Long polling, perform the procedure above selecting the Polling connection type option.

Note that each Remote Collector’s communication configuration is separate and distinct from other Remote Collector configurations, so it is possible to mix and match as required.

Remote Collector Configuration

Long Polling

In order to allow the MA and Remote Collector to communicate in Long polling mode, the Remote Collector must be able to successfully connect to port 443 and the following endpoints on the Main Appliance:

Endpoint

HTTP Method

/collectors/[0-9A-Za-z]+\-[0-9]+/connect/

POST

/collectors/[0-9A-Za-z]+\-[0-9]+/disconnect/

POST

/collectors/[0-9A-Za-z]+\-[0-9]+/fetch/

POST

/collectors/[0-9A-Za-z]+\-[0-9]+/message/

POST

Notes

The second section of each of the endpoints shown above is a regular expression. An example of the value of that section would be:

01010101010101010101010101010101-20

WebSockets

In order to allow the MA and Remote Collector to communicate in WebSockets mode, the Remote Collector must be able to successfully connect to port 443 and the following endpoint on the Main Appliance:

Endpoint

HTTP Method

/wsd/[0-9A-Za-z]+\-[0-9]+/.*

GET, POST

Notes

The second section of the endpoint shown above is a regular expression. An example of the value of that section would be:

01010101010101010101010101010101-20

The third section of the endpoint shown above is a regular expression that allows any legal URL characters.

Note that this WebSocket endpoint has not changed from previous versions, so existing Firewall rules with this constraint do not have to be modified.

WDS

As with Remote Collector communications, the Windows Discovery Service (WDS) communicates with the Remote Collector (RC) using one of two distinct mechanisms.

1. Using Long Poll - initiated by WDS on a periodic basis to collect and return Windows discovery jobs. This is the default configuration in 18.06.00 and forward.

1. Using WebSockets - initiated by WDS using a continuous connection to collect and return discovery jobs.

WDS Configuration

Long Polling

In Long Poll mode, the WDS makes periodic HTTPS POST requests to the Main Appliance or Remote Collector API endpoint as shown below.

Endpoint

HTTP Method

/api/wds/

POST

HTTPS traffic must be permitted to the /api/wds/ endpoint, thus on the server, you will need to configure your firewall to allow incoming traffic on port 443 (the default HTTPS port) and specify the URL path of the API endpoint.

WebSockets

To enable WebSocket mode between WDS and RC you need to make a manual change to the WDS configuration file “Device42.Service.exe.config”.

You must add an entry in this file to enable websockets from WDS To RC. This entry is to enable “Legacy Mode” WebSockets.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
…
    <add key="LegacyMode" value="true"/>
…
  </appSettings>

In WebSocket mode, GET and POST requests are made to the Main Appliance or Remote Collector on HTTPS port 443 to the endpoint shown below:

Endpoint

HTTP Method

/wsn

POST, GET

HTTPS traffic must be permitted to the /wsn endpoint, thus on the server, you will need to configure your firewall to allow incoming traffic on port 443 (the default HTTPS port) and specify the URL path of the API endpoint.

Firewall Configuration Notes

While Firewall configuration differs among vendors, this section outlines the basic vendor independent steps necessary to configure rules for Device42 endpoints in this document.

• Allow incoming traffic on port 443:
  • Open your firewall software or hardware settings
  • Create a new rule to allow incoming traffic on port 443
  • Specify the source and destination IP addresses as needed
  • Set the protocol to TCP
• Allow traffic to the one of the endpoints listed above:
  • Create a new rule to allow traffic to the endpoint
  • Specify the source and destination IP addresses as needed
  • Set the protocol to TCP
  • Set the port to 443
  • Specify the URL endpoint path as noted above
• Allow GET and POST requests:
  • Modify the rule created in step 2 to allow GET and POST requests
  • Specify the method as GET and POST

Again, the exact firewall configuration steps may vary depending on the Firewall software or hardware you are using. Consult your firewall documentation for specific instructions on how to create new rules.

Security Considerations

It's important to ensure that the firewall rules are configured to allow traffic to the desired endpoints while still maintaining security by only allowing traffic from trusted sources.