Collabora with Apache2 backend and Nginx Reverse Proxy?

Hey guys,

As I only have one public IP but several domains, I’m forced to use an Nginx Revrse Proxy that proxies all the HTTPS and HTTP requests. So far so good. The problem is I can’t seem to get Collabora working with the same setup as the other hosts. I would really need some help here.

This are my setups:
NGINX (192.168.4.201)

server {
        # Cloudflare IP that is masked by mod_real_ip

	error_page 404 500 502 503 504 /office-error.html;
        location = /office-error.html {
                root /usr/share/nginx/html;
                internal;
        }
     	set_real_ip_from 103.21.244.0/22;
     	set_real_ip_from 103.22.200.0/22;
     	set_real_ip_from 103.31.4.0/22;
     	set_real_ip_from 104.16.0.0/12;
     	set_real_ip_from 108.162.192.0/18;
     	set_real_ip_from 131.0.72.0/22;
     	set_real_ip_from 141.101.64.0/18;
     	set_real_ip_from 162.158.0.0/15;
     	set_real_ip_from 172.64.0.0/13;
     	set_real_ip_from 173.245.48.0/20;
     	set_real_ip_from 188.114.96.0/20;
     	set_real_ip_from 190.93.240.0/20;
     	set_real_ip_from 197.234.240.0/22;
     	set_real_ip_from 198.41.128.0/17;
     	set_real_ip_from 199.27.128.0/21;

	real_ip_header     X-Forwarded-For;
        real_ip_recursive  on;

        listen 192.168.4.201:443 ssl http2;

        ssl on;
        ssl_certificate /etc/nginx/ssl/techandme/techandme_wild.pem;
        ssl_certificate_key /etc/nginx/ssl/techandme/techandme_wild.key;
#        ssl_certificate /etc/letsencrypt/live/office.techandme.se/fullchain.pem;
#        ssl_certificate_key /etc/letsencrypt/live/office.techandme.se/privkey.pem;
	ssl_dhparam /etc/nginx/sites-available/cloudflare_ip/office.techandme/office-dhparams.pem;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:10m;
        ssl_stapling on;
        ssl_stapling_verify on;

        # Only use safe chiphers
	ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
	ssl_prefer_server_ciphers on;
	
	# Add secure headers
	add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
	add_header X-Content-Type-Options nosniff;
	
        server_name office.techandme.se;
        set $upstream 192.168.4.111;

        location / {
                proxy_pass_header Authorization;
                proxy_pass https://$upstream;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP  $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_buffering off;
                proxy_request_buffering off;
		client_max_body_size 0;
                proxy_read_timeout  36000s;
                proxy_redirect off;
                proxy_ssl_session_reuse off;
        }
}

server {
  listen 192.168.4.201:80;
  server_name office.techandme.se;
  return 301 https://office.techandme.se$request_uri;
}

APACHE2 (192.168.4.111)

 <VirtualHost 192.168.4.111:443>
 ServerName office.techandme.se
 
 # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
 SSLEngine on
 SSLCertificateFile /etc/ssl/techandme/techandme_wild.pem
 SSLCertificateKeyFile /etc/ssl/techandme/techandme_wild.key

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

 # Encoded slashes need to be allowed
 AllowEncodedSlashes On

 # 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://127.0.0.1:9980/loleaflet retry=0
 ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet

 # WOPI discovery URL
 ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
 ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery
 
 # Main websocket
 ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws

 # Admin Console websocket
 ProxyPass   /lool/adminws wss://127.0.0.1:9980/lool/adminws

 # Download as, Fullscreen presentation and Image upload operations
 ProxyPass           /lool https://127.0.0.1:9980/lool
 ProxyPassReverse    /lool https://127.0.0.1:9980/lool
</VirtualHost>

What seems to be wrong here?

Thank you in advance!

Hi,

As I understand, both of your reverse proxies are showing to the same destination.
I think you want to refer the nginx proxy to the apache proxy?
So you just need to refer the nginx proxy to 192.168.4.111:443 (apache) because the apache does the collabora thing.
I am curios if a double proxy works with collabora :slight_smile:

Did you get this working? Is your Collabora/Code a docker image and the Apache running within the Docker?

I am using only apache and using plain old iptables to forward the ports from the external uo to the apache instance back.
So the documentation at the frontpage works in my case.
No the apache is not running inside a dockerimage, only collabora is in one.

@dev0 @Tyler_Collins

In a “normal” situation I run all my VMs in Apache as backends on port 80, and Nginx handles all the SSL requests. In this case both Apache and Nginx must handle SSL as Collabora requires SSL to work properly.

So, What I’m trying to do here is to do a Proxy configuration in Apache and let the Nginx Proxy just forward the traffic from WAN.

I’m not an expert on this, but I got Spreed.ME working when doing like this, and I run a reverse Proxy in Apache on Spreed.ME as well…

Any concrete suggestions on what to do here? Personally I think Collabora is loosing a lot of customers if this isn’t possible.

What do you mean by this? How should a config look like?

And btw, this is how my config looks like: Collabora Online 1.8 with LO 5.1 and new features

if you have all the ssl-work done, a simple

proxy_pass https://192.168.4.111:443;

from the nginx to the apache should do the job. But such a setup is really uncommon.
In that case I don’t think that the collabora guys thought that far. They are working mainly at the docker part of it.

You mean like I did here: proxy_pass https://$upstream;?

Kind of, because you split up the collabora urls in your nginx config which is not required, as your apache already doing that. Afaik you just need to do one proxy_pass with https to your upstream and thats it.

@dev0 Tried that but it doesn’t work… :confused: Hence this post.

I get this: https://office.techandme.se/

Though this works: https://office.techandme.se/hosting/discovery hmmm

collabora work for me since I run the command.

docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=cloud\\.nextcloud\\.com' -e 'username=admin' -e 'password=123456' --restart always --cap-add MKNOD collabora/code

note: run docker container with an user.

@Lars_M Thanks, but are you running it behind a Nginx Reverse Proxy?

yes. it´s behind an Reverse Proxy

Ok, so just to be clear, you have one Apache backend with a Reverse Proxy to localhost, and one Ngnix Reverse Proxy in front of the Apache Reverse Proxy?

no one apache server and one Nginx Reverse Proxy Server.

@Lars_M Interesting, so when you say that you run docker with a user, do you mean a user in Ubuntu or in Nextcloud?

This Container runs with an Ubuntu User.

Look here: https://www.collaboraoffice.com/community-news/code-2-0-updates/

i quote the part:

Updates

Inclusion of Google Noto font family, which aims to support all languages with a harmonious look and feel.
Fixed localization of the menu bar
Improved Writer’s Format menu, including page size and orientation.
New startup options for CODE (requested by user at https://bugs.documentfoundation.org/show_bug.cgi?id=103724).

-e 'username=admin' -e 'password=123456'

in docker command line set the username and password environment variables in container, which will be used by the start-libreoffice.sh script and it sets the username and password for the admin console.

Still doesn’t work… :confused:

I added a user to the system, then I set to use that user when starting the docker image, but no luck.

Anyone that could help me? I would pay for a working setup!