Guacamole Problem

Well, you can take a look at this post. But I’m not sure if it helps a lot. Guacamole is working as it is supposed to on a member-server while it didn’t on a slave-server.
But I can’t really tell if this has something to do with server roles or the other apps that are installed on the slave (I mentioned samba4 but perhaps the mailserver and anti-virus are even more relevant - some indications towards this can be found with a web search).

Hello lebernd, thank you for your feedback!

But I’m not sure how this can be helpful in my situation.
Like for the other official apps from the UCS appstore, my expectation was that it can be deployed easily without any further manuel adjustments or configuration. There were also nothing mentioned about excepetions (server role) or any other preconditions.

To spend further efforts for investigations/troubleshooting doesn’t makes sense for me, for the time being I’m only interested in how to do a “clean” uninstall.

Curious if you managed to get Guacamole working?? I’ve been fighting with it for three weeks off an on and I cannot get a simple RDP connection to work, SSH connections allow me to log in but returns nothing after authentication.

It seems there are way more problems posted than solutions so If it’s just not a working package I’ll remove it and find something else.

Thanks.

Hi,
Guacamole is still not working here (broken LDAP connection) and it seems nobody is able/willing to support here :frowning: I gave up already …

Hi,
I don’t know if this may help you to solve your problem, but my reverse proxy entries in the files
default-ssl.conf and 000-default.conf looks like:

    ProxyPass /guacamole/ http://127.0.0.1:40001/guacamole/ retry=0
    ProxyPassReverse /guacamole/ http://127.0.0.1:40001/guacamole/

…both entries with a / (slash) at the end

For the rest - running guacamole (0.9.13-univention14) installed from the app-center on a (standalone) UCS as Domain Master and after app install it worked (more or less) out-of-the-box.
Installed apps:

  • AD-DC
  • RADIUS
  • Guacamole
  • Software Installations-Monitor

As I’m running the whole “thing” as a VM - snapshoting while playing arround with guacamole may have saved me, because:
Once I had all up and running (inclusive adding Session-Configs in the LDAP tree “guacamole”) no connection entry worked - every try ended up in a black screen - SHIFT/STRG/ALT allows to leave the session but nothing more.
Long story short - the root problem for me, was that the docker network connector guacamole_default didn’t work as expected - removed both guacamole docker container from there and added them to the default bridge network. Everything fine since then.

Good luck

Hi @dWc,

I’m also still fighting with this docker-app and my best guess so far was that there is something wrong with the docker networking of guacamole. It installs a new bridge but I can’t ping a LDAP server (install on a member server) on the network from it so I’m wondering how a user would be able to be identified…
Long story short - can you make your short story long and give some hints/ commands on how to attach the containers to docker0? :pray:

Thanks,
Bernd

So I provide my answer…
What I did to connect the guacamole docker containers to the default docker bridge:

root@ucs-member:/var/lib# docker network connect bridge guacamole_guacd_1
root@ucs-member:/var/lib# docker network connect bridge guacamole_guacamole_1
root@ucs-member:/var/lib# docker network disconnect guacamole_default guacamole_guacd_1
root@ucs-member:/var/lib# docker network disconnect guacamole_default guacamole_guacamole_1
root@ucs-member:/var/lib# univention-app restart guacamole

So far so good. That solved the issues described in this thread.

Next problem, and probably after some reading under https://docs.docker.com/network/network-tutorial-standalone/#use-user-defined-bridge-networks one reason why there is a user-defined bridge, is the following error, when I want to use a defined connection:

root@ucs-member:/var/lib# docker logs -ft --details guacamole_guacamole_1
...
2019-03-28T21:35:37.077055728Z  22:35:37.076 [http-nio-8080-exec-6] ERROR o.a.g.s.GuacamoleHTTPTunnelServlet - HTTP tunnel request failed: java.net.UnknownHostException: guacd: Name or service not known
...

I managed to get around this by editing /etc/hosts inside the guacamole container. But I’m not sure if this solution will even survive a restart.

Guacamole is working again, but I don’t think that this is a stable solution.

At least the guacamole_default bridge needs some repair from the maintainer I guess.
In univention bugzilla you can find a bug I think is related: Multicontainer apps use arbitrary network, database access issue, possible address conflicts

Best regards,
Bernd

Hello @lebernd,
as you already mentioned, I think the point is this guacamole_default docker bridge. A docker network inspect guacamole_default didn’t show up any Options:

        "Options": {

as i.e. the default docker bridge does:
docker network inspect bridge:

        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"

in order to remove an apply them to the default docker bridge i did the following (in this order):

docker network disconnect guacamole_default guacamole_guacamole_1
docker network disconnect guacamole_default guacamole_guacd_1
docker network connect bridge guacamole_guacd_1
docker network connect bridge guacamole_guacamole_1

I never restarted any docker container from the console - for this i always used the web-ui for starting/stopping guacamole app.
I never touched the /etc/hosts file.

What works:
*Logging into Guacamole “Website” using https://ucs-server.domain/guacamole/#/ with any user (or user, member of defined AD-Group) allowed to
*Using defined connections (RDP - Domain Auth / SSH Username/Password-Auth)
What doesn’t work (actually):
*Passthrough/or SSO in Order to use defined connections WITHOUT having to define the credentials inside the ldap object (don’t know if this ever was intended - but would be pretty cool :wink:)
*Using SSH Connections with Public Key Authentication as there must be some miss-interpretation while reading the private key and/or passphrase from the ldap object (defined there as parameter private-key= and passphrase=)

Grüße und viel Glück :four_leaf_clover:

Debug-Info:
While debugging the initial problem I ended up tcpdumping on the host (ucs domain controller) and another webserver (same subnet as the DC and domain member).
The strange thing was, that even with the “broken” guacamole_default docker network in use, requests have been kind of forwarded/NATed from the host BUT on the destination host the requests shows up comming from the docker container IP (172.17.0.x). tcpdump showed all requests with checksum-errors.
As far as I understand, the requests should have been NATed on the host into the hosts IP-address.
This way no responses from the targeted server were possible, as this server doesn’t even know about the existence of the docker network (172.17.0.0).
This problem was solved (for me) by using the default docker bridge network

1 Like

Hi dWc,

both “docker network inspect guacamole_default” and “docker network inspect bridge” as well does not have any options configured.

docker network inspect bridge
[
{
“Name”: “bridge”,
“Id”: “260b334b18a5c3f7061efadbf623af5e937b2d0361f452a8365874c8bc9a6752”,
“Created”: “2019-03-08T11:39:02.057674856+01:00”,
“Scope”: “local”,
“Driver”: “bridge”,
“EnableIPv6”: false,
“IPAM”: {
“Driver”: “default”,
“Options”: null,
“Config”: [

Do I need to edit the config file first as shown above in your last post? Where is the config file located?

@lebernd: What is the content of your hosts file now?

thx and best reagrds
Thomas

I just added a line in guacamole /etc/hosts

docker.ip.of.guacd        guacd

Hi, thx for your quick reply.

I was able to find out the IP of my docker host but I wasn’t able to figure out the according IP for guacd.
Also I was not able to run a “univention-app shell” for guacd - is this even possible?

Do you have another hint for me?

Okay, found out the correct IP myself and edited the hosts file accordingly :slight_smile:

And thanks to your instructions above Guacamole is working now - at least for SSH.
For RDP-connections it still gives me an error (The remote desktop server is currently unreachable).

This was really a big step forward … thanks to the support given here, Guacamole is now working localy (including RDP connections).

What is still not working is to access Guacamole via my external IP or DNS name (502 Proxy Error). Currently access to Guacamole is only possible via my internal IP or local hostname :frowning:

default-ssl.conf and 000-default.conf both looks like:
ProxyPass /guacamole/ http://127.0.0.1:40001/guacamole/ retry=0
ProxyPassReverse /guacamole/ http://127.0.0.1:40001/guacamole/

What else can I check?

Hello,

@tpfann
I’m an absolute docker newbie (most infos comes from here), so maybe I’m wrong, but
about the docker network bridge options:

        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"

if you haven’t configured anything as you quoted, then the problem could be, that there
is no communication possible between your client and the server.
For better understanding:

  • Can you access UCS/Guacamole from your local network?
  • How do you access - by ip or by dns?
  • What do you mean with “external IP or DNS”? Public?
  • Can you access UCS with “external IP or DNS”?

Best regards

Thanks @lebernd for the hints posted here - didn’t find time to try them, yet :smile:

Hello dWc,

thx for your feedback!

Yes - Gucamole can be accessed by using local IP or local hostname (e.g. https://192.168.0.x/guacamole/#/ or https://UCS-Server-Name/guacamole/#/)

All of my other hosted services, like WordPress, Kopano or ownCloud are also reachable via my public IP or public DNS-names (e.g. https://remote.domain-name.de/).

In order to enable secure connections, I’m using a LetsEncrypt certificate.

Best regards
Thomas

Hello Thomas,

Are the other services as WordPress or OwnCloud running as docker applications too?
If they are running native on the System (and I really think they do) this could explain why these services are working.
As you get a “502 Bad gateway”, from the communication point of view, at least you are accessing the destination (ucs-)host, but then something doesn’t work as it should.
Are you using the UCS-Firewall? (just guessing :grinning:)

Added:
Could you check your Apache Logfiles while accessing from local network against them from accessing by pub-ip/dns (you are checking them from outside your LAN, right?)

Best regards

Hello dWc,

in total I have 4 services running as a docker application:

CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS              PORTS                                           NAMES
5014241cbd6b        docker.software-univention.de/collabora:4.0.1.1                         "/bin/sh -c 'bash ..."   4 weeks ago         Up 4 weeks          0.0.0.0:9980->9980/tcp                          nervous_yalow
5410a67a9644        docker.software-univention.de/owncloud_appliance:10.0.10-1              "/usr/bin/entrypoi..."   5 weeks ago         Up 4 weeks          0.0.0.0:40007->8080/tcp                         heuristic_galileo
a120fd92459a        docker.software-univention.de/guacamole-guacamole:0.9.13-univention13   "/opt/guacamole/bi..."   6 weeks ago         Up 4 days           0.0.0.0:40001->8080/tcp                         guacamole_guacamole_1
64269927899f        docker.software-univention.de/guacamole-guacd:0.9.13-univention13       "/usr/local/sbin/g..."   6 weeks ago         Up 4 days           4822/tcp                                        guacamole_guacd_1
3a17a7345eac        docker.software-univention.de/wordpress:4.9.4                           "docker-entrypoint..."   10 months ago       Up 2 weeks          0.0.0.0:40002->80/tcp, 0.0.0.0:40003->443/tcp   sharp_williams

All of them were deployed via the UCS-Appcenter.
UCS-Firewall is enabled by default … I guess?!

When I try to access from outside (public DNS) I get this entry in Apache error.log:

[Sat Apr 06 08:16:49.560979 2019] [proxy_http:error] [pid 27496] (103)Software caused connection abort: [client 80.187.85.226:30770] AH01102: error reading status line from remote server 127.0.0.1:40001
[Sat Apr 06 08:16:49.561106 2019] [proxy:error] [pid 27496] [client 80.187.85.226:30770] AH00898: Error reading from remote server returned by /guacamole/

When I access from inside (local IP) I get this entry in Apache access.log:

192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/ HTTP/1.1" 200 5712 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/app.css?v=0.9.13-incubating HTTP/1.1" 200 8365 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/api/languages HTTP/1.1" 200 402 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "POST /guacamole/api/tokens HTTP/1.1" 403 520 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/translations/en.json HTTP/1.1" 200 31675 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/translations/de.json HTTP/1.1" 200 35904 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/images/logo-64.png HTTP/1.1" 200 5615 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
192.168.0.42 - - [06/Apr/2019:08:26:58 +0200] "GET /guacamole/api/patches HTTP/1.1" 200 460 "https://192.168.0.3/guacamole/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"

thx and best regards,
Thomas

Hello tpfann,

first, sorry for my maybe weird questions - as I’m only using Guacamole and RADIUS as additional apps I falsely assumed, that only Guacamole runs as docker app.

About the firewall - I didn’t configure anything regarding firewall settings on the UCS (all default), but it looks like that it’s enabled by default - here they say:

In the default setting, all incoming ports are blocked by the UCS firewall.
univention-firewall is a set of rules for iptables. 

In fact, there are IPTables rules defined (I guess they are auto-generated when installing an application). Specially the entries in the FORWARD Chain for the docker network (iptables -L -v -n):

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

and the NAT entries (iptables -L -v -n -t nat):

Chain POSTROUTING (policy ACCEPT 26731 packets, 2076K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:8080

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40001 to:172.17.0.3:8080

172.17.0.3 is the ip-address of the guacamole web-interface-container
Could you check these rules? Maybe there is something what’s restricting the access to the reverse-proxy to your local subnet.

For explanation: The ReverseProxy configuration for Guacamole is required as the app should be accessible through default-ssl port (443).
i.e. https://ucs-host.your-domain/guacamole
and not
http://ucs-host.your-domain:40001/guacamole

Best regards

Hello dWc,

thanks alot for spending all these efforts and having a look at my Guacamole issues :slight_smile:

iptables -L -v -n (looks identical to yours):

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 5952 1264K DOCKER-ISOLATION  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 3350  784K DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
 3262  775K ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 2602  479K ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
    5   300 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

iptables -L -v -n -t nat (here are some differences):

Chain POSTROUTING (policy ACCEPT 83270 packets, 8593K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1164 86056 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.1           172.17.0.1           tcp dpt:9980
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.2           172.17.0.2           tcp dpt:8080
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.5           172.17.0.5           tcp dpt:8080
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:443
    0     0 MASQUERADE  tcp  --  *      *       172.17.0.3           172.17.0.3           tcp dpt:80

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
 9348  561K RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9980 to:172.17.0.1:9980
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40007 to:172.17.0.2:8080
    **5   260 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40001 to:172.17.0.5:8080**
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40003 to:172.17.0.3:443
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:40002 to:172.17.0.3:80

In my understanding (I did a mapping between “docker network inspect bridge” and “docker ps”):

  • 172.17.0.1:9980 belongs to Collabora
  • 172.17.0.2:40007 belongs to ownCloud
  • 172.17.0.3:40002 and 40003 belongs to WordPress
  • 172.17.0.4:4822 belongs to guacd
  • 172.17.0.5:40001 belongs to guacamole

Assuming that 172.17.0.5 belongs to Guacamole the above FW and NAT rules seems to be okay - right?

Best regards
Thomas

Hello again,

no problem :smile:
You correctly assume, your iptables rules looks okay.
Could you increase the LogLevel of the Apache-Server:
/etc/apache2/apache2.conf

#LogLevel warn
LogLevel debug

Maybe there’s more helpfull information

Best regards

Mastodon