The KRC window appears, but the remote screen fails to load and you receive either "Connection failed" or "Device is offline" message
When you check the KRC logs, you see this: -
[I2014-10-02T22:11:38.436586+02:00 610] [EndpointConnectionManager] Attempting to connect to wss://<server address>:<port>/kaseya/edge/channel
[I2014-10-02T22:11:38.436586+02:00 22d8] [HttpProxyDiscovererThread] Started
[I2014-10-02T22:11:38.436586+02:00 22d8] [HttpProxyDiscovererThread] Stopped
[E2014-10-02T22:11:38.516620+02:00 2550] [EndpointConnectionManager] Failed to connect to wss://<server address>:<port>/kaseya/edge/channel :
SSL connect error (curl:35)
The error may occur on the viewer or agent side.
Some firewalls (for example, Microsoft Forefront and Palo Alto) have a feature called "HTTPS inspection" or "SSL inspection", which is intended to protect internal client workstations from accessing non legitimate HTTPS web sites.
KRC always uses TLS (SSL) encryption to communicate with the Kaseya server, but the port used will vary: -
- on the viewer side, it will use the same port that is used to access Kaseya web interface. For example, if you connect to the VSA web interface over port 80 (non-SSL), remote control viewer will also use port 80, but the traffic is still encrypted using TLS (SSL).
- on the agent side, KRC uses the same port that the agent uses to "check in" to the Kaseya server (usually 5721)
If the VSA does not have a valid SSL certificate installed, HTTPS inspection or similar firewall features may block KRC traffic, even if SSL is not being used to access the web interface.
Microsoft has an article that explains the implementation on Forefront and a section on "common problems" - http://blogs.technet.com/b/isablog/archive/2009/10/19/common-problems-while-implementing-https-inspection-on-forefront-tmg-2010-rc.aspx
Documentation of Palo Alto implementation can be found here - https://live.paloaltonetworks.com/docs/DOC-1412
We have had reports that if using a Palo Alto device, their current firewall application database has not been updated, for the newer KRC application. To workaround this, open all traffic on 5721 port inbound essentially removing the application security layer completely for all Kaseya traffic until they update database to include the KRC application. (thanks to Jordan Harper for this information).
If the VSA user is behind a firewall with "HTTPS inspection" or similar feature: -
- Add VSA server address to exclusion list for the "HTTPS Inspection" service (refer to firewall vendor documentation for details).
If the problem persists, temporarily disable the "HTTPS Inspection" feature as a potential workaround and to validate the source of the problem. If KRC now starts working, contact the firewall vendor to find out why connections are still blocked with the feature enabled.
If the problem persists after all the above steps, click here for further troubleshooting.