SSL termination is the recommended method of encrypting communication between users’ browsers and Guacamole, and involves configuring a reverse proxy like Nginx or Apache to handle strictly the SSL/TLS portion of the conversation with the Tomcat instance hosting Guacamole, handling encrypted HTTP externally while passing unencrypted HTTP to Tomcat internally.
This documentation deals with configuring Nginx to handle SSL/TLS termination for Guacamole, and assumes that you already have an Nginx server properly configured for SSL/TLS, including the necessary private key and certificate. If you have not already done so, be sure to set up both Nginx and Guacamole, confirming that each works properly independently before proceeding.
Proxying Guacamole through Nginx
If Nginx has been configured for SSL/TLS, there should be a
server section within this configuration that defines the certificate and private key used by Nginx, and which requires Nginx to listen on the standard HTTPS port (443). To proxy Guacamole through Nginx such that Guacamole communication is encrypted, a new
location section will need to be added within this
where “HOSTNAME” is the hostname or IP address of the internal Guacamole server.
While a typical proxy configuration for Nginx may only specify the proxy_pass and proxy_http_version directives, Guacamole requires additional configuration due to the nature of the application:
proxy_buffering offdisables buffering of packets sent to/from Guacamole. By default, Nginx will buffer communication between itself and the browser, effectively disrupting the stream of events and updates required for remote desktop. Without disabling buffering, the Guacamole connection will at best be slow, and at worst not function at all.
- The X-Forwarded-For header must be explicitly set to ensure that the IP addresses logged by Guacamole are correct. Without explicitly adding this header, all connections will appear to come from the Nginx server.
- The Upgrade and Connection headers are required parts of the WebSocket protocol. If omitted here, WebSocket will not function correctly, and Guacamole will fall back to HTTP streaming, which is less efficient.
With minor changes to the
location section, Nginx can also be leveraged to change the path used for Guacamole. Doing so requires only changing the path specified for the
location section header, and adding the proxy_cookie_path directive to rewrite the paths of any cookies set by the web application:
Applying the updated configuration
After the above changes have been made, Nginx must be reloaded to force rereading of its configuration files:
If you are using SELinux (the default on both CentOS and RHEL), you must also configure SELinux to allow HTTPD implementations like Nginx to establish network connections:
If Guacamole is not accessible through Nginx after the service has been reloaded, check the Nginx logs and/or journalctl to verify that the syntax of your configuration changes is correct. Such errors will result in Nginx refusing to reload its configuration, or refusing to start up entirely. If you do not see any errors from Nginx, verify that you have configured SELinux to allow Nginx to connect to the network and check the SELinux audit logs (
/var/log/audit/audit.log) for AVC denials.