Guacamole Problem



Moin @lebernd,

my thoughts as follows:
He is

  • able to access the UCS-Host (and other services such OwnCloud…) from local network
  • able to access the UCS-Host (and other services such OwnCloud…) from remote network(s)
  • able to access the Guacamole App from local network

He is not

  • able to access the Guacamole App from remote network(s)

The other web-apps (OC,Collabora,…) and the usage of the UCS-WebU won’t require any ReverseProxying - that’s why I evaluated it differently.
now, he maybe check the remote-connectivity of the guacamole app by using the native URI and Port ( http://your-public.dns:40001/guacamole/).
If this works, then I would say the only difference would be the ReverseProxy * thing*

Best regards


That is not true - at least for wordpress. I don’t run owncloud but I think it is dockerized too and uses a proxy config too.


Hello dWc,
Hello lebernd,

I opend port 40001 on the router/FW and a did a connection test to external IP/Hostname (http://public.dns:40001/guacamole/ - This is working, wow :slight_smile:
This is working for http only - https gives me a “ERR_CONNECTION_CLOSED” and is not working at all (yet).

apachectl -M | grep proxy gives me:
proxy_module (shared)
proxy_connect_module (shared)
proxy_http_module (shared)
proxy_wstunnel_module (shared)

apachectl -M | grep headers gives me:
headers_module (shared)

apachectl -M | grep rewrite gives me:
rewrite_module (shared)

@lebernd: Ping to public DNS name works from insides Guacamole-shell.

This my config for the reverseproxy:


<VirtualHost *:80>
	IncludeOptional /etc/apache2/ucs-sites.conf.d/*.conf

	ProxyPass /guacamole/ retry=0
	ProxyPassReverse /guacamole/

	ProxyPass /owncloud retry=0
	ProxyPassReverse /owncloud

	ProxyPass /wordpress retry=0
	ProxyPassReverse /wordpress



<VirtualHost *:443>
	IncludeOptional /etc/apache2/ucs-sites.conf.d/*.conf
	SSLEngine on
	SSLProxyEngine on
	SSLProxyCheckPeerCN off
	SSLProxyCheckPeerName off
	SSLProxyCheckPeerExpire off
	SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
	SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
	SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
	SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem

	#SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

	### To enable special log format for HTTPS-access
	# LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %p" combinedssl
	# CustomLog /var/log/apache2/access.log combinedssl	## with port number

	ProxyPass /guacamole/ retry=0
	ProxyPassReverse /guacamole/

	ProxyPass /owncloud retry=0
	ProxyPassReverse /owncloud

	ProxyPass /wordpress retry=0
	ProxyPassReverse /wordpress


Best regards


Hello @lebernd ,

in that case I’m sorry for my wrong posting. I don’t use one of those additional apps, so I couldn’t check it for myself but you’re right - there’s even a ReverseProxy config entry for the UCS-Portal.

Sorry for miss-information :sob:


looking good in my opinion.


Hello @tpfann,

after first sight, a difference in your configs are the presence or missing of a trailing slash (differnce between i.e. owncloud and guacamole config entry) .

That it works only in HTTP (over this port) is normal as the server your (now) talking to directly - is plain HTTP.
This is a reason for reverse proxying services (in general - in this case the usage of a or multiple dockerized app/s on a single port may be another good reason). The HTTPS connections should end on the Proxy (Apache), which handles the further communication with the guacamole-service in HTTP.

Best regards


Last thoughts for today: perhaps time to call apache :grinning:

You find some posts regarding your error message searching the web.

 [proxy_http:error] [pid 16890] (103)Software caused connection abort: [client] AH01102: error reading status line from remote server

I found this post interesting:

I would try the solution posted there - but this really is just trying something.


Hello lebernd,
thx for the link and your support. I have tried the tips from the post but without any success :frowning:

Best regards


Found the root cause :slight_smile:

Besides default-ssl.conf and 000-default.conf there is another relevant conf file under /etc/apache2/sites-enabled. For the handling of my public DNS names the relevant file is univention-letsencrypt.conf.

After correcting the corresponding entrys for Guacamole (changed https to http), everything is working now.

dWc and lebernd thx alot one more time for your support!

Best regards



just as an explanation: univention-app shell … is a wrapper around calling docker exec … -ti /bin/bash with the ID belonging to the app’s container. That ID in turn is stored in the UCR variable appcenter/apps/…/container.

If you ever want to run something within an app’s Docker container, I highly recommend univention-app shell … over manually looking up the container name/ID — especially as container names aren’t stable; they can and do change between installations.


Keep in mind that your modifications to the files in /etc/apache2/sites-available will be overwritten each time the file is recreated from its template. That’s what the scary-looking text at the front of the file tries to tell you.

A slightly better way to go about things is to modify the template the file is generated from, /etc/univention/templates/files/etc/apache2/sites-available/univention-letsencrypt.conf, and then to re-generate the file with ucr commit /etc/apache2/sites-available/univention-letsencrypt.conf. That way you only have to keep up to date with changes to the template itself, which shouldn’t happen too often (check by running univention-check-templates after each update). Due to how the templates generates the entries, this isn’t as straight-forward as one might like, though.

The best option would be to file a bug for this problem. Each app declares how the web server inside the Docker container can be reached (unencrypted only = HTTP, encrypted only = HTTPS or both), and the Let’s Encrypt template uses that information in order to create its reverse proxy entry. That information seems to be wrong for Guacamole.


Hi Moritz,

thanks for the hint - I will update the template accordingly as well.
As recommend, I have opened a ticket for this: 49243