Using Collector on the Internet


Using Collector on the Internet

The Nexthink solution provides support for many different network architectures. The typical scenario is always focused on the assumption that the computers that are monitored via the Nexthink Collector and, optionally kept updated via the Nexthink Updater, are always part of a corporate network. There are situations in which it is still possible to collect data from computers located in remote networks connected via the Internet.

This guide aims at highlighting the different issues that might surface when designing a Nexthink infrastructure that is using the Internet as transport, and the best practices that allow Nexthink to work is such cases. Designs where VPNs are used, either for site-to-site or client remote access, fall outside of the scope of this document, since they typically allow traffic to flow without restrictions from the remote machines.

A typical Nexthink network architecture including remote sites with machines on which Collector is installed can be visualized in the following way:

UsingCollectorOnTheInternet architecture.png

While the part of the Nexthink infrastructure that is located inside of the boundary of the corporate network behaves in a normal fashion, there are different considerations related to the architecture on the Internet side, and how Nexthink behaves in such conditions. There are considerations to address about:

  1. Location of the Nexthink Engine on the network
  2. Considerations about firewalls
  3. Considerations about Network Address Translation (NAT)
  4. Impact of data loss due to using the Internet as transport for traffic

Location of the Nexthink Engine on the network

Three different architectures can be implemented:

  1. The Engine is located on the DMZ (Demilitarized Zone);
  2. The Engine is located on the Internal network;
  3. Two Engines are installed, one on the DMZ and the other on the Internal network.

Security requirements might dictate the location for the Nexthink Engine.

In case a two Engines architecture is required, it is mandatory to correctly configure Domain Name Service (DNS) in order to supply the correct IP address to the Nexthink Collector to those laptop computers which will be connected at different times to both the internal network and via the Internet. In such situations the so-called split DNS scenario will help, as it will always provide the correct IP address of the Engine to use depending on the location of the laptop computer at any given time.

Currently, Nexthink Collector refreshes DNS information every 60 minutes. This means that activities performed right after changing location might not be recorded by Nexthink Engine.

Here is a general network diagram of possible Nexthink architectures:

UsingCollectorOnTheInternet dmz.png

Considerations about firewalls

A firewall is typically situated on the boundary of the corporate network, and is used to separate at a logical level the internal network from the external network, and the DMZ. The DMZ is where the servers that must be accessible from the Internet are typically located.

The Nexthink Engine can be located on the DMZ or in the corporate network.

Depending on the actual location of the Nexthink Engine, there will be a need to configure the firewall to allow incoming traffic from the remote Nexthink Collectors located on the Internet to cross the firewall and flow towards the Nexthink Engine.

If the Nexthink Engine is located on the DMZ, appropriate security considerations must be made, even though the Nexthink Appliance exposes only the required services for its operation.

For example, a suitable best practice would allow only the UDP traffic coming from the remote Collectors to pass thru the firewall and reach the Nexthink Engine on the DMZ.

The traffic flows from the remote endpoints towards the Engine happen on the protocols and ports described in the following articles:

* Connectivity Requirements for Collector
* Connectivity Requirements for Updater

Considerations about NAT

In most network designs, somewhere on the network there will be a device performing NAT, in order to translate the IP addresses used on the internal network to external IP addresses valid globally on the Internet. Most home routers perform NAT. The DMZ itself can have either public addresses, or be already subject to NAT. There is no standard way to design a network, so it will be important to work with the network team when designing the Nexthink infrastructure architecture.

If NAT is performed, all the devices sitting on the opposite side of the NAT with respect to the Engine will be reported with the same IP address. This does not result in any limitation with the Nexthink solution except for the fact that information about the actual IP address of these devices will not be available.

TCP traffic originated by the Nexthink Updater and crossing a NAT device will not be affected, and Updater operations will work normally.

UsingCollectorOnTheInternet nat.png

Impact of possible data loss

While most corporate networks seldom have problems with data loss, when using the Internet to transport traffic from remote PCs towards the Nexthink Engine, there sometimes can be data loss.

Nexthink Collector provides duplication of important data to address this specific issue.

Another factor to take into consideration is the possibility that the UDP frames used by Nexthink Collector could become fragmented while in transit to the Nexthink Engine. This could be due to a mismatch between the Maximum Segment Size (MSS) allowed on the network path, and the amount of data present in the UDP frame generated by the Collector.

If the MSS exceeds the limit, then IP fragmentation will occur, and the UDP frames will be fragmented in more pieces. If one or more pieces of the UDP frame are lost in transit, then the whole UDP packet will be lost.

To avoid this issue with fragmentation, Nexthink recommends that the Collector be configured to create UDP frame of smaller size, a value of 600 bytes is recommended. The configuration can be changed in the Collector Advanced properties; the parameter name is Maximum payload size (bytes).

The Maximum payload size value is stored in the Windows registry in the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\nxtdrv\params The parameter name is “mss” and its type is REG_DWORD, as shown below.

Should the reconfiguration of the MSS parameter be needed on a large number of machines on which Collector is installed, the use of a Group Policy Object (GPO) is the recommended way to proceed. You should contact Nexthink Support in case more details are needed.

The MSS value can also be set when installing Collector for the first time. The Collector MSI Parameters Reference Table contains detailed information about this topic.