Reverse Proxies

If running Kasm behind a reverse proxy such as NGINX, please consult the Reverse Proxy Guide The reverse proxy used, must support WebSockets, and the Zone configuration must also be updated accordingly.

If users can access the Kasm Workspaces UI, but cannot connect to a session, then run through the advanced connection troubleshooting steps.

If users are not able to access the Kasm Workspaces UI at all, the first step would be to ensure that Kasm Workspaces is accessible directly, without going through the reverse proxy. Next, ensure that from your reverse proxy you can curl Kasm Workspaces.

curl -k https://<ip-address>:<port>/api/__healthcheck
{"ok": true}

Replace <ip-address> with the IP address of one of your Kasm WebApp servers and <port> with the port that Kasm Workspaces is listening on, by default that is 443. Repeat this test for all WebApp servers and on all reverse proxies you have in front of Kasm Workspaces.

If you are able to access Kasm Workspaces directly and you are able to curl Kasm Workspaces from the reverse proxy, but you still cannot load the UI at all when navigating to the domain-name or IP address of the reverse proxy, then consult the documentation of your reverse proxy.

Warning

If you are using the RDP local client workspace option, make sure the Restrict RDP Client IP Address setting is disabled in Infrastructure / Zones. If it isn’t may not be able to connect, as the IP stored with the request will differ due to the connection being over a reverse proxy. If this is the case it will be reported in the Error Logs with a message such as “Invalid Request. Wrong client IP.”

RDP Session Disconnects

Reverse proxies and load balancers have settings that will timeout requests after a failing to get a response from the upstream server in a period of time. This can result in Kasm desktop/app sessions disconnecting if the user is not actively using the session. Container based sessions send a keep-alive every 5 seconds, therefore, most container based sessions will be unaffected. This issue primarily affects sessions brokered by the Kasm RDP HTTPS Gateway. By default, RDP does not send a keep-alive, therefore, RDP connections being proxied can get disconnected if the user is inactive for a time longer than reverse proxies in the path allow. Kasm NGINX servers use a proxy_send_timeout and proxy_read_timeout value of 3600 seconds, or 1 hour. The default setting for both is 60 seconds for NGINX. RDP does support sending keep-alives, with a registry setting. Either all proxies in the path need to set a non-default proxy_send_timeout and proxy_read_timeout that is long enough to allow for normal inactivity during an RDP Session, or keep-alives needs to be enabled using the registry setting.

The proxy_send_timeout and proxy_read_timeout are NGINX directives, if you are not using NGINX in front of Kasm, you will need to consult the documentation for the reverse proxy or load balancer you are using. Each vendor has different defaults and different terminology. For example, the Azure Application Gateway has a very short default value of 20 seconds for its request time-out setting.