Single external IP, separate nextcloud/collabora VMs

I’ve been banging my head against the wall here for over a week and I can’t seem to figure out what I’m missing here. I have NextCloud up and running and it’s running great. However, when I try to add my collabora instance, this is where it gets messy.

Here’s my setup:
NextCloud Server:

Collabora Server:

How I set it up:
I’m running this from home and I have a single external IP address. I have the appropriate ports forwarded and I don’t think that’s my issue.

For the NextCloud I followed a different walkthrough, but this is what I’m using as a baseline for Collabora:

I used LetsEncrypt and Certbot for the nextcloud server and that worked fine. When I go through the mentioned walkthrough, I make it to the SSL/proxy part and then it all stops working.

I have tried having the proxy info on both the nextcloud server and the collabora server without any success. I believe that I’m going to have to have the proxy stuff on the nextcloud server since that’s the one the router is pointing to directly.

Here’s the .conf file I have on my nextcloud server, and this is a separate conf file from the working nextcloud conf file:

<VirtualHost *:443>
ServerName office.domain.net

SSL configuration, you may want to take the easy route instead and use Lets Encrypt!

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/cloud.domain.net/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/cloud.domain.net/privkey.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.domain.net/chain.pem
Include /etc/letsencrypt/options-ssl-apache.conf

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-S$
SSLHonorCipherOrder on

Encoded slashes need to be allowed

AllowEncodedSlashes NoDecode

Container uses a unique non-signed certificate

SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

keep the host

ProxyPreserveHost On

static html, js, images, etc. served from loolwsd

loleaflet is the client part of LibreOffice Online

ProxyPass /loleaflet https://10.10.2.32:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://10.10.2.32:9980/loleaflet

WOPI discovery URL

ProxyPass /hosting/discovery https://10.10.2.32:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://10.10.2.32:9980/hosting/discovery

Main websocket

ProxyPassMatch “/lool/(.*)/ws$” wss://10.10.2.32:9980/lool/$1/ws nocanon

Admin Console websocket

ProxyPass /lool/adminws wss://office.domain.net:9980/lool/adminws

keep the host

ProxyPreserveHost On

static html, js, images, etc. served from loolwsd

loleaflet is the client part of LibreOffice Online

ProxyPass /loleaflet https://10.10.2.32:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://10.10.2.32:9980/loleaflet

The referenced SSL certificate files are the same ones used by the nextcloud instance.

Thanks a lot for your help!!

From the config you are providing it shows you are using a HTTPS to HTTPS proxy. I would recommend to have Collabora running as HTTP, therefore remove all ‘S’ references in the proxy lines.

For the rest it looks similar to mine and would assume if you have the initial Apache (which runs for NextCloud) handle the certificates you don’t need to use any on Collabora itself.

If anyone is having this issue, I have figured out the problem. I was thinking about this all wrong. I was putting the 9980 proxy file on the proxy server (my next cloud server) when it actually needs to go on the collabora side itself. I’ll write up a how to so that if anyone else is interested in doing this, they can.