Issues using Caddy to Proxy to Guacamole

Help
1

Hi everyone,

I originally had an Apache2 server that I was using as a proxy to various internal sites. That server was being decommissioned, and I decided to use Caddy this time around. 5 out of 6 HTTPS sites are working perfectly, but I’m having issues with Guacamole. The page loads, and I am able to log in, but once I attempt to start an RDP, VNC, or SSH connection, it disconnects almost immediately.

On the original proxy server (apache2) the virtual host config was as follows:

<VirtualHost *:443>

    ServerName remote.example.com

    # SSL Config
    SSLEngine On
    SSLProxyEngine On
    SSLProxyVerify none 
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off
    
    # Proxy
    ProxyPreserveHost On
    ProxyPass / https://10.0.50.149:443/ flushpackets=on
    ProxyPassReverse / https://10.0.50.149:443/

    # Certs
    SSLCertificateFile /etc/letsencrypt/live/remote.example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/remote.example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/remote.example.com/chain.pem

</VirtualHost>

On the new Caddy server, the caddyfile contains:

https://remote.example.com {
	import common.conf
	proxy / https://10.0.50.149:443 {
		insecure_skip_verify
		transparent
	}
}

Here is the contents of the “common.conf” file:

gzip
ipfilter / {
	rule allow
	ip 10.0.50.0/24
	ip 10.0.20.0/24
	country CA US
	database /opt/caddy/GeoLite2/GeoLite2-Country.mmdb
	blockpage  /var/www/static/access_denied.html
}

I tried adding a few different options nested under proxy, with no success:

header_upstream X-Real-IP {remote}
header_upstream Host {host}
header_downstream X-Real-IP {remote}
header_downstream Host {host}

I was wondering if anyone can offer any insight as to what might be different between the apache and caddy configs. One thing I can’t seem to find any information on is the “flushpackets=on” parameter.

Thanks

2

I think Guacamole wants a websocket. Try:

	proxy / https://10.0.50.149:443 {
		insecure_skip_verify
		transparent
		websocket
	}
3

Hi, thanks for the suggestion, but it didn’t work. I even pointed the the caddyfile to the original port advertised by Tomcat (8080):

https://remote.badin.network {
        import common.conf
        proxy / http://10.0.50.149:8080/guacamole/ {
                insecure_skip_verify
                transparent
                websocket
        }
}
```

After some further digging, I found the manual for Guacamole.It looks like for Apache, the "proxypass" needs to have the following option turned on:

```
flushpackets=on
```

For Nginx, the equivalent appears to be:
```
proxy_buffering off
```

Does Caddy have anything like this?
4

Hmm. Definitely doesn’t need it. I’ve just written up and deployed a Guacamole instance, here are my configs:

→ cat docker-compose.yml
version: '2.1'

services:
  guacdb:
    image: mariadb:10
    volumes:
      # docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > initdb.sql
      - ./initdb.sql:/docker-entrypoint-initdb.d/initdb.sql
      - ./guacdb:/var/lib/mysql
    environment:
      # `date | md5sum`
      MYSQL_ROOT_PASSWORD: 16ce20fc37d15a4f272074967c0c3002
      MYSQL_DATABASE: guac
      MYSQL_USER: guac
      # `date | md5sum`
      MYSQL_PASSWORD: 54e0ba1cb2b4f643ab2fae94433e046e
    restart: always

  guacd:
    image: guacamole/guacd
    depends_on:
      - guacdb
    restart: always

  guacamole:
    image: guacamole/guacamole
    depends_on:
      - guacd
      - guacdb
    environment:
      MYSQL_DATABASE: guac
      MYSQL_USER: guac
      # `date | md5sum`
      MYSQL_PASSWORD: 54e0ba1cb2b4f643ab2fae94433e046e
      GUACD_HOSTNAME: guacd
      MYSQL_HOSTNAME: guacdb
    restart: always

# web_default belongs to a docker-composed Caddy instance, for ease of proxying:
networks:
  default:
    external:
      name: web_default

→ cat Caddyfile
import /etc/vhosts/*.caddy

→ cat guacamole.whitestrake.net.caddy
guacamole.whitestrake.net {
    rewrite / /guacamole
    proxy /guacamole guacamole:8080 {
        transparent
        websocket
    }
}

Site is available at https://guacamole.whitestrake.net (for the time being).

I have tested an RDP session to a Windows 2012 r2 server, I was able to keep the connection open for at least 15 minutes before I logged off as I definitely don’t seem to have the same issue as you’re describing.

Only thing I can think of is that I handle the path (/guacamole) a little differently than you do.

1 Like
5

To answer this one - no, I don’t believe it does have a setting for this. But I don’t think Caddy suffers from the issue described by the Guacamole manual to begin with, as demonstrated by my above example.

6

Thanks for taking the time to get all of that set up, I really appreciate it. I tried modifying my caddy file to match yours:

https://remote.example.com {
        import common.conf
        rewrite / /guacamole
        proxy / http://10.0.50.149:8080 {
                transparent
                websocket
        }
}

However, I get the same result. At this point, it looks like the problem may be how my Guacamole instance is set up. I’ll rebuild it from scratch and report back.

7

I’ve built my new Guacamole VM (CentOS7). I am using Guacamole version 0.9.12. Guacamole is available and working on port 8080. On my proxy server, I’m using the following caddyfile:

https://remote.example.com {
        import common.conf
        rewrite / /guacamole
        proxy / http://10.0.50.15:8080 {
                transparent
                websocket
        }
}

When I connect directly to the Guacamole server, on port 8080, I am able to use RDP without any disconnections. However, once I use the proxy server to access Guacamole, the connection times out after 5-15 seconds.

8

Add timeouts none to your Caddyfile; this won’t be needed after the next release.

1 Like
9

Thanks Matt, that fixed it.

1 Like
10

Huh. Just double checked the version of Caddy running in my containers. It’s 0.9.3, which explains why I don’t need that…

Maybe I’ll wait until next release to update them, seems to be running just fine in the meantime. :slight_smile:

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.