Windows Collector proxy support

Overview

The devices in a corporate network typically connect to the Internet through a proxy server instead of using a direct connection. A proxy server, often simply referred to as a proxy, forwards the requests of client applications that run on corporate devices to the servers that run on the Internet, as if the proxy itself is initiating the requests. Then the proxy sends the responses from the servers back to the clients. By acting as an intermediary, a proxy server can provide varied functionality such as content filtering (for improved security) or content caching (for better performance).

Collectors inside a corporate network that is equipped with a proxy server are usually required to send their traffic through the proxy to reach the Nexthink instance. In this article, learn about the different types of proxies and configurations supported by Collector.

Supported types of proxies

Collector supports the following types of proxies:

• HTTP

• SOCKS5

Collector should work out of the box with transparent proxies that automatically intercept network traffic going from the corporate network to the Internet. The client systems are not aware that their traffic is traversing a proxy.

Authentication

Collector for Windows supports Integrated Windows Authentication (IWA).

Because Collector runs as a service under the local system, if a configured proxy requires NTLM authentication, Collector responds to the challenge with the computer's identity.

Supported proxy configurations

Proxy settings may appear at different levels.

System level

Settings apply to all users and applications on the device.

Application level

Settings apply only to the application itself.

Because Collector runs as a Windows service, it can read the proxy settings specified both at the application level (its own custom configuration) and at the system level, but not at the user level. Therefore, Collector supports the methods described below to configure its proxy settings.

Microsoft Windows HTTP Services (WinHTTP)

The WinHTTP interface is meant to be used by server applications and system services such as Collector. It provides proxy settings at the system level and its configuration is stored in the Windows Registry.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
Value: WinHttpSettings
Type: Binary

To read the proxy settings on a device, type from the command prompt:

netsh winhttp show proxy

To configure the proxy settings on a device, use the set proxy command. Type in the following to display usage and options:

netsh winhttp set proxy /?

As the Collector is a system component, the user-specific settings do not have any impact on it.

Some important remarks regarding the syntax used for the bypass list:

• The bypass entry for the Nexthink instance must match the value you used during the Collector configuration. If you used the fully qualified domain name (FQDN), then you must use it in the bypass list.

• As stated in the Microsoft documentation, the bypass list can contain wildcards. Make sure to remember that something like *.nexthink.cloud is correct but nexthink.* is not supported. Nexthink Collector also supports the following kinds of entries 192.168.212* or 192.168.* or 192.* but other products installed on the system might not.

Microsoft Windows Internet (WinINet) API

The WinINet API was designed to give interactive desktop applications access to standard Internet protocols such as HTTP or FTP. Applications such as Internet Explorer get their proxy configuration via WinINet.

By default, WinINet provides proxy settings at the user level. So, Collector cannot read them. To make them readable by Collector, promote the WinINet proxy settings to system level by setting the ProxySettingsPerUser value to 0 in the Windows Registry.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
Value: ProxySettingsPerUser
Type: Binary
Data: 0

Or by setting the following GPO:

Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\
Make proxy settings per-machine (rather than per user)

Web Proxy Auto-Discovery (WPAD)

The Web Proxy Auto-Discovery (WPAD) protocol is a method to set the proxy settings automatically by leveraging the DHCP and DNS protocols. WPAD uses discovery methods in DHCP and DNS to find out the URL of a PAC file, in much the same way as WinINet gets its LAN settings when automatic detection is enabled.

Collector custom configuration

Specify the proxy settings of Collector at the application level during installation, with the Collector Installer or with the MSI parameters, or later with the Collector configuration tool.

There are basically two options for custom configuration:

• Automatic proxy Get a PAC file from the specified URL to automatically determine the proxy settings. A proxy-auto-config (PAC) file is a JavaScript file with a single function that determines which proxy should be used for each client connection.

• Manual proxy Manually provide the address and port of the proxy.

Collector logic to choose proxy settings

Collector for Windows selects one method to get its proxy settings on a trial and error basis. Collector tests the validity of each method in sequence: the first method that yields a set of proxy settings which allows Collector to connect to the Nexthink instance is kept. Methods are tried in the following order until one of them is successful:

1. Collector custom configuration.

   1. If enabled, automatic proxy configuration through PAC file.

   2. If enabled, manual proxy configuration.

2. Direct connection without proxy.

3. Microsoft Windows HTTP Services (WinHTTP).

4. Microsoft Windows Internet (WinINet) API.

   • Only if settings are valid at the system level (per device).

     1. Manual configuration.

     2. PAC file referenced by URL (automatic configuration script).

5. Web Proxy Auto-Discovery (WPAD).