Reverse-Proxy-as-a-Service (RPaaS) is a security service for Automate servers offering network layer security hardening. The documentation below describes how to implement the reverse proxy.
Deployment Model #
The first decision to make is how to implement the proxy. There are two common models:
- All traffic: Both Control Center and agent traffic pass through the proxy (good for partners without existing ACLs or hardening)
- Agent only: Only agent traffic passes through the proxy (good for partners with existing ACLs)
Deployment models can be mixed and matched; it’s quite possible to have a proxy that allows all agent traffic plus Control Center traffic from trusted IP addresses. However, it’s useful to determine what traffic to proxy and how it will interact with existing security measures before implementation.
Configuration Changes (optional) #
By default, all parts of the Automate application are accessible via the proxy, and no additional countries are allowed in the GeoIP configuration. If the desired deployment model is different or additional countries are needed, please submit a ticket requesting the changes.
Template Settings #
Once the proxy instance is provisioned, an FQDN will be supplied (ex. 052d3c3287c38201.exampledomain.com). To let agents use the proxy, it must be configured as the server address in an agent template.
Important: When configuring the agent templates, leave the existing server address as a secondary address (see screenshot below). This will allow for failover in the event of an upstream disruption to the proxy service (see the Firewall ACLs section below for more details).
Caution: It is highly suggested to create a new template for initial testing when configuring the proxy. Improper formatting in the default template can cause global communication loss with agents and can be difficult to correct.
To verify that the agents are using the proxy address, Process Explorer (running as Administrator) can be used to watch the outbound TCP connections to verify that they are going to the proxy public IP address (a restart of the agent service is required):
VPN Configuration – UDP Traffic (optional) #
RPaaS supports UDP traffic via a VPN connection between the instance and the Automate server (the Automate server receives a software client that dials out to the proxy instance). This is not enabled by default; if this functionality is desired for Automate heartbeat traffic, please submit a ticket to support.
To configure Automate to use the proxy for UDP traffic, the redirector address must be changed to point to the RPaaS instance in the dashboard. Please note that this is a global setting and has implications for CW SSO; we advise waiting until agent testing has been completed before modifying this setting.
Additional details about VPN configuration can be found here.
Testing #
Once the proxy instance has been provisioned and configured, it’s time to test it. The primary objectives are to verify that the performance of the web/desktop clients is still adequate and that agents can communicate correctly (and that GeoIP/TLS/IPS settings are tuned as needed).
Additional configuration #
SSO #
For partners using SSO for Automate, the proxy FQDN will need to be added as an alternate FQDN in ConnectWise Home for authentication to work (any CORS errors in the browser console indicate an FQDN mismatch). Please see the documentation for changing FQDNs here.
Agent Deployment #
Certain proxy ACLs (such as agent-only configuration) can impact common methods of agent deployment. Workarounds are available in these scenarios, and the documentation can be found here.
Cutover / Firewall Rules #
After the trial period, assuming that all testing has been successful, it’s time to configure the technical controls to force traffic through the proxy. At this point, other agent templates should be configured with the proxy address (with the existing server as a secondary address). Time will be required for all agents to receive the new template settings.
Once the template settings have propagated, it’s time to edit the NAT rule for inbound traffic to the Automate server. It should be configured to only allow traffic from the source IP of the proxy instance.
In an emergency scenario, this source IP restriction would be removed, and this would allow agents to communicate with the server directly again (as long as the regular FQDN is the secondary address in the agent template).
Troubleshooting #
The first step when troubleshooting is to isolate the issue. The common causes of communication issues are GeoIP settings, TLS hardening, and IPS false positives.
If the issue is across an entire site, it’s likely the issue is GeoIP or IPS settings. These issues will need to be fixed in the proxy configuration, but several tools can be used to check the country code of an IP address to verify if that is the issue. It’s also possible to see agents not communicating at a site of the firewall has outbound rules with the IP/FQDN of the Automate server hardcoded — and this can be easily fixed by updating the ACL in the firewall to include the proxy.
To isolate if an issue is application layer or network layer the following PowerShell can be used to test communication:
Test-NetConnection -ComputerName 052d3c3287c38201.exampledomain.com -Port 443If there’s only one agent that’s not communicating then TLS hardening is likely the issue. This problem can be addressed on the device itself, but it’s also possible to configure the proxy to accept legacy connections (and to configure agents to try on the more secure channel first, then fall back).
Client TLS settings can be difficult due to the nature of the .Net framework (where OS settings can impact application behavior). The protocol needs to be present/enabled, and the application then needs to choose it. The PowerShell below will show available SSL/TLS versions on a system:
[enum]::GetNames([Net.SecurityProtocolType])If TLS12 is in the list, then the issue is with the OS settings, and there are registry keys that can be set. More details on what version of SSL/TLS is used and how to control them can be found here.
When submitting tickets for communication issues, please include the public IP of the impacted devices wherever possible.
