Windows Collector proxy support
Last updated
Last updated
The following content applies exclusively to the Nexthink Cloud offering.
The devices in a corporate network typically connect to the Internet through a proxy server instead of using a direct connection. A proxy server or proxy forwards the requests of client applications that run on the corporate devices to the servers that run on the Internet, as if the proxy itself initiated the requests. Then the proxy sends the responses from the servers back to the clients. By acting as intermediary, a proxy server can provide varied functionality such as content filtering (for improved security) or content caching (for better performance).
Thus, in a Nexthink Cloud setup, 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 Cloud. In this article, learn about the different types of proxies and configurations supported by the Collector.
Applies to platform | Windows |
The Collector supports the following types of proxies:
HTTP (web) proxy
SOCKS5 proxy
Collector should work out of the box with transparent proxies as well. Transparent proxies automatically intercept network traffic that goes from the corporate network to the Internet, so that clients are not aware that their traffic is traversing a proxy.
The Windows Collector supports Integrated Windows Authentication (IWA).
Because the Collector runs as a service under the local system, if a configured proxy requires NTLM authentication, the Collector responds to the challenge with the computer's identity.
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 the 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, the Collector supports the methods described below to configure its proxy settings.
The WinHTTP interface is meant to be used by server applications and system services such as the Collector. It provides proxy settings at the system level and its configuration is stored in the Windows Registry:
To read the proxy settings on a device, type in from the comand 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 /?
The Windows Collector V6.24 already supported WinHTTP services to get the proxy settings. If you are migrating from V6.24, proxy settings will remain unchanged on V6.25 and later.
Starting from version 6.27.2, the Collector takes into account the bypass list set via WinHTTP or Internet Explorer Options in system context. 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 server must match the value you used during the Collector configuration. If you used the DNS name, then you must use it in the bypass list. Same goes for the IP address, if you used it for the Collector configuration 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.com is correct but nexthink.* is not supported. The Nexthink Collector supports as well the following kind of entries 192.168.212* or 192.168.* or 192.* but other products installed on the system might not.
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; therefore, the Collector cannot read them. To make them readable by the Collector, promote the WinINet proxy settings to system level by setting the ProxySettingsPerUser value to 0 in the Windows Registry:
Or by setting the following GPO:
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.
Specify the proxy settings of the 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: Provide manually the address and port of the proxy.
The Windows Collector selects one of the methods to get its proxy settings on a trial and error basis. The Collector tests the validity of each method in sequence: the first method that yields a set of proxy settings which let the Collector connect to the Nexthink Cloud is retained. Methods are tried in the following order until one of them is successful:
Collector custom configuration.
If enabled, automatic proxy configuration through PAC file.
If enabled, manual proxy configuration.
Direct connection without proxy.
Microsoft Windows HTTP Services (WinHTTP).
Microsoft Windows Internet (WinINet) API.
Only if settings are valid at the system level (per device).
Manual configuration.
PAC file referenced by URL (automatic configuration script).
Web Proxy Auto-Discovery (WPAD).
