Setting up Nextcloud behind nginx as reverse proxy

[kosta]

Hello,

I'd like to ask for some assistance in this matter please.
I've searched the forums for similar material, but I'm at a loss.
The reason why I'd like to use nginx as reverse proxy is that it offers WAF, and I can implement a Layer7 security, even if I currently have no idea really what to do - but keen to learn. Anyways...

Nextcloud is installed on Ubuntu server. Deployed with the server itself, via snap.
OPNsense is installed on a hardware device and is connected directly to internet.
I use Cloudflare as DNS.

So I installed the nginx addon, and looked here:
https://docs.opnsense.org/manual/how-tos/nginx.html
and here:
https://forum.opnsense.org/index.php?topic=19305.0
and here:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies

So I tried setting it up:
Configured Nextcloud to accept HTTP at port 7444, HTTPS at port 7443, self-signed cert. Connect via HTTPS, confirm cert error, -> OK
Also tested port forwarding -> OK
Then I entered into the config.php file:
  'trusted_domains' =>
  array (
    0 => '192.168.110.6',
    1 => 'nextcloud.domain.com',
   ),
...
   'trusted_proxies' => array('192.168.110.254'),

.6 is the nextcloud server, .254 is the firewall (it's actually a VLAN).

I also set up Cloudflare DNS to point to my WAN IP for nextcloud.domain.com.
I also have a second entry in DNS, call it firewall.domain.com, which is the FQDN of the OPNsense.

And then on with the OPNsense setup:

Added upstream server: 192.168.110.6, 7443, 1
Configured Upstream: server entry = the above entry, weighted round robin, enable TLS unchecked, uncheck TLS: verify certificate (self-signed on NC)
Location: URL pattern /, match type none, URL rewriting nothing selected. Rest is default, upstream servers: previous step.
HTTP Server:
HTTP Port empty
HTTPS Port 7443
Server Name: nextcloud.domain.com
Locations: previous step
URL Rewriting Nothing selected
TLS Certificate: my *.domain.com wildcard certificate.
Rest is default afaik.

And now, if I try to access: https://nxtcld.domain.com:7443/

Nothing. Zip. Nada.
It's not the firewall, ports are open.
Nothing in the log of nginx.

However, here's one thing: if I attempt to access the FQDN of the firewall (firewall.domain.com), I get untrusted domain, so apparently there is an answer from the nextcloud at port 7443.
But: why does it answer at firewall.domain.com and not at nextcloud.domain.com?

Also discovered another thing: if I then enter firewall.domain.com into trusted_domains, I get no answer any more. Vice versa too, if I remove nextcloud.domain.com from trusted_domains, I get untrusted domain message.

So, I am really not sure who's at fault here. Is it wrong nextcloud config or is it OPNsense/nginx?

Can someone help a little please?

[galmiklos]

Hi kosta,

It looks like I have the exact same setup, and it doesn't work for me either, but a different way, but later about that.

When you connect to your Nextcloud locally, isn't the URL something like this?

https://192.168.110.6:7443/nextcloud

If you connect to https://nxtcld.domain.com:7443/, you are going to be forwarded to the "root" of your Web server, and perhaps you don't have a default index.html there. I kept the default apache2 ubuntu index.html in my web root, so I get that.

https://www.gyalogkakukk.net

I wonder, if you add "nextcloud" to the URL you are connecting with, would you have the same problem I have, which is that the browser will just hang there, and eventually times out, with "We can’t connect to the server at ..." (in Firefox).

P.S. I am in the process of replacing my Sophos UTM 9 with OPNsense, and since this nginx reverse proxy didn't work, I re-connected my old Sophos firewall, so right now my nextcloud works.

Regards,
Miki.

[kosta]

I dumped nginx. I have it running via HAproxy now, and all is well. I only access Nextcloud over it's own FQDN, no IP. NAT reflection is on.

[galmiklos]

Huh! I came to the same conclusion, and just started experimenting with HAproxy. 

Is my understanding correct, that I don't necessarily have to create any condition and rule, I can just have a "real server", "backend pool", and "public service" without any rule? The terms I use may be different in older HAproxy versions, I just upgraded to the latest (os-haproxy-3.3). At least the documentation does not always match what I see in the GUI.

About NAT reflection. I access my nextcloud the same way, always using the public FQDN, even if I'm home, but it is possible to connect to nextcloud locally, just to test if it works at all. I have to mention, my Web server is not secured, so my nextcloud locally is accessed with simple http. I let the firewall add TLS. I believe it would be option #3 at https://docs.opnsense.org/manual/reverse_proxy.html#tls-offloading-downstream-is-tls-protected-upstream-is-plain.

[kosta]

I believe you need both rules and conditions, I have both.
However, I think it also depends on the nextcloud config file, I think you need to set trusted_domains and such. Otherweise it doesn't work.

[galmiklos]

I didn't see any secrets in haproxy.conf, so I hope I'm not asking too much. Could you post yours, or send it in a private message, please?

[galmiklos]

Gaah! It's not the reverse proxy I am having problem with, but the firewall rules.

I guess I am spoiled by Sophos, which creates all needed firewall rules when you set up a reverse proxy (they call it Web Server Protection), and I did not create any rule. :-/

Also, I thought "NAT reflection" was an automatically working thing, but I can see there are more to it, too. I am now reading the documentation how to configure it.

[galmiklos]

Well, of course a firewall rule was missing (port 443 on the WAN interface), but after all, it looks like there was nothing to do with NAT reflection, I still have all three reflection related options off under Firewall->Settings->Advanced.

There was another thing I didn't think of, though. I mentioned it in an earlier post, that I have an unsecure server, and I secured it by enabling "SSL offloading" in the Public Service settings. However, I still had that strange behavior, that I only could connect to the root of my web server. When I added "nextcloud" to the URL, it was just hanging.

Well, what happened was that nextcloud immediately forwarded me to its index.php/login (not surprisingly), but the HAproxy changed the URL back to HTTP, rather than keeping HTTPS. I could see it in the firewall log, that it was dropping the packets to port 80. As a matter of fact, if I added an "s" to the URL in the browser, it brought up the nextcloud login screen.

Turns out, there was another crucial setting to enable in the public service definition, namely enabling HSTS (HTTP Strict Transport Security). To do that, you have to enable advanced SSL setting in the dialog.

Please, see below my haproxy.conf for your reading pleasure. 

Code: [Select]

#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin
    nbproc                      1
    nbthread                    1
    tune.ssl.default-dh-param   2048
    spread-checks               2
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log /var/run/log local0 info

defaults
    log     global
    option redispatch -1
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats




# Frontend: gyalogkakukk ()
frontend gyalogkakukk
    http-response set-header Strict-Transport-Security "max-age=15768000"
    bind 0.0.0.0:443 name 0.0.0.0:443 ssl prefer-client-ciphers ssl-min-ver TLSv1.2 ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256 ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 crt-list /tmp/haproxy/ssl/60b3a337e588a4.59721209.certlist
    mode http
    option http-keep-alive
    default_backend josie
    # tuning options
    maxconn 100
    timeout client 30s

    # logging options
    option log-separate-errors
    option httplog
    # ACL: www_gyalogkakukk_net
    acl acl_60b3f6269afbe3.91531576 hdr(host) -i www.gyalogkakukk.net

    # ACTION: gyalogkakukk
    use_backend josie if acl_60b3f6269afbe3.91531576

# Backend: josie ()
backend josie
    # health checking is DISABLED
    mode http
    balance roundrobin
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server josie 192.168.3.10:80