Reverse Proxy for Connectwise Control

Reverse-Proxy-as-a-Service (RPaaS) can support the reverse proxying of Connectwise Control (both web UI and agent relay traffic). The configuration details can be found below.

Important Notes #

Unlike Automate, Control agent relay server address settings are global — meaning that it’s not possible to test with a pilot group of agents in parallel with normal production. However, since server address changes require a reinstall to take effect, it is possible to validate the new FQDN functionality for a short period before implementing the global change. Please see the official documentation for additional details.

Deployment Model #

The first decision to make is what traffic to proxy. The traditional security concerns stem from the web UI (443/TCP or 8040/TCP), and typically that traffic is always proxied unless existing security measures are in place that ACL that traffic to specific IPs.

Agent relay traffic (8041/TCP) has not traditionally been a security concern for Control, but it can be proxied. However, due to the persistent nature of the connections, changes to the proxy configuration or service restarts (auto-recovery or self-service API) disrupt all sessions — thus it’s not recommended to route relay traffic through the proxy.

Once the deployment model has been determined, please submit a ticket requesting Control be added to the proxy instance (and be sure to include the existing FQDN of the Control server).

Web UI Changes #

Control uses cookies, and scenarios can emerge where the server is expecting the cookie name to be the previous FQDN, but the browser presents a cookie with the proxy FQDN. To correct this, the SameSite attribute needs to be edited.

To make the change, log in to the admin UI, then go to Advanced –> Web Configuration –> Settings, and change the SameSite Cookie Attribute to be none (as shown below):​


Unlike Automate, the SSO for Control will need to be recreated from scratch (if ConnectWise SSO is configured). This is done by deleting the existing SSO provider, and setting it up again as described in the documentation here. SSO will also require the following configuration change before recreating SSO (the same as below if the steps in the relay traffic have been followed):

<add key="WebServerAddressableUri" value="https://1234567890ABCDEF.exampledomain.com/" />

Configuration File Changes #

Please note that the rest of this guide is for agent relay traffic only; it is not required for proxying access to the Control web UI (apart from SSO FQDN changes).

To proxy the agent relay traffic, 3 lines need to be added to the <appSettings> section of the web.config file (normally located at C:\Program Files (x86)\ScreenConnect\web.config ):

<add key="WebServerAddressableUri" value="https://1234567890ABCDEF.exampledomain.com/" />
<add key="RelayListenUri" value="relay://" />
<add key="RelayAddressableUri" value="relay://1234567890ABCDEF.exampledomain.com:8041/" />

 Be sure to update the address to match your proxy above, and please note that the last line is NOT https://. ​

Testing #

At this point, reinstall one Control agent from the Access page, and after the reinstall is finished verify that you can still access it (if there are issues revert the configuration). Once you’ve verified that access is working via the proxy then you can reinstall the rest of your agents to make them communicate via the proxy.

It’s possible to validate that the new agent relay configuration is in production by reviewing the executable path in the service properties: