Reverse-Proxy-as-a-Service (RPaaS) can support the reverse proxying of the Connectwise ScreenConnect web interface (not relay traffic). The configuration details can be found below.
Important Notes #
ScreenConnect has two network services (the web UI and the relay traffic) that default to the same FQDN. The relay traffic should not be proxied (as it can cause interruption to remote sessions), so part of the proxy implementation process is separating the two services into two different FQDNs.
There are a number of ways to achieve the desired configuration, but the most efficient would be configuring a new relay FQDN (official documentation here). The relay FQDN is configured when the remote agent is installed, so this change must be made and propagated so the remote agents can update before modifying the original FQDN. Please see the section below on updating the relay address.
Deployment Model #
The first decision to make is the FQDN to be used with the proxy. The existing name can be used (requires a new relay FQDN), a new name can be used (impacting CW SSO), or a random FQDN can be generated (also impacts CW SSO).
Once the deployment model has been determined, please submit a ticket requesting ScreenConnect be added to the proxy instance (and be sure to include the existing FQDN of the ScreenConnect server, along with the desired deployment model).
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):
SSO #
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/" />Relay FQDN updating #
Please note that the rest of this guide is for agent relay traffic only; it is not required for proxying access to the ScreenConnect web UI, and under normal scenarios, relay traffic should not be proxied.
To proxy the agent relay traffic, 2 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="RelayListenUri" value="relay://0.0.0.0:8041/" />
<add key="RelayAddressableUri" value="relay://relay.yourdomain.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 ScreenConnect 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. [Note: a mass reinstall happens when patches are applied to ScreenConnect, so we suggest installing a patch once the configuration is tested and known to be working to expedite the reinstall process.]
It’s possible to validate that the new agent relay configuration is in production by reviewing the executable path in the service properties:
